From noreply at sourceforge.net Thu Mar 1 05:27:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Feb 2007 20:27:29 -0800 Subject: [ python-Bugs-1671411 ] python code fails with "MemoryError" on HP-UX 11.11 PA_RISC Message-ID: Bugs item #1671411, was opened at 2007-03-01 11:27 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=1671411&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Performance Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: shashi (shashikala) Assigned to: Nobody/Anonymous (nobody) Summary: python code fails with "MemoryError" on HP-UX 11.11 PA_RISC Initial Comment: Hi, Python-2.5 code fails with "MemoryError". This is happening only on one system, PA-RISC running HP-UX 11.11.Failing system has 12 GB of RAM installed, non-failing system has 8 GB. 1) spark 9GB phys mem(Python is working fine) 2) stalker 12GB phys mem (that has problem with python 2.5 ) please assist me in this. Thanks in advance Shashi ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671411&group_id=5470 From noreply at sourceforge.net Thu Mar 1 07:38:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Feb 2007 22:38:48 -0800 Subject: [ python-Bugs-1671411 ] python code fails with "MemoryError" on HP-UX 11.11 PA_RISC Message-ID: Bugs item #1671411, was opened at 2007-03-01 05:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671411&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Performance Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: shashi (shashikala) Assigned to: Nobody/Anonymous (nobody) Summary: python code fails with "MemoryError" on HP-UX 11.11 PA_RISC Initial Comment: Hi, Python-2.5 code fails with "MemoryError". This is happening only on one system, PA-RISC running HP-UX 11.11.Failing system has 12 GB of RAM installed, non-failing system has 8 GB. 1) spark 9GB phys mem(Python is working fine) 2) stalker 12GB phys mem (that has problem with python 2.5 ) please assist me in this. Thanks in advance Shashi ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-01 07:38 Message: Logged In: YES user_id=21627 Originator: NO This tracker is not about assistance. If at all, we need you to assist us. Can you please report more details, like stack traces, causes of the crash, patches? If not, I think there is little we can do about this report ("it crashes" is pretty unspecific). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671411&group_id=5470 From noreply at sourceforge.net Thu Mar 1 07:40:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Feb 2007 22:40:53 -0800 Subject: [ python-Bugs-1669743 ] Python needs a way to detect implementation Message-ID: Bugs item #1669743, was opened at 2007-02-27 08:32 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669743&group_id=5470 Please note that this 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: Feature Request >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Kay Hayen (kayhayen2) Assigned to: Nobody/Anonymous (nobody) Summary: Python needs a way to detect implementation Initial Comment: Hello, I am currently writing an application that will run under both CPython and PyPy. In this I encountered the need to discover the implementation of the current interpreter. For example, with PyPy the use of StringIO may offer benefits due to the possibility of more complete analysis of data flows during compilation or JIT execution. I want to take advantage of this. (Granted, currently pypy will run on top of CPython most of the time, so it's not the real solution to my problem until PyPy-c is at comparable performance). This is only example, a lot of different performance behaviors exist, that at times, will make sense to be abstracted. I have checked module sys of both implementations (plus Jython) and found in CPython only the property "subversion", which contains a tuple with CPython being the first element. My suspect is though that this is related to the detail of using svn in CPython development, and as such, would not be a good standard. So, what I believe with more and more Python versions existing (e.g. IronPython), it is needed to have sys.implementation that puts sys.version into context. My proposal is that CPython leads the effort to aid this, and the other Python variants can then adopt the standard property. Thank you in advance, Kay Hayen ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-01 07:40 Message: Logged In: YES user_id=21627 Originator: NO Please take a look at sys.subversion. This is fixed in Python 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669743&group_id=5470 From noreply at sourceforge.net Thu Mar 1 11:09:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Mar 2007 02:09:33 -0800 Subject: [ python-Bugs-1647654 ] No obvious and correct way to get the time zone offset Message-ID: Bugs item #1647654, was opened at 2007-01-30 13:48 Message generated for change (Comment added) made by jhenstridge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1647654&group_id=5470 Please note that this 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 Private: No Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: No obvious and correct way to get the time zone offset Initial Comment: It would be nice if the Python time module provided an obvious way to get the local time UTC offset for an arbitrary time stamp. The existing constants included in the module are not sufficient to correctly determine this value. As context, the Bazaar version control system (written in Python), the local time UTC offset is recorded in a commit. The method used in releases prior to 0.14 made use of the "daylight", "timezone" and "altzone" constants from the time module like this: if time.localtime(t).tm_isdst and time.daylight: return -time.altzone else: return -time.timezone This worked most of the time, but would occasionally give incorrect results. On Linux, the local time system can handle different daylight saving rules for different spans of years. For years where the rules change, these constants can provide incorrect data. Furthermore, they may be incorrect for time stamps in the past. I personally ran into this problem last December when Western Australia adopted daylight saving -- time.altzone gave an incorrect value until the start of 2007. Having a function in the standard library to calculate this offset would solve the problem. The implementation we ended up with for Bazaar was: offset = datetime.fromtimestamp(t) - datetime.utcfromtimestamp(t) return offset.days * 86400 + offset.seconds Another alternative would be to expose tm_gmtoff on time tuples (perhaps using the above code to synthesise it on platforms that don't have the field). ---------------------------------------------------------------------- >Comment By: James Henstridge (jhenstridge) Date: 2007-03-01 18:09 Message: Logged In: YES user_id=146903 Originator: YES The localtime_tz() function sounds like it would probably fit the bill. Another option would be to expose tm_gmtoff and tm_zone as non-sequence fields of time.struct_time for systems that support them. This would provide the data without needing new APIs. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-02-24 08:31 Message: Logged In: YES user_id=226443 Originator: NO See patch #1667546 for a time module function returning extended time tuples. The datetime-based solution you provide is quite a clever workaround using "naive" datetime objects, but I'm inclined to think that some more convenient way of getting "aware" datetime objects would be nicer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1647654&group_id=5470 From noreply at sourceforge.net Thu Mar 1 11:25:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Mar 2007 02:25:54 -0800 Subject: [ python-Bugs-1628895 ] Pydoc sets choices for doc locations incorrectly Message-ID: Bugs item #1628895, was opened at 2007-01-05 16:24 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1628895&group_id=5470 Please note that this 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 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Pydoc sets choices for doc locations incorrectly Initial Comment: In pydoc.Helper.__init__ I see this code: execdir = os.path.dirname(sys.executable) homedir = os.environ.get('PYTHONHOME') for dir in [os.environ.get('PYTHONDOCS'), homedir and os.path.join(homedir, 'doc'), os.path.join(execdir, 'doc'), '/usr/doc/python-docs-' + split(sys.version)[0], '/usr/doc/python-' + split(sys.version)[0], '/usr/doc/python-docs-' + sys.version[:3], '/usr/doc/python-' + sys.version[:3], os.path.join(sys.prefix, 'Resources/English.lproj/Documenta$ if dir and os.path.isdir(os.path.join(dir, 'lib')): self.docdir = dir I think the third choice in the list of candidate directories is wrong. execdir is the directory of the Python executable (e.g., it's /usr/local/bin by default). I think it should be set as execdir = os.path.dirname(os.path.dirname(sys.executable)) You're not going to find a "doc" directory in /usr/local/bin. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-01 10:25 Message: Logged In: YES user_id=849994 Originator: NO Looks like that is for Windows distributions, as there is C:\Python24\python.exe and C:\Python24\Doc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1628895&group_id=5470 From noreply at sourceforge.net Thu Mar 1 12:47:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Mar 2007 03:47:25 -0800 Subject: [ python-Bugs-1671411 ] python code fails with "MemoryError" on HP-UX 11.11 PA_RISC Message-ID: Bugs item #1671411, was opened at 2007-03-01 11:27 Message generated for change (Comment added) made by shashikala You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671411&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Performance Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: shashi (shashikala) Assigned to: Nobody/Anonymous (nobody) Summary: python code fails with "MemoryError" on HP-UX 11.11 PA_RISC Initial Comment: Hi, Python-2.5 code fails with "MemoryError". This is happening only on one system, PA-RISC running HP-UX 11.11.Failing system has 12 GB of RAM installed, non-failing system has 8 GB. 1) spark 9GB phys mem(Python is working fine) 2) stalker 12GB phys mem (that has problem with python 2.5 ) please assist me in this. Thanks in advance Shashi ---------------------------------------------------------------------- >Comment By: shashi (shashikala) Date: 2007-03-01 18:47 Message: Logged In: YES user_id=1506183 Originator: YES File Added: Pythonmemoryerror.txt ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-01 13:38 Message: Logged In: YES user_id=21627 Originator: NO This tracker is not about assistance. If at all, we need you to assist us. Can you please report more details, like stack traces, causes of the crash, patches? If not, I think there is little we can do about this report ("it crashes" is pretty unspecific). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671411&group_id=5470 From noreply at sourceforge.net Thu Mar 1 13:24:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Mar 2007 04:24:44 -0800 Subject: [ python-Bugs-1671676 ] test_mailbox is hanging while doing gmake test on HP-UX v3 Message-ID: Bugs item #1671676, was opened at 2007-03-01 19:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671676&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: shashi (shashikala) Assigned to: Nobody/Anonymous (nobody) Summary: test_mailbox is hanging while doing gmake test on HP-UX v3 Initial Comment: Hi , I am testing Python 2.5 on HP-UX 11iv3 using gmake test , while testing the test test_mailbox.py is hanging . when tried to track the problem i came to know that in the function if pid == 0: # In the child, lock the mailbox. self._box.lock() time.sleep(2) self._box.unlock() os._exit(0) # In the parent, sleep a bit to give the child time to acquire # the lock. time.sleep(0.5) try: self.assertRaises(mailbox.ExternalClashError, self._box.lock) finally: # Wait for child to exit. Locking should now succeed. exited_pid, status = os.waitpid(pid, 0) after forking the child , child is not returning status to the parent while its waiting for the return status. which part of the Python functionality is checked. Please assist me to solve this. Thanks in advance , shashi ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671676&group_id=5470 From noreply at sourceforge.net Thu Mar 1 19:01:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Mar 2007 10:01:40 -0800 Subject: [ python-Bugs-1669743 ] Python needs a way to detect implementation Message-ID: Bugs item #1669743, was opened at 2007-02-27 08:32 Message generated for change (Comment added) made by kayhayen2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669743&group_id=5470 Please note that this 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: Feature Request Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Kay Hayen (kayhayen2) Assigned to: Nobody/Anonymous (nobody) Summary: Python needs a way to detect implementation Initial Comment: Hello, I am currently writing an application that will run under both CPython and PyPy. In this I encountered the need to discover the implementation of the current interpreter. For example, with PyPy the use of StringIO may offer benefits due to the possibility of more complete analysis of data flows during compilation or JIT execution. I want to take advantage of this. (Granted, currently pypy will run on top of CPython most of the time, so it's not the real solution to my problem until PyPy-c is at comparable performance). This is only example, a lot of different performance behaviors exist, that at times, will make sense to be abstracted. I have checked module sys of both implementations (plus Jython) and found in CPython only the property "subversion", which contains a tuple with CPython being the first element. My suspect is though that this is related to the detail of using svn in CPython development, and as such, would not be a good standard. So, what I believe with more and more Python versions existing (e.g. IronPython), it is needed to have sys.implementation that puts sys.version into context. My proposal is that CPython leads the effort to aid this, and the other Python variants can then adopt the standard property. Thank you in advance, Kay Hayen ---------------------------------------------------------------------- >Comment By: Kay Hayen (kayhayen2) Date: 2007-03-01 19:01 Message: Logged In: YES user_id=1730054 Originator: YES Well, I did find sys.subversion of CPython 2.5 and sys.pypy_svn_url of Pypy 0.99 or so. The docs currently say about sys.subversion: "A triple (repo, branch, version) representing the Subversion information of the Python interpreter. repo is the name of the repository, 'CPython'. branch is a string of one of the forms 'trunk', 'branches/name' or 'tags/name'. version is the output of svnversion [...]" Would you confirm that sys.subversion is a property that every implementation of Python should have? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-01 07:40 Message: Logged In: YES user_id=21627 Originator: NO Please take a look at sys.subversion. This is fixed in Python 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669743&group_id=5470 From noreply at sourceforge.net Thu Mar 1 20:44:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Mar 2007 11:44:45 -0800 Subject: [ python-Bugs-1671965 ] shutil.copy2 modifies decimal part of last modification time Message-ID: Bugs item #1671965, was opened at 2007-03-01 20: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=1671965&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Guy Dalberto (guy-dalberto) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.copy2 modifies decimal part of last modification time Initial Comment: Problem on Windows 2000 with Python 2.5. When copying a file with shutil.copy2, the last modification times should be copied. What happens is that : + the integer part is copied correctly + the decimal part is modified + some samples : source-lastmod-time copy-lastmod-time file_0.txt 1172574881.34375 => 1172574881.034375 file_1.txt 1172574881.46875 => 1172574881.046875 + what is really odd is that the decimal part is divided by 10 The attached file *test_shutil_copy2.py* contains an Unit Test that demonstrate the incorrect behaviour ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671965&group_id=5470 From noreply at sourceforge.net Thu Mar 1 22:34:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Mar 2007 13:34:59 -0800 Subject: [ python-Bugs-1671411 ] python code fails with "MemoryError" on HP-UX 11.11 PA_RISC Message-ID: Bugs item #1671411, was opened at 2007-03-01 05:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671411&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Performance Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: shashi (shashikala) Assigned to: Nobody/Anonymous (nobody) Summary: python code fails with "MemoryError" on HP-UX 11.11 PA_RISC Initial Comment: Hi, Python-2.5 code fails with "MemoryError". This is happening only on one system, PA-RISC running HP-UX 11.11.Failing system has 12 GB of RAM installed, non-failing system has 8 GB. 1) spark 9GB phys mem(Python is working fine) 2) stalker 12GB phys mem (that has problem with python 2.5 ) please assist me in this. Thanks in advance Shashi ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-01 22:34 Message: Logged In: YES user_id=21627 Originator: NO Can you also provide a gdb/dbx backtrace of where the problem occurred? ---------------------------------------------------------------------- Comment By: shashi (shashikala) Date: 2007-03-01 12:47 Message: Logged In: YES user_id=1506183 Originator: YES File Added: Pythonmemoryerror.txt ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-01 07:38 Message: Logged In: YES user_id=21627 Originator: NO This tracker is not about assistance. If at all, we need you to assist us. Can you please report more details, like stack traces, causes of the crash, patches? If not, I think there is little we can do about this report ("it crashes" is pretty unspecific). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671411&group_id=5470 From noreply at sourceforge.net Thu Mar 1 22:36:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Mar 2007 13:36:56 -0800 Subject: [ python-Bugs-1671965 ] shutil.copy2 modifies decimal part of last modification time Message-ID: Bugs item #1671965, was opened at 2007-03-01 20:44 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671965&group_id=5470 Please note that this 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.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Guy Dalberto (guy-dalberto) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.copy2 modifies decimal part of last modification time Initial Comment: Problem on Windows 2000 with Python 2.5. When copying a file with shutil.copy2, the last modification times should be copied. What happens is that : + the integer part is copied correctly + the decimal part is modified + some samples : source-lastmod-time copy-lastmod-time file_0.txt 1172574881.34375 => 1172574881.034375 file_1.txt 1172574881.46875 => 1172574881.046875 + what is really odd is that the decimal part is divided by 10 The attached file *test_shutil_copy2.py* contains an Unit Test that demonstrate the incorrect behaviour ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-01 22:36 Message: Logged In: YES user_id=21627 Originator: NO I believe this is a duplicate of #565150; it has been fixed in the maintenance branch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671965&group_id=5470 From noreply at sourceforge.net Thu Mar 1 22:40:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Mar 2007 13:40:45 -0800 Subject: [ python-Bugs-1669743 ] Python needs a way to detect implementation Message-ID: Bugs item #1669743, was opened at 2007-02-27 08:32 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669743&group_id=5470 Please note that this 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: Feature Request Status: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: Kay Hayen (kayhayen2) Assigned to: Nobody/Anonymous (nobody) Summary: Python needs a way to detect implementation Initial Comment: Hello, I am currently writing an application that will run under both CPython and PyPy. In this I encountered the need to discover the implementation of the current interpreter. For example, with PyPy the use of StringIO may offer benefits due to the possibility of more complete analysis of data flows during compilation or JIT execution. I want to take advantage of this. (Granted, currently pypy will run on top of CPython most of the time, so it's not the real solution to my problem until PyPy-c is at comparable performance). This is only example, a lot of different performance behaviors exist, that at times, will make sense to be abstracted. I have checked module sys of both implementations (plus Jython) and found in CPython only the property "subversion", which contains a tuple with CPython being the first element. My suspect is though that this is related to the detail of using svn in CPython development, and as such, would not be a good standard. So, what I believe with more and more Python versions existing (e.g. IronPython), it is needed to have sys.implementation that puts sys.version into context. My proposal is that CPython leads the effort to aid this, and the other Python variants can then adopt the standard property. Thank you in advance, Kay Hayen ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-01 22:40 Message: Logged In: YES user_id=21627 Originator: NO No; it should be only available in Python implementations that do indeed have subversion information available. If you truly want something that all Python implementations must implement to be valid implementations of the Python programming language, you will have to write a PEP. Closing this as "works for me". ---------------------------------------------------------------------- Comment By: Kay Hayen (kayhayen2) Date: 2007-03-01 19:01 Message: Logged In: YES user_id=1730054 Originator: YES Well, I did find sys.subversion of CPython 2.5 and sys.pypy_svn_url of Pypy 0.99 or so. The docs currently say about sys.subversion: "A triple (repo, branch, version) representing the Subversion information of the Python interpreter. repo is the name of the repository, 'CPython'. branch is a string of one of the forms 'trunk', 'branches/name' or 'tags/name'. version is the output of svnversion [...]" Would you confirm that sys.subversion is a property that every implementation of Python should have? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-01 07:40 Message: Logged In: YES user_id=21627 Originator: NO Please take a look at sys.subversion. This is fixed in Python 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669743&group_id=5470 From noreply at sourceforge.net Fri Mar 2 12:10:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Mar 2007 03:10:33 -0800 Subject: [ python-Bugs-1672332 ] cPickle can pickle, but cannot unpickle on 64bit machines Message-ID: Bugs item #1672332, was opened at 2007-03-02 12:10 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=1672332&group_id=5470 Please note that this 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 Private: No Submitted By: Bartlomiej Ogryczak (oneg) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle can pickle, but cannot unpickle on 64bit machines Initial Comment: Seems that on 64-bit machines cPickle is able to pickle floats smaller then DBL_MIN, but it's unable to unpickle them. 64-bit machine (Solaris 10 on Sparc) Python 2.4.4 (#1, Oct 26 2006, 10:01:37) [GCC 3.3.4] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import cPickle >>> cPickle.dumps(1e-310) 'F9.9999999999999694e-311\n.' >>> cPickle.loads(_) Traceback (most recent call last): File "", line 1, in ? ValueError: could not convert string to float Same thing works fine on 32-bit machine (P4 with MS Windows) Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import cPickle >>> cPickle.dumps(1e-310) 'F0\n.' >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672332&group_id=5470 From noreply at sourceforge.net Fri Mar 2 12:16:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Mar 2007 03:16:57 -0800 Subject: [ python-Bugs-1672336 ] Building python 2.5 for AMD64 (windows) and VS2005 Message-ID: Bugs item #1672336, was opened at 2007-03-02 12:16 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=1672336&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: fred2k (fred2k) Assigned to: Nobody/Anonymous (nobody) Summary: Building python 2.5 for AMD64 (windows) and VS2005 Initial Comment: When building pythoncore for AMD64 (WIndows) on VS2005, I get the following error : 3>generate buildinfo 3>cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -MD -MD /USECL:MS_OPTERON ..\Modules\getbuildinfo.c -Fogetbuildinfo.o -I..\Include -I..\PC 3>Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86 3>Copyright (C) Microsoft Corporation. All rights reserved. 3>getbuildinfo.c 3>Linking... 3>LINK : warning LNK4044: unrecognized option '/USELINK:MS_SDK'; ignored 3>getbuildinfo.o : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' 3>Build log was saved at "file://d:\users\fbr\python build\Python-2.5\PCbuild8\amd64-temp-release\pythoncore\BuildLog.htm" 3>pythoncore - 1 error(s), 225 warning(s) I already looked for the issue on google and on the ML archive (http://mail.python.org/pipermail/python-dev/2006-March/062753.html) but the workaround explained there (checking vsextcompiler) is specific for VC2003. Has anyone solved this problem ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 From noreply at sourceforge.net Fri Mar 2 15:37:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Mar 2007 06:37:33 -0800 Subject: [ python-Bugs-1628895 ] Pydoc sets choices for doc locations incorrectly Message-ID: Bugs item #1628895, was opened at 2007-01-05 16:24 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1628895&group_id=5470 Please note that this 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: Fixed Priority: 5 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Pydoc sets choices for doc locations incorrectly Initial Comment: In pydoc.Helper.__init__ I see this code: execdir = os.path.dirname(sys.executable) homedir = os.environ.get('PYTHONHOME') for dir in [os.environ.get('PYTHONDOCS'), homedir and os.path.join(homedir, 'doc'), os.path.join(execdir, 'doc'), '/usr/doc/python-docs-' + split(sys.version)[0], '/usr/doc/python-' + split(sys.version)[0], '/usr/doc/python-docs-' + sys.version[:3], '/usr/doc/python-' + sys.version[:3], os.path.join(sys.prefix, 'Resources/English.lproj/Documenta$ if dir and os.path.isdir(os.path.join(dir, 'lib')): self.docdir = dir I think the third choice in the list of candidate directories is wrong. execdir is the directory of the Python executable (e.g., it's /usr/local/bin by default). I think it should be set as execdir = os.path.dirname(os.path.dirname(sys.executable)) You're not going to find a "doc" directory in /usr/local/bin. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-02 14:37 Message: Logged In: YES user_id=849994 Originator: NO Added some more search paths in rev. 54080. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-01 10:25 Message: Logged In: YES user_id=849994 Originator: NO Looks like that is for Windows distributions, as there is C:\Python24\python.exe and C:\Python24\Doc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1628895&group_id=5470 From noreply at sourceforge.net Fri Mar 2 16:48:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Mar 2007 07:48:50 -0800 Subject: [ python-Bugs-1647654 ] No obvious and correct way to get the time zone offset Message-ID: Bugs item #1647654, was opened at 2007-01-30 00:48 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1647654&group_id=5470 Please note that this 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 Private: No Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: No obvious and correct way to get the time zone offset Initial Comment: It would be nice if the Python time module provided an obvious way to get the local time UTC offset for an arbitrary time stamp. The existing constants included in the module are not sufficient to correctly determine this value. As context, the Bazaar version control system (written in Python), the local time UTC offset is recorded in a commit. The method used in releases prior to 0.14 made use of the "daylight", "timezone" and "altzone" constants from the time module like this: if time.localtime(t).tm_isdst and time.daylight: return -time.altzone else: return -time.timezone This worked most of the time, but would occasionally give incorrect results. On Linux, the local time system can handle different daylight saving rules for different spans of years. For years where the rules change, these constants can provide incorrect data. Furthermore, they may be incorrect for time stamps in the past. I personally ran into this problem last December when Western Australia adopted daylight saving -- time.altzone gave an incorrect value until the start of 2007. Having a function in the standard library to calculate this offset would solve the problem. The implementation we ended up with for Bazaar was: offset = datetime.fromtimestamp(t) - datetime.utcfromtimestamp(t) return offset.days * 86400 + offset.seconds Another alternative would be to expose tm_gmtoff on time tuples (perhaps using the above code to synthesise it on platforms that don't have the field). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 10:48 Message: Logged In: YES user_id=6380 Originator: NO Hm.... I'm not sure I understand why the first bit of code didn't work. Can you give a concrete example? (I.e. what was t, what was returned by localtime(t), and what were the three time variables that day.) I don't know the details of Western Australia's DST change. But looking at the source of timemodule.c, I notice that it simply samples the timezone on Jan 1st and July 1st, and if they differ, decides which one is summer time by which one is smaller. Your remark that the problem righted itself in January makes me wonder -- between what dates did you have DST? Alternatively, it could be that your system simply didn't have the correct DST change data loaded yet (this happens all the time when governments change the rules). Can you rule that out? I really don't want to have to change Python in order to correct for *that* problem. Yet another question, if you were to code this in C, how would you write it? Regardless, I think that it would be useful to support tm_gmtoff and other struct tm entries, the same way that we do this in struct stat. You could probably also get the correct result (assuming your system's timezone database is correct) by comparing localtime() and gmtime(). But the reverse engineering is a bit painful; your trick using datetime essentially does that. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2007-03-01 05:09 Message: Logged In: YES user_id=146903 Originator: YES The localtime_tz() function sounds like it would probably fit the bill. Another option would be to expose tm_gmtoff and tm_zone as non-sequence fields of time.struct_time for systems that support them. This would provide the data without needing new APIs. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-02-23 19:31 Message: Logged In: YES user_id=226443 Originator: NO See patch #1667546 for a time module function returning extended time tuples. The datetime-based solution you provide is quite a clever workaround using "naive" datetime objects, but I'm inclined to think that some more convenient way of getting "aware" datetime objects would be nicer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1647654&group_id=5470 From noreply at sourceforge.net Fri Mar 2 17:05:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Mar 2007 08:05:34 -0800 Subject: [ python-Bugs-1646728 ] datetime.fromtimestamp fails with negative fractional times Message-ID: Bugs item #1646728, was opened at 2007-01-28 21:21 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.fromtimestamp fails with negative fractional times Initial Comment: The datetime.fromtimestamp() function works fine with integer timestamps and positive fractional timestamps, but fails if I pass a negative fractional timestamp. For example: >>> import datetime >>> datetime.datetime.fromtimestamp(-1.05) Traceback (most recent call last): File "", line 1, in ValueError: microsecond must be in 0..999999 It should return the same result as datetime.fromtimestamp(-1) - timedelta(seconds=.5). The same bug can be triggered in datetime.utcfromtimestamp(). I have been able to reproduce this bug in Python 2.4.4 and Python 2.5 on Linux. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 11:05 Message: Logged In: YES user_id=6380 Originator: NO Looks like a bug in the conversion from floats to ints. Anyone care to track it down more precisely? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 From noreply at sourceforge.net Fri Mar 2 18:04:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Mar 2007 09:04:08 -0800 Subject: [ python-Bugs-1672568 ] silent error in email.message.Message.get_payload Message-ID: Bugs item #1672568, was opened at 2007-03-02 18: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=1672568&group_id=5470 Please note that this 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: Not a Bug Status: Open Resolution: None Priority: 5 Private: No Submitted By: Renaud Blanch (blanch) Assigned to: Nobody/Anonymous (nobody) Summary: silent error in email.message.Message.get_payload Initial Comment: I rencently had trouble finding a bug in an email processing script because of an error that pass silently in the email module. The get_payload() method in the email.message module always return something when the decode argument is set to True. This behaviour is well documented, but is their a reason to catch the decoding errors ? Why not let them pop-up to the calling code ? renaud ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672568&group_id=5470 From noreply at sourceforge.net Fri Mar 2 21:30:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Mar 2007 12:30:45 -0800 Subject: [ python-Bugs-1669304 ] Clarify PyMem_Realloc and PyMem_Resize docs Message-ID: Bugs item #1669304, was opened at 2007-02-26 17:26 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669304&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: Clarify PyMem_Realloc and PyMem_Resize docs Initial Comment: This should close 1668036 and 1668032 which both looked like valid doc patch requests. The pymem_resize patch indicates the PyMem_Resize assigns to p (its first argument), and the pymem_realloc patch indicates that PyMem_Realloc will not modify the pointer if the realloc fails. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-02 20:30 Message: Logged In: YES user_id=849994 Originator: NO Fixed in rev. 54088, 54089 (2.5). ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2007-02-26 17:26 Message: Logged In: YES user_id=945502 Originator: YES File Added: pymem_realloc.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669304&group_id=5470 From noreply at sourceforge.net Fri Mar 2 21:30:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Mar 2007 12:30:51 -0800 Subject: [ python-Bugs-1668032 ] PyMem_Realloc docs don't specifiy out-of-mem behavior Message-ID: Bugs item #1668032, was opened at 2007-02-24 21:01 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668032&group_id=5470 Please note that this 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 Private: No Submitted By: Daniel Stutzbach (agthorr) Assigned to: Nobody/Anonymous (nobody) Summary: PyMem_Realloc docs don't specifiy out-of-mem behavior Initial Comment: I suggest adding the following text to the documentation for PyMem_Realloc: "If the request fails, PyMem_Realloc returns NULL and p remains a valid allocated pointer." I dug into obmalloc.c to figure out the behavior. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-02 20:30 Message: Logged In: YES user_id=849994 Originator: NO Fixed in rev. 54088, 54089 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668032&group_id=5470 From noreply at sourceforge.net Fri Mar 2 21:30:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Mar 2007 12:30:58 -0800 Subject: [ python-Bugs-1668036 ] PyMem_Resize docs don't specify that it modifies an argument Message-ID: Bugs item #1668036, was opened at 2007-02-24 21:09 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668036&group_id=5470 Please note that this 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 Private: No Submitted By: Daniel Stutzbach (agthorr) Assigned to: Nobody/Anonymous (nobody) Summary: PyMem_Resize docs don't specify that it modifies an argument Initial Comment: PyMem_Resize is defined as follows: #define PyMem_Resize(p, type, n) \ ( (p) = (type *) PyMem_Realloc((p), (n) * sizeof(type)) ) The docs for PyMem_Resize don't specify that it modifies p. I suggest adding the following sentence: "On return, p will point to the new memory area, or NULL in the event of failure." ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-02 20:30 Message: Logged In: YES user_id=849994 Originator: NO Fixed in rev. 54088, 54089 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668036&group_id=5470 From noreply at sourceforge.net Sat Mar 3 02:49:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Mar 2007 17:49:45 -0800 Subject: [ python-Bugs-1672336 ] Building python 2.5 for AMD64 (windows) and VS2005 Message-ID: Bugs item #1672336, was opened at 2007-03-02 12:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: fred2k (fred2k) >Assigned to: Kristj?n Valur (krisvale) Summary: Building python 2.5 for AMD64 (windows) and VS2005 Initial Comment: When building pythoncore for AMD64 (WIndows) on VS2005, I get the following error : 3>generate buildinfo 3>cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -MD -MD /USECL:MS_OPTERON ..\Modules\getbuildinfo.c -Fogetbuildinfo.o -I..\Include -I..\PC 3>Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86 3>Copyright (C) Microsoft Corporation. All rights reserved. 3>getbuildinfo.c 3>Linking... 3>LINK : warning LNK4044: unrecognized option '/USELINK:MS_SDK'; ignored 3>getbuildinfo.o : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' 3>Build log was saved at "file://d:\users\fbr\python build\Python-2.5\PCbuild8\amd64-temp-release\pythoncore\BuildLog.htm" 3>pythoncore - 1 error(s), 225 warning(s) I already looked for the issue on google and on the ML archive (http://mail.python.org/pipermail/python-dev/2006-March/062753.html) but the workaround explained there (checking vsextcompiler) is specific for VC2003. Has anyone solved this problem ? ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2007-03-03 02:49 Message: Logged In: YES user_id=21627 Originator: NO Kristjan, can you take a look? If not, please unassign. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 From noreply at sourceforge.net Sat Mar 3 09:01:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Mar 2007 00:01:41 -0800 Subject: [ python-Bugs-1672853 ] Error reading files larger than 4GB Message-ID: Bugs item #1672853, was opened at 2007-03-03 00: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=1672853&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Case Van Horsen (casevh) Assigned to: Nobody/Anonymous (nobody) Summary: Error reading files larger than 4GB Initial Comment: When reading test files larger than 4GB, sometimes two lines are merged into a single line. The problem is reproducible on Windows 2K SP4 with both Python 2.4 and 2.5. It does not appear to occur on Linux. I have attached a test case that creates the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672853&group_id=5470 From noreply at sourceforge.net Sat Mar 3 11:23:27 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Mar 2007 02:23:27 -0800 Subject: [ python-Bugs-1672336 ] Building python 2.5 for AMD64 (windows) and VS2005 Message-ID: Bugs item #1672336, was opened at 2007-03-02 11:16 Message generated for change (Comment added) made by krisvale You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: fred2k (fred2k) Assigned to: Kristj?n Valur (krisvale) Summary: Building python 2.5 for AMD64 (windows) and VS2005 Initial Comment: When building pythoncore for AMD64 (WIndows) on VS2005, I get the following error : 3>generate buildinfo 3>cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -MD -MD /USECL:MS_OPTERON ..\Modules\getbuildinfo.c -Fogetbuildinfo.o -I..\Include -I..\PC 3>Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86 3>Copyright (C) Microsoft Corporation. All rights reserved. 3>getbuildinfo.c 3>Linking... 3>LINK : warning LNK4044: unrecognized option '/USELINK:MS_SDK'; ignored 3>getbuildinfo.o : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' 3>Build log was saved at "file://d:\users\fbr\python build\Python-2.5\PCbuild8\amd64-temp-release\pythoncore\BuildLog.htm" 3>pythoncore - 1 error(s), 225 warning(s) I already looked for the issue on google and on the ML archive (http://mail.python.org/pipermail/python-dev/2006-March/062753.html) but the workaround explained there (checking vsextcompiler) is specific for VC2003. Has anyone solved this problem ? ---------------------------------------------------------------------- >Comment By: Kristj?n Valur (krisvale) Date: 2007-03-03 10:23 Message: Logged In: YES user_id=1262199 Originator: NO Well, it sounds like he is trying to link modules compiled for different machines. /USECL or /USELINK aren't options for MSVC, so something fishy is going on there. I will try to reproduce when I get the chance ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-03 01:49 Message: Logged In: YES user_id=21627 Originator: NO Kristjan, can you take a look? If not, please unassign. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 From noreply at sourceforge.net Sat Mar 3 11:40:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Mar 2007 02:40:05 -0800 Subject: [ python-Bugs-1672336 ] Building python 2.5 for AMD64 (windows) and VS2005 Message-ID: Bugs item #1672336, was opened at 2007-03-02 12:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: fred2k (fred2k) Assigned to: Kristj?n Valur (krisvale) Summary: Building python 2.5 for AMD64 (windows) and VS2005 Initial Comment: When building pythoncore for AMD64 (WIndows) on VS2005, I get the following error : 3>generate buildinfo 3>cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -MD -MD /USECL:MS_OPTERON ..\Modules\getbuildinfo.c -Fogetbuildinfo.o -I..\Include -I..\PC 3>Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86 3>Copyright (C) Microsoft Corporation. All rights reserved. 3>getbuildinfo.c 3>Linking... 3>LINK : warning LNK4044: unrecognized option '/USELINK:MS_SDK'; ignored 3>getbuildinfo.o : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' 3>Build log was saved at "file://d:\users\fbr\python build\Python-2.5\PCbuild8\amd64-temp-release\pythoncore\BuildLog.htm" 3>pythoncore - 1 error(s), 225 warning(s) I already looked for the issue on google and on the ML archive (http://mail.python.org/pipermail/python-dev/2006-March/062753.html) but the workaround explained there (checking vsextcompiler) is specific for VC2003. Has anyone solved this problem ? ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2007-03-03 11:40 Message: Logged In: YES user_id=21627 Originator: NO USECL and USELINK is easily resolved: that's an option of vsextcomp, used to build the "official" AMD64 and Itanium binaries with the 2003 build environment, vsextcomp, and the platform compilers. Apparently, when the VS 2005 projects were created, the AMD64 and Itanium targets weren't updated. ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2007-03-03 11:23 Message: Logged In: YES user_id=1262199 Originator: NO Well, it sounds like he is trying to link modules compiled for different machines. /USECL or /USELINK aren't options for MSVC, so something fishy is going on there. I will try to reproduce when I get the chance ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-03 02:49 Message: Logged In: YES user_id=21627 Originator: NO Kristjan, can you take a look? If not, please unassign. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 From noreply at sourceforge.net Sat Mar 3 11:57:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Mar 2007 02:57:12 -0800 Subject: [ python-Bugs-1672336 ] Building python 2.5 for AMD64 (windows) and VS2005 Message-ID: Bugs item #1672336, was opened at 2007-03-02 11:16 Message generated for change (Comment added) made by krisvale You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: fred2k (fred2k) Assigned to: Kristj?n Valur (krisvale) Summary: Building python 2.5 for AMD64 (windows) and VS2005 Initial Comment: When building pythoncore for AMD64 (WIndows) on VS2005, I get the following error : 3>generate buildinfo 3>cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -MD -MD /USECL:MS_OPTERON ..\Modules\getbuildinfo.c -Fogetbuildinfo.o -I..\Include -I..\PC 3>Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86 3>Copyright (C) Microsoft Corporation. All rights reserved. 3>getbuildinfo.c 3>Linking... 3>LINK : warning LNK4044: unrecognized option '/USELINK:MS_SDK'; ignored 3>getbuildinfo.o : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' 3>Build log was saved at "file://d:\users\fbr\python build\Python-2.5\PCbuild8\amd64-temp-release\pythoncore\BuildLog.htm" 3>pythoncore - 1 error(s), 225 warning(s) I already looked for the issue on google and on the ML archive (http://mail.python.org/pipermail/python-dev/2006-March/062753.html) but the workaround explained there (checking vsextcompiler) is specific for VC2003. Has anyone solved this problem ? ---------------------------------------------------------------------- >Comment By: Kristj?n Valur (krisvale) Date: 2007-03-03 10:57 Message: Logged In: YES user_id=1262199 Originator: NO This suggest to me that the reporter is not using the PCBuild8 build setup to do this, since that should have all-new flags. I will still try to repro, though. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-03 10:40 Message: Logged In: YES user_id=21627 Originator: NO USECL and USELINK is easily resolved: that's an option of vsextcomp, used to build the "official" AMD64 and Itanium binaries with the 2003 build environment, vsextcomp, and the platform compilers. Apparently, when the VS 2005 projects were created, the AMD64 and Itanium targets weren't updated. ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2007-03-03 10:23 Message: Logged In: YES user_id=1262199 Originator: NO Well, it sounds like he is trying to link modules compiled for different machines. /USECL or /USELINK aren't options for MSVC, so something fishy is going on there. I will try to reproduce when I get the chance ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-03 01:49 Message: Logged In: YES user_id=21627 Originator: NO Kristjan, can you take a look? If not, please unassign. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 From noreply at sourceforge.net Sat Mar 3 12:53:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Mar 2007 03:53:50 -0800 Subject: [ python-Bugs-1672336 ] Building python 2.5 for AMD64 (windows) and VS2005 Message-ID: Bugs item #1672336, was opened at 2007-03-02 12:16 Message generated for change (Comment added) made by fred2k You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: fred2k (fred2k) Assigned to: Kristj?n Valur (krisvale) Summary: Building python 2.5 for AMD64 (windows) and VS2005 Initial Comment: When building pythoncore for AMD64 (WIndows) on VS2005, I get the following error : 3>generate buildinfo 3>cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -MD -MD /USECL:MS_OPTERON ..\Modules\getbuildinfo.c -Fogetbuildinfo.o -I..\Include -I..\PC 3>Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86 3>Copyright (C) Microsoft Corporation. All rights reserved. 3>getbuildinfo.c 3>Linking... 3>LINK : warning LNK4044: unrecognized option '/USELINK:MS_SDK'; ignored 3>getbuildinfo.o : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' 3>Build log was saved at "file://d:\users\fbr\python build\Python-2.5\PCbuild8\amd64-temp-release\pythoncore\BuildLog.htm" 3>pythoncore - 1 error(s), 225 warning(s) I already looked for the issue on google and on the ML archive (http://mail.python.org/pipermail/python-dev/2006-March/062753.html) but the workaround explained there (checking vsextcompiler) is specific for VC2003. Has anyone solved this problem ? ---------------------------------------------------------------------- >Comment By: fred2k (fred2k) Date: 2007-03-03 12:53 Message: Logged In: YES user_id=1733250 Originator: YES What do you mean by PCBuild8 build setup ?? I only see the files that are necessary to the build in the directory. ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2007-03-03 11:57 Message: Logged In: YES user_id=1262199 Originator: NO This suggest to me that the reporter is not using the PCBuild8 build setup to do this, since that should have all-new flags. I will still try to repro, though. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-03 11:40 Message: Logged In: YES user_id=21627 Originator: NO USECL and USELINK is easily resolved: that's an option of vsextcomp, used to build the "official" AMD64 and Itanium binaries with the 2003 build environment, vsextcomp, and the platform compilers. Apparently, when the VS 2005 projects were created, the AMD64 and Itanium targets weren't updated. ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2007-03-03 11:23 Message: Logged In: YES user_id=1262199 Originator: NO Well, it sounds like he is trying to link modules compiled for different machines. /USECL or /USELINK aren't options for MSVC, so something fishy is going on there. I will try to reproduce when I get the chance ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-03 02:49 Message: Logged In: YES user_id=21627 Originator: NO Kristjan, can you take a look? If not, please unassign. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 From noreply at sourceforge.net Sat Mar 3 13:05:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Mar 2007 04:05:07 -0800 Subject: [ python-Bugs-1672336 ] Building python 2.5 for AMD64 (windows) and VS2005 Message-ID: Bugs item #1672336, was opened at 2007-03-02 12:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: fred2k (fred2k) Assigned to: Kristj?n Valur (krisvale) Summary: Building python 2.5 for AMD64 (windows) and VS2005 Initial Comment: When building pythoncore for AMD64 (WIndows) on VS2005, I get the following error : 3>generate buildinfo 3>cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -MD -MD /USECL:MS_OPTERON ..\Modules\getbuildinfo.c -Fogetbuildinfo.o -I..\Include -I..\PC 3>Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86 3>Copyright (C) Microsoft Corporation. All rights reserved. 3>getbuildinfo.c 3>Linking... 3>LINK : warning LNK4044: unrecognized option '/USELINK:MS_SDK'; ignored 3>getbuildinfo.o : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' 3>Build log was saved at "file://d:\users\fbr\python build\Python-2.5\PCbuild8\amd64-temp-release\pythoncore\BuildLog.htm" 3>pythoncore - 1 error(s), 225 warning(s) I already looked for the issue on google and on the ML archive (http://mail.python.org/pipermail/python-dev/2006-March/062753.html) but the workaround explained there (checking vsextcompiler) is specific for VC2003. Has anyone solved this problem ? ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2007-03-03 13:05 Message: Logged In: YES user_id=21627 Originator: NO In what directory? PCbuild or PCbuild8? ---------------------------------------------------------------------- Comment By: fred2k (fred2k) Date: 2007-03-03 12:53 Message: Logged In: YES user_id=1733250 Originator: YES What do you mean by PCBuild8 build setup ?? I only see the files that are necessary to the build in the directory. ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2007-03-03 11:57 Message: Logged In: YES user_id=1262199 Originator: NO This suggest to me that the reporter is not using the PCBuild8 build setup to do this, since that should have all-new flags. I will still try to repro, though. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-03 11:40 Message: Logged In: YES user_id=21627 Originator: NO USECL and USELINK is easily resolved: that's an option of vsextcomp, used to build the "official" AMD64 and Itanium binaries with the 2003 build environment, vsextcomp, and the platform compilers. Apparently, when the VS 2005 projects were created, the AMD64 and Itanium targets weren't updated. ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2007-03-03 11:23 Message: Logged In: YES user_id=1262199 Originator: NO Well, it sounds like he is trying to link modules compiled for different machines. /USECL or /USELINK aren't options for MSVC, so something fishy is going on there. I will try to reproduce when I get the chance ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-03 02:49 Message: Logged In: YES user_id=21627 Originator: NO Kristjan, can you take a look? If not, please unassign. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 From noreply at sourceforge.net Sat Mar 3 13:08:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Mar 2007 04:08:49 -0800 Subject: [ python-Bugs-1672336 ] Building python 2.5 for AMD64 (windows) and VS2005 Message-ID: Bugs item #1672336, was opened at 2007-03-02 12:16 Message generated for change (Comment added) made by fred2k You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: fred2k (fred2k) Assigned to: Kristj?n Valur (krisvale) Summary: Building python 2.5 for AMD64 (windows) and VS2005 Initial Comment: When building pythoncore for AMD64 (WIndows) on VS2005, I get the following error : 3>generate buildinfo 3>cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -MD -MD /USECL:MS_OPTERON ..\Modules\getbuildinfo.c -Fogetbuildinfo.o -I..\Include -I..\PC 3>Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86 3>Copyright (C) Microsoft Corporation. All rights reserved. 3>getbuildinfo.c 3>Linking... 3>LINK : warning LNK4044: unrecognized option '/USELINK:MS_SDK'; ignored 3>getbuildinfo.o : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' 3>Build log was saved at "file://d:\users\fbr\python build\Python-2.5\PCbuild8\amd64-temp-release\pythoncore\BuildLog.htm" 3>pythoncore - 1 error(s), 225 warning(s) I already looked for the issue on google and on the ML archive (http://mail.python.org/pipermail/python-dev/2006-March/062753.html) but the workaround explained there (checking vsextcompiler) is specific for VC2003. Has anyone solved this problem ? ---------------------------------------------------------------------- >Comment By: fred2k (fred2k) Date: 2007-03-03 13:08 Message: Logged In: YES user_id=1733250 Originator: YES As I tried to build with MVS2005, I used the sln file in the PCBuild8 directory ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-03 13:05 Message: Logged In: YES user_id=21627 Originator: NO In what directory? PCbuild or PCbuild8? ---------------------------------------------------------------------- Comment By: fred2k (fred2k) Date: 2007-03-03 12:53 Message: Logged In: YES user_id=1733250 Originator: YES What do you mean by PCBuild8 build setup ?? I only see the files that are necessary to the build in the directory. ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2007-03-03 11:57 Message: Logged In: YES user_id=1262199 Originator: NO This suggest to me that the reporter is not using the PCBuild8 build setup to do this, since that should have all-new flags. I will still try to repro, though. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-03 11:40 Message: Logged In: YES user_id=21627 Originator: NO USECL and USELINK is easily resolved: that's an option of vsextcomp, used to build the "official" AMD64 and Itanium binaries with the 2003 build environment, vsextcomp, and the platform compilers. Apparently, when the VS 2005 projects were created, the AMD64 and Itanium targets weren't updated. ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2007-03-03 11:23 Message: Logged In: YES user_id=1262199 Originator: NO Well, it sounds like he is trying to link modules compiled for different machines. /USECL or /USELINK aren't options for MSVC, so something fishy is going on there. I will try to reproduce when I get the chance ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-03 02:49 Message: Logged In: YES user_id=21627 Originator: NO Kristjan, can you take a look? If not, please unassign. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 From noreply at sourceforge.net Sat Mar 3 14:13:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Mar 2007 05:13:33 -0800 Subject: [ python-Bugs-1672336 ] Building python 2.5 for AMD64 (windows) and VS2005 Message-ID: Bugs item #1672336, was opened at 2007-03-02 11:16 Message generated for change (Comment added) made by krisvale You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: fred2k (fred2k) Assigned to: Kristj?n Valur (krisvale) Summary: Building python 2.5 for AMD64 (windows) and VS2005 Initial Comment: When building pythoncore for AMD64 (WIndows) on VS2005, I get the following error : 3>generate buildinfo 3>cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -MD -MD /USECL:MS_OPTERON ..\Modules\getbuildinfo.c -Fogetbuildinfo.o -I..\Include -I..\PC 3>Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86 3>Copyright (C) Microsoft Corporation. All rights reserved. 3>getbuildinfo.c 3>Linking... 3>LINK : warning LNK4044: unrecognized option '/USELINK:MS_SDK'; ignored 3>getbuildinfo.o : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' 3>Build log was saved at "file://d:\users\fbr\python build\Python-2.5\PCbuild8\amd64-temp-release\pythoncore\BuildLog.htm" 3>pythoncore - 1 error(s), 225 warning(s) I already looked for the issue on google and on the ML archive (http://mail.python.org/pipermail/python-dev/2006-March/062753.html) but the workaround explained there (checking vsextcompiler) is specific for VC2003. Has anyone solved this problem ? ---------------------------------------------------------------------- >Comment By: Kristj?n Valur (krisvale) Date: 2007-03-03 13:13 Message: Logged In: YES user_id=1262199 Originator: NO Ok, I will look into this when I get the oppertunity. Possibly these .sln file or .vcproj have gotten contaminated with some strange options... ---------------------------------------------------------------------- Comment By: fred2k (fred2k) Date: 2007-03-03 12:08 Message: Logged In: YES user_id=1733250 Originator: YES As I tried to build with MVS2005, I used the sln file in the PCBuild8 directory ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-03 12:05 Message: Logged In: YES user_id=21627 Originator: NO In what directory? PCbuild or PCbuild8? ---------------------------------------------------------------------- Comment By: fred2k (fred2k) Date: 2007-03-03 11:53 Message: Logged In: YES user_id=1733250 Originator: YES What do you mean by PCBuild8 build setup ?? I only see the files that are necessary to the build in the directory. ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2007-03-03 10:57 Message: Logged In: YES user_id=1262199 Originator: NO This suggest to me that the reporter is not using the PCBuild8 build setup to do this, since that should have all-new flags. I will still try to repro, though. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-03 10:40 Message: Logged In: YES user_id=21627 Originator: NO USECL and USELINK is easily resolved: that's an option of vsextcomp, used to build the "official" AMD64 and Itanium binaries with the 2003 build environment, vsextcomp, and the platform compilers. Apparently, when the VS 2005 projects were created, the AMD64 and Itanium targets weren't updated. ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2007-03-03 10:23 Message: Logged In: YES user_id=1262199 Originator: NO Well, it sounds like he is trying to link modules compiled for different machines. /USECL or /USELINK aren't options for MSVC, so something fishy is going on there. I will try to reproduce when I get the chance ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-03 01:49 Message: Logged In: YES user_id=21627 Originator: NO Kristjan, can you take a look? If not, please unassign. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 From noreply at sourceforge.net Sat Mar 3 14:22:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Mar 2007 05:22:52 -0800 Subject: [ python-Bugs-1668295 ] Strange unicode behaviour Message-ID: Bugs item #1668295, was opened at 2007-02-25 12:10 Message generated for change (Comment added) made by sgala You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668295&group_id=5470 Please note that this 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 Private: No Submitted By: Santiago Gala (sgala) Assigned to: Nobody/Anonymous (nobody) Summary: Strange unicode behaviour Initial Comment: I know that python is very funny WRT unicode processing, but this defies all my knowledge. I use the es_ES.UTF-8 encoding on linux. The script: python -c "print unicode('? %s' % '??','utf8') " works, i.e., prints ? ?? in the next line. However, if I redirect it to less or to a file, like python -c "print unicode('? %s' % '??','utf8') " >test Traceback (most recent call last): File "", line 1, in ? UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0: ordinal not in range(128) Why is the behaviour different when stdout is redirected? How can I get it to do "the right thing" in both cases? ---------------------------------------------------------------------- >Comment By: Santiago Gala (sgala) Date: 2007-03-03 14:22 Message: Logged In: YES user_id=178886 Originator: YES >This is not magic. "print" looks for an "encoding" attribute on the file >it is printing to. This is the terminal encoding for sys.stdout and None >for other files. I'll correct you: "print" looks for an "encoding" attribute on the file it is printing to. This is the terminal encoding for sys.stdout *if sys.stdout is a terminal* and None when sys.stdout is not a terminal. After all, the bug reported is that *the same program* behaved different when used standalone than when piped to less: $ python -c "import sys; print sys.stdout.encoding" UTF-8 $ python -c "import sys; print sys.stdout.encoding" | cat None If you say that this is intended, not a bug, that an external process is altering the behavior of a python program, I'd just leave it written to warn other naive people like myself, that thinks that an external program should not influence python behavior (with *the same environment*): $ locale LANG=es_ES.UTF-8 LC_CTYPE="es_ES.UTF-8" LC_NUMERIC="es_ES.UTF-8" LC_TIME="es_ES.UTF-8" LC_COLLATE="es_ES.UTF-8" LC_MONETARY="es_ES.UTF-8" LC_MESSAGES="es_ES.UTF-8" LC_PAPER="es_ES.UTF-8" LC_NAME="es_ES.UTF-8" LC_ADDRESS="es_ES.UTF-8" LC_TELEPHONE="es_ES.UTF-8" LC_MEASUREMENT="es_ES.UTF-8" LC_IDENTIFICATION="es_ES.UTF-8" LC_ALL=es_ES.UTF-8 But I take it as a design flaw, and against all pythonic principles, probably coming from the fact that a lot of python developers/users are windows people that don't care about stdout at all. IMO, the behavior should be either: - use always None for sys.stdout - use always LC_CTYPE or LANG for sys.stdout I prefer the second one, as when I pipe stdout, after all, I expect it to be honoring my locale settings. Don't forget that the same person that types "|" after a call to python can type LC_ALL=blah before, while s/he can't sometimes modify the script because it is out of their permission set. The implementation logic would be simpler too, I guess. And more consistent with jython (it uses the second "always LC_CTYPE" solution). Not sure about iron-python or pypy. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-02-26 00:27 Message: Logged In: YES user_id=849994 Originator: NO > >>> sys.getfilesystemencoding() > 'UTF-8' > > so python is really dumb if print does not know my filesystemencoding, but > knows my terminal encoding. the file system encoding is the encoding of file names, not of file content. > I though breaking the least surprising behaviour was not considered > pythonic, and now you tell me that having a program running on console but > issuing an exception when redirected is intended. I would prefer an > exception in both cases. Or, even better, using > sys.getfilesystemencoding(), or allowing me to set defaultencoding() I agree that using the terminal encoding is perhaps a bit too DWIMish, but you can always get consistent results if you *do not write Unicode strings anywhere*. > Do you mean that I need to say print unicode(whatever).encode('utf8'), > like: > > >>> a = unicode('\xc3\xa1','utf8') # instead of '?', easy to read and > understand, even in files encoded as utf8. Assume this is a literal or > input No. You can directly put Unicode literals in your files, with u'...'. For that to work, you need to tell Python the encoding your file has, using the coding cookie (see the docs). > ... > >>> print unicode(a).encode('utf8') # because a could be a number, or a > different object > > every time, instead of "a='?'; print a" > Cool, I'm starting to really love it. Concise and pythonic > Are you seriously meaning that there is no way to tell print to use a > default encoding, and it will magically try to find it and fail for > everything not being a terminal? This is not magic. "print" looks for an "encoding" attribute on the file it is printing to. This is the terminal encoding for sys.stdout and None for other files. > Are you seriously telling me that this is not a bug? Even worse, that it > is "intended behaviour". BTW, jython acts differently about this, in all > the versions I tried. It *is* not a bug. This was implemented as a simplification for terminal output. > And with -S I am allowed to change the encoding, which is crippled in site > for no known good reason. > python -S -c "import sys; sys.setdefaultencoding('utf8'); print > unicode('\xc3\xa1','utf8')" >test > (works, test contains an accented a as intended Because setdefaultencoding() affects *every* conversion from unicode to string and from string to unicode, which can be very confusing if you have to handle different encodings. >>use Unicode everywhere inside the >>program, and byte strings for input and output. > Have you ever wondered that to use unicode everywhere inside the program, > one needs to decode literals (or input) to unicode (the next sentence you > complain about)? Yes, you have to decode input (for files, you can do this automatically if you use codecs.open(), not builtin open()). No, you don't have to decode literals as Unicode literals exist. > I follow this principle in my programming since about 6 years ago, so I'm > not a novice. I'm playing by the rules: > a) "decodes it to unicode" is the first step to get it into processing. > This is just a test case, so processing is zero. > b) I refuse to believe that the only way to ensure something to be printed > right is wrapping every item into unicode(var).encode('utf8') [The > redundant unicode call is because the var could be a number, or a different > object] No, that is of course not the only way. An alternative is to use an encoded file, as the codecs module offers. If you e.g. set sys.stdout = codecs.EncodedFile(sys.stdout, 'utf-8') you can print Unicode strings to stdout, and they will automatically be converted using utf-8. This is clear and explicit. > c) or making my code non portable by patching site.py to get a real > encoding instead of ascii. If you still cannot live without setdefaultencoding(), you can do reload(sys) to get a sys module with this method. Closing again. ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2007-02-25 23:27 Message: Logged In: YES user_id=178886 Originator: YES re: consistent, my experience it is that python unicode handling is consistently stupid, doing almost always the wrong thing. It remembers me of the defaults of WordPerfect, that were always exactly the opposite of what the user wanted 99% of time. I hope python 3000 comes fast and stops that real pain. I love the language, but the way it handles unicode provokes hundreds of bugs. >Python could correctly find out your terminal >encoding, the Unicode string is automatically encoded in that encoding. > >If you output to a file, Python does not know which encoding you want to >have, so all Unicode strings are converted to ascii only. >>> sys.getfilesystemencoding() 'UTF-8' so python is really dumb if print does not know my filesystemencoding, but knows my terminal encoding. I though breaking the least surprising behaviour was not considered pythonic, and now you tell me that having a program running on console but issuing an exception when redirected is intended. I would prefer an exception in both cases. Or, even better, using sys.getfilesystemencoding(), or allowing me to set defaultencoding() >Please direct further questions to the Python mailing list or newsgroup. I would if I didn't consider this behaviour a bug, and a serious one. >The basic rule when handling Unicode is: use Unicode everywhere inside the >program, and byte strings for input and output. >So, your code is exactly the other way round: it takes a byte string, >decodes it to unicode and *then* prints it. > >You should do it the other way: use Unicode literals in your code, and >when y(ou write something to a file, *encode* them in utf-8. Do you mean that I need to say print unicode(whatever).encode('utf8'), like: >>> a = unicode('\xc3\xa1','utf8') # instead of '?', easy to read and understand, even in files encoded as utf8. Assume this is a literal or input ... >>> print unicode(a).encode('utf8') # because a could be a number, or a different object every time, instead of "a='?'; print a" Cool, I'm starting to really love it. Concise and pythonic Are you seriously meaning that there is no way to tell print to use a default encoding, and it will magically try to find it and fail for everything not being a terminal? Are you seriously telling me that this is not a bug? Even worse, that it is "intended behaviour". BTW, jython acts differently about this, in all the versions I tried. And with -S I am allowed to change the encoding, which is crippled in site for no known good reason. python -S -c "import sys; sys.setdefaultencoding('utf8'); print unicode('\xc3\xa1','utf8')" >test (works, test contains an accented a as intended >use Unicode everywhere inside the >program, and byte strings for input and output. Have you ever wondered that to use unicode everywhere inside the program, one needs to decode literals (or input) to unicode (the next sentence you complain about)? >So, your code is exactly the other way round: it takes a byte string, >decodes it to unicode and *then* prints it. I follow this principle in my programming since about 6 years ago, so I'm not a novice. I'm playing by the rules: a) "decodes it to unicode" is the first step to get it into processing. This is just a test case, so processing is zero. b) I refuse to believe that the only way to ensure something to be printed right is wrapping every item into unicode(var).encode('utf8') [The redundant unicode call is because the var could be a number, or a different object] c) or making my code non portable by patching site.py to get a real encoding instead of ascii. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-02-25 20:43 Message: Logged In: YES user_id=849994 Originator: NO First of all: Python's Unicode handling is very consistent and straightforward, if you know the basics. Sadly, most people don't know the difference between Unicode and encoded strings. What you're seeing is not a bug, it is due to the fact that if you print Unicode to the console, and Python could correctly find out your terminal encoding, the Unicode string is automatically encoded in that encoding. If you output to a file, Python does not know which encoding you want to have, so all Unicode strings are converted to ascii only. Please direct further questions to the Python mailing list or newsgroup. The basic rule when handling Unicode is: use Unicode everywhere inside the program, and byte strings for input and output. So, your code is exactly the other way round: it takes a byte string, decodes it to unicode and *then* prints it. You should do it the other way: use Unicode literals in your code, and when you write something to a file, *encode* them in utf-8. ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2007-02-25 12:17 Message: Logged In: YES user_id=178886 Originator: YES Forgot to say that it happens consistently with 2.4.3, 2.5-svn and svn trunk Also, some people asks for repr of strings (I guess to reproduce if they can't read the caracters). Those are printed in utf-8: $python -c "print repr('? %s')" '\xc3\xa1 %s' $ python -c "print repr('?i')" '\xc3\xa9i' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668295&group_id=5470 From noreply at sourceforge.net Sun Mar 4 01:21:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Mar 2007 16:21:15 -0800 Subject: [ python-Feature Requests-1673203 ] add identity function Message-ID: Feature Requests item #1673203, was opened at 2007-03-04 00:21 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=1673203&group_id=5470 Please note that this 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 Private: No Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: add identity function Initial Comment: Requested and assigned to Raymond at his suggestion: http://groups.google.com/group/comp.lang.python/msg/603870361743c85c There should be an identify function identity(x)=x. I suggest it also take and ignore an optional second arg: identity(x1,x2)=x1. The second arg can be useful in some generator expressions: foo = (x for x in bar if condition(x) and identity(True, memoize(x)) That allows calling memoize (or some other function) on the selected elements in the genexp, and disposing of the returned value. It's sort of like the const function (K combinator) to go along with the identity function's I combinator. OK, the above is not really in the functional spirit, but it's been useful. There could conceivably be also an actual const function const(k)=partial(identity,k) but I can't remember needing that in Python code. The two-arg identity function (uncurried version of const) is probably enough. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 From noreply at sourceforge.net Sun Mar 4 01:21:35 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Mar 2007 16:21:35 -0800 Subject: [ python-Feature Requests-1673203 ] add identity function Message-ID: Feature Requests item #1673203, was opened at 2007-03-04 00:21 Message generated for change (Settings changed) made by phr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 Please note that this 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 Private: No Submitted By: paul rubin (phr) >Assigned to: Raymond Hettinger (rhettinger) Summary: add identity function Initial Comment: Requested and assigned to Raymond at his suggestion: http://groups.google.com/group/comp.lang.python/msg/603870361743c85c There should be an identify function identity(x)=x. I suggest it also take and ignore an optional second arg: identity(x1,x2)=x1. The second arg can be useful in some generator expressions: foo = (x for x in bar if condition(x) and identity(True, memoize(x)) That allows calling memoize (or some other function) on the selected elements in the genexp, and disposing of the returned value. It's sort of like the const function (K combinator) to go along with the identity function's I combinator. OK, the above is not really in the functional spirit, but it's been useful. There could conceivably be also an actual const function const(k)=partial(identity,k) but I can't remember needing that in Python code. The two-arg identity function (uncurried version of const) is probably enough. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 From noreply at sourceforge.net Sun Mar 4 12:51:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Mar 2007 03:51:23 -0800 Subject: [ python-Bugs-1673403 ] date-datetime comparison doesn't work Message-ID: Bugs item #1673403, was opened at 2007-03-04 11:51 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=1673403&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jon Ribbens (jribbens) Assigned to: Nobody/Anonymous (nobody) Summary: date-datetime comparison doesn't work Initial Comment: Summary: bug #1028306 was not a bug, but the fix for it introduced one Comparing a date to a datetime currently throws an exception. This makes no sense. In what way is: datetime(2006, 1, 1, 0, 0, 0) < date(2007, 1, 1) not a perfectly reasonable and well-defined comparison? Throwing an exception here violates the "Principle of Least Surprise" to a considerable degree. Obviously some slight ambiguity arises if the date and the datetime differ only in the time part. There are two sensible responses in this situation that I can see: Treat dates as if they have a time-part of midnight. This is my preferred solution, and it is already what the datetime module does, for example, when subtracting two dates. Treat dates as if they refer to the entire day, i.e. if the date and datetime differ only in the time part then they are equal. This is consistent but becomes confusing in other situations such as when subtracting dates. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673403&group_id=5470 From noreply at sourceforge.net Sun Mar 4 12:52:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Mar 2007 03:52:43 -0800 Subject: [ python-Bugs-1673405 ] None-datetime comparison doesn't work Message-ID: Bugs item #1673405, was opened at 2007-03-04 11:52 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=1673405&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jon Ribbens (jribbens) Assigned to: Nobody/Anonymous (nobody) Summary: None-datetime comparison doesn't work Initial Comment: Comparing None to the objects in the datetime module throws an exception. This violates the general rule in Python that None compares "less than" everything else. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673405&group_id=5470 From noreply at sourceforge.net Sun Mar 4 12:59:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Mar 2007 03:59:06 -0800 Subject: [ python-Bugs-1673409 ] datetime module missing some important methods Message-ID: Bugs item #1673409, was opened at 2007-03-04 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=105470&aid=1673409&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jon Ribbens (jribbens) Assigned to: Nobody/Anonymous (nobody) Summary: datetime module missing some important methods Initial Comment: The datetime module is missing some important methods for interacting with timestamps (i.e. seconds since 1970-01-01T00:00:00). There are methods to convert from a timestamp, i.e. date.fromtimestamp and datetime.fromtimestamp, but there are no methods to convert back. In addition, timedelta has no method for returning the number of seconds it represents (i.e. days*86400+seconds+microseconds/1000000). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673409&group_id=5470 From noreply at sourceforge.net Sun Mar 4 19:48:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Mar 2007 10:48:14 -0800 Subject: [ python-Bugs-1673405 ] None-datetime comparison doesn't work Message-ID: Bugs item #1673405, was opened at 2007-03-04 06:52 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673405&group_id=5470 Please note that this 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: Feature Request >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Jon Ribbens (jribbens) Assigned to: Nobody/Anonymous (nobody) Summary: None-datetime comparison doesn't work Initial Comment: Comparing None to the objects in the datetime module throws an exception. This violates the general rule in Python that None compares "less than" everything else. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2007-03-04 13:48 Message: Logged In: YES user_id=31435 Originator: NO There is no such rule, and it's quite deliberate that the newer types (like datetime objects and sets) raise an exception on mixed-type inequality comparisons. For older types, the result of inequality comparison with None isn't defined by the language, and the outcome does vary across CPython releases. Rejecting this, since the code is working as designed and documented (see, e.g., footnote (4) in the datetime docs: "Note: In order to stop comparison from falling back to the default scheme of comparing object addresses, datetime comparison normally raises TypeError if the other comparand isn't also a datetime object. However, ..."). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673405&group_id=5470 From noreply at sourceforge.net Mon Mar 5 03:34:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Mar 2007 18:34:13 -0800 Subject: [ python-Bugs-1673757 ] string and unicode formatting are missing a test for "G" Message-ID: Bugs item #1673757, was opened at 2007-03-04 21: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=1673757&group_id=5470 Please note that this 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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eric V. Smith (ericvsmith) Assigned to: Nobody/Anonymous (nobody) Summary: string and unicode formatting are missing a test for "G" Initial Comment: In stringobject.c and unicodeobject.c, the formatting codes for 'e', 'E', 'f', 'F', 'g', and 'G' all get routed to formatfloat(). formatfloat() is essentially identical in stringobject.c and unicodeobject.c. 'F' is mapped to 'f'. There is a test for excess precision for 'f' and 'g', but not one for 'G'. The "type == 'g'" test should be "(type == 'g' || type == 'G')". I assume this bug is in 2.5 and 2.6 as well, although I haven't verified that, yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&group_id=5470 From noreply at sourceforge.net Mon Mar 5 03:42:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Mar 2007 18:42:17 -0800 Subject: [ python-Bugs-1673757 ] string and unicode formatting are missing a test for "G" Message-ID: Bugs item #1673757, was opened at 2007-03-04 21:34 Message generated for change (Comment added) made by ericvsmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&group_id=5470 Please note that this 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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eric V. Smith (ericvsmith) Assigned to: Nobody/Anonymous (nobody) Summary: string and unicode formatting are missing a test for "G" Initial Comment: In stringobject.c and unicodeobject.c, the formatting codes for 'e', 'E', 'f', 'F', 'g', and 'G' all get routed to formatfloat(). formatfloat() is essentially identical in stringobject.c and unicodeobject.c. 'F' is mapped to 'f'. There is a test for excess precision for 'f' and 'g', but not one for 'G'. The "type == 'g'" test should be "(type == 'g' || type == 'G')". I assume this bug is in 2.5 and 2.6 as well, although I haven't verified that, yet. ---------------------------------------------------------------------- >Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-04 21:42 Message: Logged In: YES user_id=411198 Originator: YES This is the correct behavior: >>> '%200.200g' % 1.0 Traceback (most recent call last): File "", line 1, in ? OverflowError: formatted float is too long (precision too large?) But 'G' is handled differently: >>> '%200.200G' % 1.0 ' 1' 'G' should give the same OverflowError as 'g'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&group_id=5470 From noreply at sourceforge.net Mon Mar 5 03:47:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Mar 2007 18:47:17 -0800 Subject: [ python-Bugs-1673757 ] string and unicode formatting are missing a test for "G" Message-ID: Bugs item #1673757, was opened at 2007-03-04 21:34 Message generated for change (Comment added) made by ericvsmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&group_id=5470 Please note that this 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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eric V. Smith (ericvsmith) Assigned to: Nobody/Anonymous (nobody) Summary: string and unicode formatting are missing a test for "G" Initial Comment: In stringobject.c and unicodeobject.c, the formatting codes for 'e', 'E', 'f', 'F', 'g', and 'G' all get routed to formatfloat(). formatfloat() is essentially identical in stringobject.c and unicodeobject.c. 'F' is mapped to 'f'. There is a test for excess precision for 'f' and 'g', but not one for 'G'. The "type == 'g'" test should be "(type == 'g' || type == 'G')". I assume this bug is in 2.5 and 2.6 as well, although I haven't verified that, yet. ---------------------------------------------------------------------- >Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-04 21:47 Message: Logged In: YES user_id=411198 Originator: YES Patch for 3.0 is at http://python.org/sf/1673759 This should be checked in 2.5 and 2.6, but I don't have an environment to compile those. ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-04 21:42 Message: Logged In: YES user_id=411198 Originator: YES This is the correct behavior: >>> '%200.200g' % 1.0 Traceback (most recent call last): File "", line 1, in ? OverflowError: formatted float is too long (precision too large?) But 'G' is handled differently: >>> '%200.200G' % 1.0 ' 1' 'G' should give the same OverflowError as 'g'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&group_id=5470 From noreply at sourceforge.net Mon Mar 5 05:27:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Mar 2007 20:27:40 -0800 Subject: [ python-Bugs-1669498 ] 2.4.4 Logging LogRecord attributes broken Message-ID: Bugs item #1669498, was opened at 2007-02-26 15:18 Message generated for change (Settings changed) made by murrayg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669498&group_id=5470 Please note that this 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 Private: No Submitted By: Glenn Murray (murrayg) Assigned to: Vinay Sajip (vsajip) Summary: 2.4.4 Logging LogRecord attributes broken Initial Comment: The following module gives different results under 2.4.3 and 2.4.4 (running on Kubuntu, Dapper and Edgy releases, resp.) #!/usr/bin/env python import logging logger = logging.getLogger("MyLogger") logger.setLevel(logging.DEBUG) handler = logging.StreamHandler() format = "%(levelname)-8s %(module)s %(lineno)d %(message)s" handler.setFormatter(logging.Formatter(format)) logger.addHandler(handler) logger.info("Yo") On 2.4.3 I get INFO tmplogger 11 Yo On 2.4.4 I get INFO __init__ 1072 Yo The versions are Python 2.4.3 (#2, Oct 6 2006, 07:52:30) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 and Python 2.4.4c1 (#2, Oct 11 2006, 21:51:02) [GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)] on linux2 ---------------------------------------------------------------------- >Comment By: Glenn Murray (murrayg) Date: 2007-03-04 21:27 Message: Logged In: YES user_id=584266 Originator: YES Hi Vinay, Good call, recompiling the /usr/lib/python2.4/logging/*.pyc files fixed the problem. Thanks, Glenn ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2007-02-28 14:15 Message: Logged In: YES user_id=308438 Originator: NO Can you please delete all logging .pyc files before running the test script? The problem appears to be caused by the __file__ value stored inside a .pyc being different (possibly due to symlink changes) from the source file it was originally compiled from. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669498&group_id=5470 From noreply at sourceforge.net Mon Mar 5 11:03:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 02:03:49 -0800 Subject: [ python-Bugs-1647654 ] No obvious and correct way to get the time zone offset Message-ID: Bugs item #1647654, was opened at 2007-01-30 13:48 Message generated for change (Comment added) made by jhenstridge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1647654&group_id=5470 Please note that this 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 Private: No Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: No obvious and correct way to get the time zone offset Initial Comment: It would be nice if the Python time module provided an obvious way to get the local time UTC offset for an arbitrary time stamp. The existing constants included in the module are not sufficient to correctly determine this value. As context, the Bazaar version control system (written in Python), the local time UTC offset is recorded in a commit. The method used in releases prior to 0.14 made use of the "daylight", "timezone" and "altzone" constants from the time module like this: if time.localtime(t).tm_isdst and time.daylight: return -time.altzone else: return -time.timezone This worked most of the time, but would occasionally give incorrect results. On Linux, the local time system can handle different daylight saving rules for different spans of years. For years where the rules change, these constants can provide incorrect data. Furthermore, they may be incorrect for time stamps in the past. I personally ran into this problem last December when Western Australia adopted daylight saving -- time.altzone gave an incorrect value until the start of 2007. Having a function in the standard library to calculate this offset would solve the problem. The implementation we ended up with for Bazaar was: offset = datetime.fromtimestamp(t) - datetime.utcfromtimestamp(t) return offset.days * 86400 + offset.seconds Another alternative would be to expose tm_gmtoff on time tuples (perhaps using the above code to synthesise it on platforms that don't have the field). ---------------------------------------------------------------------- >Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 18:03 Message: Logged In: YES user_id=146903 Originator: YES In Western Australia, a 3 year daylight saving trial was introduced starting on 3rd December 2006. Prior to that, we had no daylight saving shifts (the previous time we had daylight saving was 15 years ago in another trial). Since there was no daylight savings for 1st January 2006 and 1st July 2006, time.timezone and time.altzone were both equal to -28800 (UTC+8) for Python interpreters run in 2006. I am sure that I had the tzdata updates installed: my computer displayed the correct time, and listed the UTC offset as +0900 in December. Creating a time tuple for a date in December 2006 had the tm_isdst flag set to 1. If I was programming this in C, I'd use the tm_gmtoff field of "struct tm" if it was available. On platforms that don't provide tm_gmtoff, other platform specific methods would be needed (e.g. using timezone/altzone). The other alternative is to do date arithmetic on the results of localtime() and gmtime(), as you say. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 23:48 Message: Logged In: YES user_id=6380 Originator: NO Hm.... I'm not sure I understand why the first bit of code didn't work. Can you give a concrete example? (I.e. what was t, what was returned by localtime(t), and what were the three time variables that day.) I don't know the details of Western Australia's DST change. But looking at the source of timemodule.c, I notice that it simply samples the timezone on Jan 1st and July 1st, and if they differ, decides which one is summer time by which one is smaller. Your remark that the problem righted itself in January makes me wonder -- between what dates did you have DST? Alternatively, it could be that your system simply didn't have the correct DST change data loaded yet (this happens all the time when governments change the rules). Can you rule that out? I really don't want to have to change Python in order to correct for *that* problem. Yet another question, if you were to code this in C, how would you write it? Regardless, I think that it would be useful to support tm_gmtoff and other struct tm entries, the same way that we do this in struct stat. You could probably also get the correct result (assuming your system's timezone database is correct) by comparing localtime() and gmtime(). But the reverse engineering is a bit painful; your trick using datetime essentially does that. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2007-03-01 18:09 Message: Logged In: YES user_id=146903 Originator: YES The localtime_tz() function sounds like it would probably fit the bill. Another option would be to expose tm_gmtoff and tm_zone as non-sequence fields of time.struct_time for systems that support them. This would provide the data without needing new APIs. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-02-24 08:31 Message: Logged In: YES user_id=226443 Originator: NO See patch #1667546 for a time module function returning extended time tuples. The datetime-based solution you provide is quite a clever workaround using "naive" datetime objects, but I'm inclined to think that some more convenient way of getting "aware" datetime objects would be nicer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1647654&group_id=5470 From noreply at sourceforge.net Mon Mar 5 11:23:35 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 02:23:35 -0800 Subject: [ python-Bugs-1646728 ] datetime.fromtimestamp fails with negative fractional times Message-ID: Bugs item #1646728, was opened at 2007-01-29 10:21 Message generated for change (Comment added) made by jhenstridge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.fromtimestamp fails with negative fractional times Initial Comment: The datetime.fromtimestamp() function works fine with integer timestamps and positive fractional timestamps, but fails if I pass a negative fractional timestamp. For example: >>> import datetime >>> datetime.datetime.fromtimestamp(-1.05) Traceback (most recent call last): File "", line 1, in ValueError: microsecond must be in 0..999999 It should return the same result as datetime.fromtimestamp(-1) - timedelta(seconds=.5). The same bug can be triggered in datetime.utcfromtimestamp(). I have been able to reproduce this bug in Python 2.4.4 and Python 2.5 on Linux. ---------------------------------------------------------------------- >Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 18:23 Message: Logged In: YES user_id=146903 Originator: YES The problem seems to be in datetime_from_timestamp() from datetimemodule.c. It should probably be checking to see whether the microseconds value it calculates is negative, and adjust "timet" and "us" accordingly if so. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-03 00:05 Message: Logged In: YES user_id=6380 Originator: NO Looks like a bug in the conversion from floats to ints. Anyone care to track it down more precisely? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 From noreply at sourceforge.net Mon Mar 5 12:24:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 03:24:09 -0800 Subject: [ python-Bugs-1669498 ] 2.4.4 Logging LogRecord attributes broken Message-ID: Bugs item #1669498, was opened at 2007-02-26 22:18 Message generated for change (Settings changed) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669498&group_id=5470 Please note that this 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: None Priority: 5 Private: No Submitted By: Glenn Murray (murrayg) Assigned to: Vinay Sajip (vsajip) Summary: 2.4.4 Logging LogRecord attributes broken Initial Comment: The following module gives different results under 2.4.3 and 2.4.4 (running on Kubuntu, Dapper and Edgy releases, resp.) #!/usr/bin/env python import logging logger = logging.getLogger("MyLogger") logger.setLevel(logging.DEBUG) handler = logging.StreamHandler() format = "%(levelname)-8s %(module)s %(lineno)d %(message)s" handler.setFormatter(logging.Formatter(format)) logger.addHandler(handler) logger.info("Yo") On 2.4.3 I get INFO tmplogger 11 Yo On 2.4.4 I get INFO __init__ 1072 Yo The versions are Python 2.4.3 (#2, Oct 6 2006, 07:52:30) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 and Python 2.4.4c1 (#2, Oct 11 2006, 21:51:02) [GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)] on linux2 ---------------------------------------------------------------------- Comment By: Glenn Murray (murrayg) Date: 2007-03-05 04:27 Message: Logged In: YES user_id=584266 Originator: YES Hi Vinay, Good call, recompiling the /usr/lib/python2.4/logging/*.pyc files fixed the problem. Thanks, Glenn ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2007-02-28 21:15 Message: Logged In: YES user_id=308438 Originator: NO Can you please delete all logging .pyc files before running the test script? The problem appears to be caused by the __file__ value stored inside a .pyc being different (possibly due to symlink changes) from the source file it was originally compiled from. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669498&group_id=5470 From noreply at sourceforge.net Mon Mar 5 14:33:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 05:33:33 -0800 Subject: [ python-Feature Requests-1674032 ] Make threading.Event().wait(timeout=3) return isSet Message-ID: Feature Requests item #1674032, was opened at 2007-03-05 15:33 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=1674032&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Fraser (davidfraser) Assigned to: Nobody/Anonymous (nobody) Summary: Make threading.Event().wait(timeout=3) return isSet Initial Comment: Currently the wait method on threading.Event always returns None, even if a timeout is given and the event is not set. This means that there is no way to determine whether the wait method returned because the event was set, or because the timeout period expired, without querying the event status again: x.wait(3) if x.isSet(): # do stuff Note that in the above case, the event could be cleared between the return from x.wait and the execution of x.isSet (in another thread), and so this would operate as though x.wait had just timed out It would be great to be able to do: if x.wait(3): # do stuff This should also not affect any existing code as it shouldn't be relying on the return value from x.wait anyway ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1674032&group_id=5470 From noreply at sourceforge.net Mon Mar 5 15:21:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 06:21:33 -0800 Subject: [ python-Feature Requests-1673203 ] add identity function Message-ID: Feature Requests item #1673203, was opened at 2007-03-03 19:21 Message generated for change (Comment added) made by belopolsky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 Please note that this 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 Private: No Submitted By: paul rubin (phr) Assigned to: Raymond Hettinger (rhettinger) Summary: add identity function Initial Comment: Requested and assigned to Raymond at his suggestion: http://groups.google.com/group/comp.lang.python/msg/603870361743c85c There should be an identify function identity(x)=x. I suggest it also take and ignore an optional second arg: identity(x1,x2)=x1. The second arg can be useful in some generator expressions: foo = (x for x in bar if condition(x) and identity(True, memoize(x)) That allows calling memoize (or some other function) on the selected elements in the genexp, and disposing of the returned value. It's sort of like the const function (K combinator) to go along with the identity function's I combinator. OK, the above is not really in the functional spirit, but it's been useful. There could conceivably be also an actual const function const(k)=partial(identity,k) but I can't remember needing that in Python code. The two-arg identity function (uncurried version of const) is probably enough. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 09:21 Message: Logged In: YES user_id=835142 Originator: NO 1. If this proposal is accepted, it will make sense to deprecate the use of None as an identity function in map: >>> map(None, range(10)) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] 2. Some other languages have an dyadic identity function that returns the *second* argument. For example, K has : primitive: identity:(:) identity[1;2] 2 The rationale in K is that it is useful in an ammed function that replaces entries of an an array with a result of a dyadic function applied to the old and the supplied value and it is natural to have old value first: @[1 2 3;1;-;20] 1 -18 3 @[1 2 3;1;:;20] 1 20 3 This rationale does not apply to Python, but in the absence of other reasons to choose the order of arguments, Python may as well follow the precedent. Does anyone know a less exotic language that has a dyadic identity? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 From noreply at sourceforge.net Mon Mar 5 17:38:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 08:38:42 -0800 Subject: [ python-Bugs-1672332 ] cPickle can pickle, but cannot unpickle on 64bit machines Message-ID: Bugs item #1672332, was opened at 2007-03-02 12:10 Message generated for change (Comment added) made by sgala You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672332&group_id=5470 Please note that this 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 Private: No Submitted By: Bartlomiej Ogryczak (oneg) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle can pickle, but cannot unpickle on 64bit machines Initial Comment: Seems that on 64-bit machines cPickle is able to pickle floats smaller then DBL_MIN, but it's unable to unpickle them. 64-bit machine (Solaris 10 on Sparc) Python 2.4.4 (#1, Oct 26 2006, 10:01:37) [GCC 3.3.4] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import cPickle >>> cPickle.dumps(1e-310) 'F9.9999999999999694e-311\n.' >>> cPickle.loads(_) Traceback (most recent call last): File "", line 1, in ? ValueError: could not convert string to float Same thing works fine on 32-bit machine (P4 with MS Windows) Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import cPickle >>> cPickle.dumps(1e-310) 'F0\n.' >>> ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2007-03-05 17:38 Message: Logged In: YES user_id=178886 Originator: NO FYI: it doesn't happen for me in python 2.4.3, 2.5svn and 2.6svn built on linux (x86_64) with gcc-4.1.2, so it looks compiler version or hw platform specific. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672332&group_id=5470 From noreply at sourceforge.net Mon Mar 5 17:49:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 08:49:38 -0800 Subject: [ python-Bugs-1672332 ] cPickle can pickle, but cannot unpickle on 64bit machines Message-ID: Bugs item #1672332, was opened at 2007-03-02 12:10 Message generated for change (Comment added) made by oneg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672332&group_id=5470 Please note that this 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 Private: No Submitted By: Bartlomiej Ogryczak (oneg) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle can pickle, but cannot unpickle on 64bit machines Initial Comment: Seems that on 64-bit machines cPickle is able to pickle floats smaller then DBL_MIN, but it's unable to unpickle them. 64-bit machine (Solaris 10 on Sparc) Python 2.4.4 (#1, Oct 26 2006, 10:01:37) [GCC 3.3.4] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import cPickle >>> cPickle.dumps(1e-310) 'F9.9999999999999694e-311\n.' >>> cPickle.loads(_) Traceback (most recent call last): File "", line 1, in ? ValueError: could not convert string to float Same thing works fine on 32-bit machine (P4 with MS Windows) Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import cPickle >>> cPickle.dumps(1e-310) 'F0\n.' >>> ---------------------------------------------------------------------- >Comment By: Bartlomiej Ogryczak (oneg) Date: 2007-03-05 17:49 Message: Logged In: YES user_id=1733256 Originator: YES I forgot to specify, it's 32-bit Python binary. I'm guessing yours is 64-bit binary on 64-bit system? Some additional info: gcc --version gcc (GCC) 3.3.4 $ file `which python` ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped $ ldd `which python` libresolv.so.2 => /usr/lib/libresolv.so.2 libsocket.so.1 => /usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 librt.so.1 => /usr/lib/librt.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libstdc++.so.5 => /usr/local/lib/libstdc++.so.5 libm.so.2 => /usr/lib/libm.so.2 libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 libc.so.1 => /usr/lib/libc.so.1 libmp.so.2 => /usr/lib/libmp.so.2 libmd5.so.1 => /usr/lib/libmd5.so.1 libscf.so.1 => /usr/lib/libscf.so.1 libaio.so.1 => /usr/lib/libaio.so.1 libdoor.so.1 => /usr/lib/libdoor.so.1 libuutil.so.1 => /usr/lib/libuutil.so.1 /platform/SUNW,Sun-Fire-15000/lib/libc_psr.so.1 /platform/SUNW,Sun-Fire-15000/lib/libmd5_psr.so.1 ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2007-03-05 17:38 Message: Logged In: YES user_id=178886 Originator: NO FYI: it doesn't happen for me in python 2.4.3, 2.5svn and 2.6svn built on linux (x86_64) with gcc-4.1.2, so it looks compiler version or hw platform specific. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672332&group_id=5470 From noreply at sourceforge.net Mon Mar 5 18:11:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 09:11:09 -0800 Subject: [ python-Bugs-1674223 ] Unicode xmlcharrefreplace produces backslash not xml style. Message-ID: Bugs item #1674223, was opened at 2007-03-05 09: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=1674223&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stanley Sokolow (odontomatix) Assigned to: Nobody/Anonymous (nobody) Summary: Unicode xmlcharrefreplace produces backslash not xml style. Initial Comment: In Python 2.4.2 and 2.5, and maybe other versions too, the unicode string encoder for producing xml style unicode output (example, © for copyright symbol) produces the wrong style -- it produces backslash encoding (\xa9 for same copyright unicode character). Example at Python shell: u'\u2122'.encode('unicode_escape','xmlcharrefreplace') should produce: ™ but it produces \u2122 The same happens when it is used in a program. The print output of the encoded unicode contains backslash encodings as though the method 'backslashreplace' had been used. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1674223&group_id=5470 From noreply at sourceforge.net Mon Mar 5 18:54:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 09:54:51 -0800 Subject: [ python-Bugs-1674223 ] Unicode xmlcharrefreplace produces backslash not xml style. Message-ID: Bugs item #1674223, was opened at 2007-03-05 18:11 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1674223&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Stanley Sokolow (odontomatix) Assigned to: Nobody/Anonymous (nobody) Summary: Unicode xmlcharrefreplace produces backslash not xml style. Initial Comment: In Python 2.4.2 and 2.5, and maybe other versions too, the unicode string encoder for producing xml style unicode output (example, © for copyright symbol) produces the wrong style -- it produces backslash encoding (\xa9 for same copyright unicode character). Example at Python shell: u'\u2122'.encode('unicode_escape','xmlcharrefreplace') should produce: ™ but it produces \u2122 The same happens when it is used in a program. The print output of the encoded unicode contains backslash encodings as though the method 'backslashreplace' had been used. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2007-03-05 18:54 Message: Logged In: YES user_id=89016 Originator: NO u'\u2122'.encode('unicode_escape','xmlcharrefreplace') produces \u2122 because that's the way the unicode_escape codec outputs unicode codepoints. For unicode_escape the xmlcharrefreplace error handler never kicks in. If you want the error handler to kick in, you have to use an encoding that doesn't support the character you want to encode. The best candidate is probably ascii: >>> u"\u2122".encode("ascii", "xmlcharrefreplace") >>> '™' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1674223&group_id=5470 From noreply at sourceforge.net Mon Mar 5 19:38:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 10:38:26 -0800 Subject: [ python-Bugs-1646728 ] datetime.fromtimestamp fails with negative fractional times Message-ID: Bugs item #1646728, was opened at 2007-01-28 21:21 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.fromtimestamp fails with negative fractional times Initial Comment: The datetime.fromtimestamp() function works fine with integer timestamps and positive fractional timestamps, but fails if I pass a negative fractional timestamp. For example: >>> import datetime >>> datetime.datetime.fromtimestamp(-1.05) Traceback (most recent call last): File "", line 1, in ValueError: microsecond must be in 0..999999 It should return the same result as datetime.fromtimestamp(-1) - timedelta(seconds=.5). The same bug can be triggered in datetime.utcfromtimestamp(). I have been able to reproduce this bug in Python 2.4.4 and Python 2.5 on Linux. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-05 13:38 Message: Logged In: YES user_id=6380 Originator: NO Attached is a fix. If this is to your liking I'll check it in. File Added: datetime.patch ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 05:23 Message: Logged In: YES user_id=146903 Originator: YES The problem seems to be in datetime_from_timestamp() from datetimemodule.c. It should probably be checking to see whether the microseconds value it calculates is negative, and adjust "timet" and "us" accordingly if so. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 11:05 Message: Logged In: YES user_id=6380 Originator: NO Looks like a bug in the conversion from floats to ints. Anyone care to track it down more precisely? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 From noreply at sourceforge.net Mon Mar 5 20:31:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 11:31:55 -0800 Subject: [ python-Feature Requests-1674315 ] funcName and module incorrectly reported in logging Message-ID: Feature Requests item #1674315, was opened at 2007-03-05 11: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=1674315&group_id=5470 Please note that this 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 Private: No Submitted By: Michael Garvin (wraithgar) Assigned to: Nobody/Anonymous (nobody) Summary: funcName and module incorrectly reported in logging Initial Comment: When using logging.log, the funcName is always reported as _log, and the module is always reported as __init__ This is using python2.5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1674315&group_id=5470 From noreply at sourceforge.net Mon Mar 5 20:58:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 11:58:17 -0800 Subject: [ python-Feature Requests-1674315 ] funcName and module incorrectly reported in logging Message-ID: Feature Requests item #1674315, was opened at 2007-03-05 11:31 Message generated for change (Comment added) made by wraithgar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1674315&group_id=5470 Please note that this 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 Private: No Submitted By: Michael Garvin (wraithgar) Assigned to: Nobody/Anonymous (nobody) Summary: funcName and module incorrectly reported in logging Initial Comment: When using logging.log, the funcName is always reported as _log, and the module is always reported as __init__ This is using python2.5 ---------------------------------------------------------------------- >Comment By: Michael Garvin (wraithgar) Date: 2007-03-05 11:58 Message: Logged In: YES user_id=725363 Originator: YES info from logging/__init.py file being used: __author__ = "Vinay Sajip " __status__ = "production" __version__ = "0.4.9.9" __date__ = "06 February 2006" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1674315&group_id=5470 From noreply at sourceforge.net Mon Mar 5 21:28:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 12:28:33 -0800 Subject: [ python-Feature Requests-1674315 ] funcName and module incorrectly reported in logging Message-ID: Feature Requests item #1674315, was opened at 2007-03-05 11:31 Message generated for change (Comment added) made by wraithgar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1674315&group_id=5470 Please note that this 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 Private: No Submitted By: Michael Garvin (wraithgar) Assigned to: Nobody/Anonymous (nobody) Summary: funcName and module incorrectly reported in logging Initial Comment: When using logging.log, the funcName is always reported as _log, and the module is always reported as __init__ This is using python2.5 ---------------------------------------------------------------------- >Comment By: Michael Garvin (wraithgar) Date: 2007-03-05 12:28 Message: Logged In: YES user_id=725363 Originator: YES this appears to be a dirty logging/__init__.pyc file in the debian package. Removing that file fixes this problem. ---------------------------------------------------------------------- Comment By: Michael Garvin (wraithgar) Date: 2007-03-05 11:58 Message: Logged In: YES user_id=725363 Originator: YES info from logging/__init.py file being used: __author__ = "Vinay Sajip " __status__ = "production" __version__ = "0.4.9.9" __date__ = "06 February 2006" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1674315&group_id=5470 From noreply at sourceforge.net Mon Mar 5 22:45:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 13:45:01 -0800 Subject: [ python-Feature Requests-1674315 ] funcName and module incorrectly reported in logging Message-ID: Feature Requests item #1674315, was opened at 2007-03-05 19:31 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1674315&group_id=5470 Please note that this 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: None Priority: 5 Private: No Submitted By: Michael Garvin (wraithgar) Assigned to: Nobody/Anonymous (nobody) Summary: funcName and module incorrectly reported in logging Initial Comment: When using logging.log, the funcName is always reported as _log, and the module is always reported as __init__ This is using python2.5 ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-05 21:45 Message: Logged In: YES user_id=849994 Originator: NO Closing here then, you may want to file a bug (or search if someone else already did) in Debian's tracker. ---------------------------------------------------------------------- Comment By: Michael Garvin (wraithgar) Date: 2007-03-05 20:28 Message: Logged In: YES user_id=725363 Originator: YES this appears to be a dirty logging/__init__.pyc file in the debian package. Removing that file fixes this problem. ---------------------------------------------------------------------- Comment By: Michael Garvin (wraithgar) Date: 2007-03-05 19:58 Message: Logged In: YES user_id=725363 Originator: YES info from logging/__init.py file being used: __author__ = "Vinay Sajip " __status__ = "production" __version__ = "0.4.9.9" __date__ = "06 February 2006" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1674315&group_id=5470 From noreply at sourceforge.net Mon Mar 5 22:46:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 13:46:15 -0800 Subject: [ python-Bugs-1672332 ] cPickle can pickle, but cannot unpickle on 64bit machines Message-ID: Bugs item #1672332, was opened at 2007-03-02 11:10 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672332&group_id=5470 Please note that this 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 Private: No Submitted By: Bartlomiej Ogryczak (oneg) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle can pickle, but cannot unpickle on 64bit machines Initial Comment: Seems that on 64-bit machines cPickle is able to pickle floats smaller then DBL_MIN, but it's unable to unpickle them. 64-bit machine (Solaris 10 on Sparc) Python 2.4.4 (#1, Oct 26 2006, 10:01:37) [GCC 3.3.4] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import cPickle >>> cPickle.dumps(1e-310) 'F9.9999999999999694e-311\n.' >>> cPickle.loads(_) Traceback (most recent call last): File "", line 1, in ? ValueError: could not convert string to float Same thing works fine on 32-bit machine (P4 with MS Windows) Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import cPickle >>> cPickle.dumps(1e-310) 'F0\n.' >>> ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-05 21:46 Message: Logged In: YES user_id=849994 Originator: NO I seem to remember that float pickling has been overhauled for 2.5, could you try with a 2.5 Python and report the results? ---------------------------------------------------------------------- Comment By: Bartlomiej Ogryczak (oneg) Date: 2007-03-05 16:49 Message: Logged In: YES user_id=1733256 Originator: YES I forgot to specify, it's 32-bit Python binary. I'm guessing yours is 64-bit binary on 64-bit system? Some additional info: gcc --version gcc (GCC) 3.3.4 $ file `which python` ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped $ ldd `which python` libresolv.so.2 => /usr/lib/libresolv.so.2 libsocket.so.1 => /usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 librt.so.1 => /usr/lib/librt.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libstdc++.so.5 => /usr/local/lib/libstdc++.so.5 libm.so.2 => /usr/lib/libm.so.2 libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 libc.so.1 => /usr/lib/libc.so.1 libmp.so.2 => /usr/lib/libmp.so.2 libmd5.so.1 => /usr/lib/libmd5.so.1 libscf.so.1 => /usr/lib/libscf.so.1 libaio.so.1 => /usr/lib/libaio.so.1 libdoor.so.1 => /usr/lib/libdoor.so.1 libuutil.so.1 => /usr/lib/libuutil.so.1 /platform/SUNW,Sun-Fire-15000/lib/libc_psr.so.1 /platform/SUNW,Sun-Fire-15000/lib/libmd5_psr.so.1 ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2007-03-05 16:38 Message: Logged In: YES user_id=178886 Originator: NO FYI: it doesn't happen for me in python 2.4.3, 2.5svn and 2.6svn built on linux (x86_64) with gcc-4.1.2, so it looks compiler version or hw platform specific. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672332&group_id=5470 From noreply at sourceforge.net Mon Mar 5 23:14:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 14:14:51 -0800 Subject: [ python-Bugs-1633621 ] curses should reset curses.{COLS, LINES} when term. resized Message-ID: Bugs item #1633621, was opened at 2007-01-11 18:38 Message generated for change (Comment added) made by geekmug You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633621&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 3 Private: No Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: curses should reset curses.{COLS,LINES} when term. resized Initial Comment: [forwarded from http://bugs.debian.org/366698] The curses module does not reset curses.COLS and curses.LINES when the terminal is resized. ---------------------------------------------------------------------- Comment By: Scott Dial (geekmug) Date: 2007-03-05 17:14 Message: Logged In: YES user_id=383208 Originator: NO I've reviewed this patch and I believe it to be the correct patch. I believe it would be prudent to add a test case for this. I'm unable to attach, but here is a link to a patch for that: http://scottdial.com/python-dev/curses-test.patch ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2007-02-12 13:59 Message: Logged In: YES user_id=89016 Originator: NO Here's a patch that implements the requested changes. File Added: diff.txt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633621&group_id=5470 From noreply at sourceforge.net Tue Mar 6 00:38:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 15:38:25 -0800 Subject: [ python-Bugs-1674503 ] execfile() response to syntax errors Message-ID: Bugs item #1674503, was opened at 2007-03-05 16: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=1674503&group_id=5470 Please note that this 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 Private: No Submitted By: Jonathan Griffitts (jcgriffitts) Assigned to: Nobody/Anonymous (nobody) Summary: execfile() response to syntax errors Initial Comment: Python 2.5 seems to have an anomaly when execfile() encounters syntax errors. If I use execfile() to execute a file that contains a syntax error, it throws the expected SyntaxError exception but does not close the source file. Since the file is still open, an external program can't modify it to fix the syntax error. I have noticed this problem in Python 2.5 on Windows 2000 and Windows XP. I tried to reproduce it on Python 2.3 on BSD Unix but it didn't seem to happen there. ---------------- spam.py --------------------- [intentional-syntax-error) ---------------------------------------------- The following is my console session: ---------------------------------------------- Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> execfile('spam.py') Traceback (most recent call last): File "", line 1, in File "spam.py", line 1 [intentional-syntax-error) ^ SyntaxError: invalid syntax >>> ---------------------------------------------- At this point file spam.py remains open until Python exits. There's no obvious way to close the file from within the script because there is no file object. Under Windows, this prevents spam.py from being edited, renamed, or deleted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1674503&group_id=5470 From noreply at sourceforge.net Tue Mar 6 01:03:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 16:03:20 -0800 Subject: [ python-Bugs-1646728 ] datetime.fromtimestamp fails with negative fractional times Message-ID: Bugs item #1646728, was opened at 2007-01-29 10:21 Message generated for change (Comment added) made by jhenstridge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.fromtimestamp fails with negative fractional times Initial Comment: The datetime.fromtimestamp() function works fine with integer timestamps and positive fractional timestamps, but fails if I pass a negative fractional timestamp. For example: >>> import datetime >>> datetime.datetime.fromtimestamp(-1.05) Traceback (most recent call last): File "", line 1, in ValueError: microsecond must be in 0..999999 It should return the same result as datetime.fromtimestamp(-1) - timedelta(seconds=.5). The same bug can be triggered in datetime.utcfromtimestamp(). I have been able to reproduce this bug in Python 2.4.4 and Python 2.5 on Linux. ---------------------------------------------------------------------- >Comment By: James Henstridge (jhenstridge) Date: 2007-03-06 08:03 Message: Logged In: YES user_id=146903 Originator: YES I just tried the patch, and can confirm that it fixes the problem with datetime.fromtimestamp() and datetime.utcfromtimestamp(). The logic in the patch looks correct. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 02:38 Message: Logged In: YES user_id=6380 Originator: NO Attached is a fix. If this is to your liking I'll check it in. File Added: datetime.patch ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 18:23 Message: Logged In: YES user_id=146903 Originator: YES The problem seems to be in datetime_from_timestamp() from datetimemodule.c. It should probably be checking to see whether the microseconds value it calculates is negative, and adjust "timet" and "us" accordingly if so. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-03 00:05 Message: Logged In: YES user_id=6380 Originator: NO Looks like a bug in the conversion from floats to ints. Anyone care to track it down more precisely? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 From noreply at sourceforge.net Tue Mar 6 02:17:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 17:17:54 -0800 Subject: [ python-Bugs-1674503 ] execfile() response to syntax errors Message-ID: Bugs item #1674503, was opened at 2007-03-05 16:38 Message generated for change (Comment added) made by jcgriffitts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1674503&group_id=5470 Please note that this 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: 3 Private: No Submitted By: Jonathan Griffitts (jcgriffitts) Assigned to: Nobody/Anonymous (nobody) Summary: execfile() response to syntax errors Initial Comment: Python 2.5 seems to have an anomaly when execfile() encounters syntax errors. If I use execfile() to execute a file that contains a syntax error, it throws the expected SyntaxError exception but does not close the source file. Since the file is still open, an external program can't modify it to fix the syntax error. I have noticed this problem in Python 2.5 on Windows 2000 and Windows XP. I tried to reproduce it on Python 2.3 on BSD Unix but it didn't seem to happen there. ---------------- spam.py --------------------- [intentional-syntax-error) ---------------------------------------------- The following is my console session: ---------------------------------------------- Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> execfile('spam.py') Traceback (most recent call last): File "", line 1, in File "spam.py", line 1 [intentional-syntax-error) ^ SyntaxError: invalid syntax >>> ---------------------------------------------- At this point file spam.py remains open until Python exits. There's no obvious way to close the file from within the script because there is no file object. Under Windows, this prevents spam.py from being edited, renamed, or deleted. ---------------------------------------------------------------------- >Comment By: Jonathan Griffitts (jcgriffitts) Date: 2007-03-05 18:17 Message: Logged In: YES user_id=796443 Originator: YES Easy work-around: use exec(file('spam.py')) instead of execfile('spam.py') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1674503&group_id=5470 From noreply at sourceforge.net Tue Mar 6 02:37:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 17:37:07 -0800 Subject: [ python-Bugs-1674555 ] Python 2.5 testsuite sys.path contains system dirs Message-ID: Bugs item #1674555, was opened at 2007-03-06 01: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=1674555&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Theodoros V. Kalamatianos (nyb) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.5 testsuite sys.path contains system dirs Initial Comment: While trying to debug a testsuite crash, I discovered that a faulty module from the system wide directories was being picked up. The module in question was sgmlop.so, which was being imported by Lib/xmlrpclib.py. (BTW isn't it considered bad form for a module within the Python distribution to load a third party module?) In my opinion, the main issue here is that while testing a Python build, no out-of-tree modules should be able to be imported in any case, in order to avoid pollution of the testing environment. Yet AFAICT, there is no place where the sys.path is manipulated to remove the out-of-tree directories. I believe that the proper thing to do would be to allow only the build tree module directories in the search path. Any comments/patches would be appreciated. Best Regards, Theodoros Kalamatianos ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1674555&group_id=5470 From noreply at sourceforge.net Tue Mar 6 04:20:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 5 Mar 2007 19:20:11 -0800 Subject: [ python-Bugs-1663392 ] PyType_IsSubtype segfaults Message-ID: <200703060320.l263KBPi016088@sc8-sf-db2-new-b.sourceforge.net> Bugs item #1663392, was opened at 2007-02-19 03:42 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1663392&group_id=5470 Please note that this 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: Invalid Priority: 5 Private: No Submitted By: navtej singh (nsbuttar) Assigned to: Nobody/Anonymous (nobody) Summary: PyType_IsSubtype segfaults Initial Comment: It seems the issue is similar to bug#560215. I was not able to reopen the last bug so I have opened a new one. I am using an external python extension which seems to be buggy. I am still investigating the actual cause of the bug in the said extension library. PyType_IsSubType segfault reason is NULL pointer derefrence @ PyType_IsSubtype (a=0x0, b=0xb7f1ea00) attaching the gdb bt as attachment. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-03-05 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-02-19 04:21 Message: Logged In: YES user_id=849994 Originator: NO I don't think this is a bug in the core. Most Python API functions may not be passed NULL pointers; it is expected that the user of the function checks for that condition. ---------------------------------------------------------------------- Comment By: navtej singh (nsbuttar) Date: 2007-02-19 03:46 Message: Logged In: YES user_id=847825 Originator: YES Additional Information cat /etc/gentoo-release ; uname -r; python -V Gentoo Base System release 1.12.9 2.6.19-suspend2-r2 Python 2.4.4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1663392&group_id=5470 From noreply at sourceforge.net Tue Mar 6 07:38:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 22:38:50 -0800 Subject: [ python-Feature Requests-1043446 ] Interpreter should be interruptable everywhere Message-ID: Feature Requests item #1043446, was opened at 2004-10-08 23:26 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1043446&group_id=5470 Please note that this 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: None Priority: 3 Private: No Submitted By: Jp Calderone (kuran) Assigned to: Raymond Hettinger (rhettinger) Summary: Interpreter should be interruptable everywhere Initial Comment: import itertools list(itertools.repeat('x')) ^C will not interrupt this. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-10-12 07:40 Message: Logged In: YES user_id=849994 Turning into a feature request. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 17:15 Message: Logged In: YES user_id=1188172 What to do here? ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-10-15 17:25 Message: Logged In: YES user_id=593130 Killing the interpreter will, of course, interrupt anything ;-). The ability to ask the interpreter, via an alternate non-code communication channel, to stop doing what one just requested via the normal code input channel, is an implementation-specific metafeature independent of the language definition. So I see this as a CPython feature- expansion request rather than a bug report. If the CPython interpreter documentation promises that ^C or whatever will always grab the interpreter's attention, then that overpromise is a bug that should be modified. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-10 03:06 Message: Logged In: YES user_id=80475 FWIW, there are many variations of this theme using almost anything accepting an iterable input (dict.fromkeys, tuple, set, etc) paired with any long running or infinite iterator (itertools.count, xrange(sys.maxint), etc). Even the tp_print slot can get caught up in emitting oversized output in a way that is uninterruptable. I don't see a clean way of teaching all of these functions to periodically check for signals, and either handle them, raise an exception or continue. Fixing this could muck-up and complicate a bunch of otherwise clean code. Still, it would be nice if everything were interruptable. I'm just not sure it's worth it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1043446&group_id=5470 From noreply at sourceforge.net Tue Mar 6 11:55:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 02:55:07 -0800 Subject: [ python-Bugs-1673757 ] string and unicode formatting are missing a test for "G" Message-ID: Bugs item #1673757, was opened at 2007-03-05 12:34 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&group_id=5470 Please note that this 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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eric V. Smith (ericvsmith) Assigned to: Nobody/Anonymous (nobody) Summary: string and unicode formatting are missing a test for "G" Initial Comment: In stringobject.c and unicodeobject.c, the formatting codes for 'e', 'E', 'f', 'F', 'g', and 'G' all get routed to formatfloat(). formatfloat() is essentially identical in stringobject.c and unicodeobject.c. 'F' is mapped to 'f'. There is a test for excess precision for 'f' and 'g', but not one for 'G'. The "type == 'g'" test should be "(type == 'g' || type == 'G')". I assume this bug is in 2.5 and 2.6 as well, although I haven't verified that, yet. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2007-03-06 20:55 Message: Logged In: YES user_id=1038590 Originator: NO Behaviour is definitely present in the current 2.6 trunk, so I expect it to be present in the 2.5 maintenance branch too. On platforms which provide a correct implementation of vsnprintf, this won't cause a buffer overflow (but can give an incorrect result). As far as I can tell, the limited precision of C doubles saves you on platforms without vsnprintf (then again, I may not be abusing it correctly after forcing my dev tree to use the vsnprintf emulation, or else the behaviour of the emulation may vary with platform vagaries in vsprintf implementations). The patch doesn't currently apply cleanly - it needs to be regenerated using svn diff from the main python directory so that the filenames are correct. We also need a test case to make sure the problem never comes back (the string tests are a little confusing though, since the same tests are used for str, unicode & UserString). ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-05 12:47 Message: Logged In: YES user_id=411198 Originator: YES Patch for 3.0 is at http://python.org/sf/1673759 This should be checked in 2.5 and 2.6, but I don't have an environment to compile those. ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-05 12:42 Message: Logged In: YES user_id=411198 Originator: YES This is the correct behavior: >>> '%200.200g' % 1.0 Traceback (most recent call last): File "", line 1, in ? OverflowError: formatted float is too long (precision too large?) But 'G' is handled differently: >>> '%200.200G' % 1.0 ' 1' 'G' should give the same OverflowError as 'g'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&group_id=5470 From noreply at sourceforge.net Tue Mar 6 11:57:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 02:57:52 -0800 Subject: [ python-Bugs-1673757 ] string and unicode formatting are missing a test for "G" Message-ID: Bugs item #1673757, was opened at 2007-03-04 21:34 Message generated for change (Comment added) made by ericvsmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&group_id=5470 Please note that this 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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eric V. Smith (ericvsmith) Assigned to: Nobody/Anonymous (nobody) Summary: string and unicode formatting are missing a test for "G" Initial Comment: In stringobject.c and unicodeobject.c, the formatting codes for 'e', 'E', 'f', 'F', 'g', and 'G' all get routed to formatfloat(). formatfloat() is essentially identical in stringobject.c and unicodeobject.c. 'F' is mapped to 'f'. There is a test for excess precision for 'f' and 'g', but not one for 'G'. The "type == 'g'" test should be "(type == 'g' || type == 'G')". I assume this bug is in 2.5 and 2.6 as well, although I haven't verified that, yet. ---------------------------------------------------------------------- >Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-06 05:57 Message: Logged In: YES user_id=411198 Originator: YES Yes, my bad on not having tests and the diff being fubar. I've already started writing the tests, I should be done in the next 30 minutes. Expect a new patch. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2007-03-06 05:55 Message: Logged In: YES user_id=1038590 Originator: NO Behaviour is definitely present in the current 2.6 trunk, so I expect it to be present in the 2.5 maintenance branch too. On platforms which provide a correct implementation of vsnprintf, this won't cause a buffer overflow (but can give an incorrect result). As far as I can tell, the limited precision of C doubles saves you on platforms without vsnprintf (then again, I may not be abusing it correctly after forcing my dev tree to use the vsnprintf emulation, or else the behaviour of the emulation may vary with platform vagaries in vsprintf implementations). The patch doesn't currently apply cleanly - it needs to be regenerated using svn diff from the main python directory so that the filenames are correct. We also need a test case to make sure the problem never comes back (the string tests are a little confusing though, since the same tests are used for str, unicode & UserString). ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-04 21:47 Message: Logged In: YES user_id=411198 Originator: YES Patch for 3.0 is at http://python.org/sf/1673759 This should be checked in 2.5 and 2.6, but I don't have an environment to compile those. ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-04 21:42 Message: Logged In: YES user_id=411198 Originator: YES This is the correct behavior: >>> '%200.200g' % 1.0 Traceback (most recent call last): File "", line 1, in ? OverflowError: formatted float is too long (precision too large?) But 'G' is handled differently: >>> '%200.200G' % 1.0 ' 1' 'G' should give the same OverflowError as 'g'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&group_id=5470 From noreply at sourceforge.net Tue Mar 6 12:10:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 03:10:52 -0800 Subject: [ python-Bugs-1673757 ] string and unicode formatting are missing a test for "G" Message-ID: Bugs item #1673757, was opened at 2007-03-04 21:34 Message generated for change (Comment added) made by ericvsmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&group_id=5470 Please note that this 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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eric V. Smith (ericvsmith) Assigned to: Nobody/Anonymous (nobody) Summary: string and unicode formatting are missing a test for "G" Initial Comment: In stringobject.c and unicodeobject.c, the formatting codes for 'e', 'E', 'f', 'F', 'g', and 'G' all get routed to formatfloat(). formatfloat() is essentially identical in stringobject.c and unicodeobject.c. 'F' is mapped to 'f'. There is a test for excess precision for 'f' and 'g', but not one for 'G'. The "type == 'g'" test should be "(type == 'g' || type == 'G')". I assume this bug is in 2.5 and 2.6 as well, although I haven't verified that, yet. ---------------------------------------------------------------------- >Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-06 06:10 Message: Logged In: YES user_id=411198 Originator: YES The patch was corrected, and tests added. ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-06 05:57 Message: Logged In: YES user_id=411198 Originator: YES Yes, my bad on not having tests and the diff being fubar. I've already started writing the tests, I should be done in the next 30 minutes. Expect a new patch. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2007-03-06 05:55 Message: Logged In: YES user_id=1038590 Originator: NO Behaviour is definitely present in the current 2.6 trunk, so I expect it to be present in the 2.5 maintenance branch too. On platforms which provide a correct implementation of vsnprintf, this won't cause a buffer overflow (but can give an incorrect result). As far as I can tell, the limited precision of C doubles saves you on platforms without vsnprintf (then again, I may not be abusing it correctly after forcing my dev tree to use the vsnprintf emulation, or else the behaviour of the emulation may vary with platform vagaries in vsprintf implementations). The patch doesn't currently apply cleanly - it needs to be regenerated using svn diff from the main python directory so that the filenames are correct. We also need a test case to make sure the problem never comes back (the string tests are a little confusing though, since the same tests are used for str, unicode & UserString). ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-04 21:47 Message: Logged In: YES user_id=411198 Originator: YES Patch for 3.0 is at http://python.org/sf/1673759 This should be checked in 2.5 and 2.6, but I don't have an environment to compile those. ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-04 21:42 Message: Logged In: YES user_id=411198 Originator: YES This is the correct behavior: >>> '%200.200g' % 1.0 Traceback (most recent call last): File "", line 1, in ? OverflowError: formatted float is too long (precision too large?) But 'G' is handled differently: >>> '%200.200G' % 1.0 ' 1' 'G' should give the same OverflowError as 'g'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&group_id=5470 From noreply at sourceforge.net Tue Mar 6 13:18:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 04:18:07 -0800 Subject: [ python-Bugs-1674503 ] execfile() response to syntax errors Message-ID: Bugs item #1674503, was opened at 2007-03-05 23:38 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1674503&group_id=5470 Please note that this 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: 3 Private: No Submitted By: Jonathan Griffitts (jcgriffitts) Assigned to: Nobody/Anonymous (nobody) Summary: execfile() response to syntax errors Initial Comment: Python 2.5 seems to have an anomaly when execfile() encounters syntax errors. If I use execfile() to execute a file that contains a syntax error, it throws the expected SyntaxError exception but does not close the source file. Since the file is still open, an external program can't modify it to fix the syntax error. I have noticed this problem in Python 2.5 on Windows 2000 and Windows XP. I tried to reproduce it on Python 2.3 on BSD Unix but it didn't seem to happen there. ---------------- spam.py --------------------- [intentional-syntax-error) ---------------------------------------------- The following is my console session: ---------------------------------------------- Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> execfile('spam.py') Traceback (most recent call last): File "", line 1, in File "spam.py", line 1 [intentional-syntax-error) ^ SyntaxError: invalid syntax >>> ---------------------------------------------- At this point file spam.py remains open until Python exits. There's no obvious way to close the file from within the script because there is no file object. Under Windows, this prevents spam.py from being edited, renamed, or deleted. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 12:18 Message: Logged In: YES user_id=849994 Originator: NO Indeed PyRun_FileEx only closed the file if compilation was successful, fixed in rev. 54159, 54158 (2.5). ---------------------------------------------------------------------- Comment By: Jonathan Griffitts (jcgriffitts) Date: 2007-03-06 01:17 Message: Logged In: YES user_id=796443 Originator: YES Easy work-around: use exec(file('spam.py')) instead of execfile('spam.py') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1674503&group_id=5470 From noreply at sourceforge.net Tue Mar 6 14:21:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 05:21:46 -0800 Subject: [ python-Bugs-947380 ] sys.path is wrong in some cases Message-ID: Bugs item #947380, was opened at 2004-05-04 02:46 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947380&group_id=5470 Please note that this 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: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ori Berger (orib) Assigned to: Nobody/Anonymous (nobody) Summary: sys.path is wrong in some cases Initial Comment: Python version tested: 2.3.3 (But if I read the cvs annotate correctly, this goes all the way back to 2.0) OS Version tested: Win2K (but any win32 version should behave the same). On Windows, sys,path sometimes contains the 'current working directory', in which the Python process was started, while the interpreter is still initializing; it shouldn't be there until after the interpreter had completed initializing and is ready for batch or interactive execution. How to reproduce: Use plain-vanilla 2.3.3 Python, without _any_ additional module installed. The HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.3\PythonPath registry key must NOT have any subkey (this is true for a fresh install, but might not be true if packages were installed earlier). Go to a subdirectory of your choice, e.g., C:\HoverCraft\Eels, and run (assuming Python is in c:\python23) > c:\python23\python -c "import sys; print sys.path" The first entry should be the current directory or ''. That's ok - it was added at the end of initialization. The second entry will be a .zip file where the .dll is; That's also ok. The third entry should be the current directory (or '') again. THIS IS NOT OK. How this was discovered: To give credit where credit is due, my friend Oren Gampel created a file called 'stat.py' in a directory, and from that moment on, Python started complaining about failing to import site. The reason is that 'site' imports 'ntpath', which imports 'stat', which unfortunately imported the new 'stat' rather than the library 'stat'. In some convoluted settings, this might have security implications - e.g., if an administrator starts a Python script in a directory to which a user has write permissions, this could result in a privelege escalation (even if the script has no import statements at all - the implicit "import site" is sufficient). I'm submitting a 2-line patch to the patch tracker (and one of them is a comment!) that seems to solve this problem. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-06 14:21 Message: Logged In: YES user_id=1326842 Originator: NO This was fixed in Python 2.5 with patch #1232023: http://www.python.org/sf/1232023 ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-21 02:06 Message: Logged In: YES user_id=341410 This is the old "module in current path shadows standard library module" issue which will be fixed in Python 2.4 via absolute and relative imports as stated in PEP 328: http://python.org/peps/pep-0328.html ---------------------------------------------------------------------- Comment By: Ori Berger (orib) Date: 2004-05-04 02:59 Message: Logged In: YES user_id=67862 Patch uploaded to http://python.org/sf/947386 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947380&group_id=5470 From noreply at sourceforge.net Tue Mar 6 16:50:35 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 07:50:35 -0800 Subject: [ python-Bugs-1646728 ] datetime.fromtimestamp fails with negative fractional times Message-ID: Bugs item #1646728, was opened at 2007-01-28 21:21 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.fromtimestamp fails with negative fractional times Initial Comment: The datetime.fromtimestamp() function works fine with integer timestamps and positive fractional timestamps, but fails if I pass a negative fractional timestamp. For example: >>> import datetime >>> datetime.datetime.fromtimestamp(-1.05) Traceback (most recent call last): File "", line 1, in ValueError: microsecond must be in 0..999999 It should return the same result as datetime.fromtimestamp(-1) - timedelta(seconds=.5). The same bug can be triggered in datetime.utcfromtimestamp(). I have been able to reproduce this bug in Python 2.4.4 and Python 2.5 on Linux. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 10:50 Message: Logged In: YES user_id=6380 Originator: NO Committed revision 54167. I'm leaving this open until it's been backported to the 2.5 branch. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 19:03 Message: Logged In: YES user_id=146903 Originator: YES I just tried the patch, and can confirm that it fixes the problem with datetime.fromtimestamp() and datetime.utcfromtimestamp(). The logic in the patch looks correct. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-05 13:38 Message: Logged In: YES user_id=6380 Originator: NO Attached is a fix. If this is to your liking I'll check it in. File Added: datetime.patch ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 05:23 Message: Logged In: YES user_id=146903 Originator: YES The problem seems to be in datetime_from_timestamp() from datetimemodule.c. It should probably be checking to see whether the microseconds value it calculates is negative, and adjust "timet" and "us" accordingly if so. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 11:05 Message: Logged In: YES user_id=6380 Originator: NO Looks like a bug in the conversion from floats to ints. Anyone care to track it down more precisely? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 From noreply at sourceforge.net Tue Mar 6 16:58:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 07:58:14 -0800 Subject: [ python-Bugs-1675026 ] Redirect cause invalid descriptor error Message-ID: Bugs item #1675026, was opened at 2007-03-06 15: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=1675026&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jean-Marc Ranger (jmranger) Assigned to: Nobody/Anonymous (nobody) Summary: Redirect cause invalid descriptor error Initial Comment: Test setup: - Windows 2000 (french) - Python 2.5 (reproducible with 2.4.2 and 2.4.4) One python source file, test.py: --- import os print os.system("echo test") --- Console output: --- C:\test>test.py test 0 C:\test>test.py > test.log Descripteur non valide C:\test>type test.log 0 C:\test>c:\python25\python test.py test 0 C:\test>c:\python25\python test.py > test.log C:\test>type test.log test 0 C:\test> --- The "Descripteur non valide" error would translate to "invalid file descriptor". I would expect the 2nd call to perform the same way the 4th does. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675026&group_id=5470 From noreply at sourceforge.net Tue Mar 6 18:59:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 09:59:03 -0800 Subject: [ python-Bugs-1646728 ] datetime.fromtimestamp fails with negative fractional times Message-ID: Bugs item #1646728, was opened at 2007-01-28 21:21 Message generated for change (Settings changed) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 Please note that this 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.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.fromtimestamp fails with negative fractional times Initial Comment: The datetime.fromtimestamp() function works fine with integer timestamps and positive fractional timestamps, but fails if I pass a negative fractional timestamp. For example: >>> import datetime >>> datetime.datetime.fromtimestamp(-1.05) Traceback (most recent call last): File "", line 1, in ValueError: microsecond must be in 0..999999 It should return the same result as datetime.fromtimestamp(-1) - timedelta(seconds=.5). The same bug can be triggered in datetime.utcfromtimestamp(). I have been able to reproduce this bug in Python 2.4.4 and Python 2.5 on Linux. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 12:59 Message: Logged In: YES user_id=6380 Originator: NO Georgbot backported this to 2.5. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 10:50 Message: Logged In: YES user_id=6380 Originator: NO Committed revision 54167. I'm leaving this open until it's been backported to the 2.5 branch. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 19:03 Message: Logged In: YES user_id=146903 Originator: YES I just tried the patch, and can confirm that it fixes the problem with datetime.fromtimestamp() and datetime.utcfromtimestamp(). The logic in the patch looks correct. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-05 13:38 Message: Logged In: YES user_id=6380 Originator: NO Attached is a fix. If this is to your liking I'll check it in. File Added: datetime.patch ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 05:23 Message: Logged In: YES user_id=146903 Originator: YES The problem seems to be in datetime_from_timestamp() from datetimemodule.c. It should probably be checking to see whether the microseconds value it calculates is negative, and adjust "timet" and "us" accordingly if so. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 11:05 Message: Logged In: YES user_id=6380 Originator: NO Looks like a bug in the conversion from floats to ints. Anyone care to track it down more precisely? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 From noreply at sourceforge.net Tue Mar 6 19:06:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 10:06:54 -0800 Subject: [ python-Bugs-947380 ] sys.path is wrong in some cases Message-ID: Bugs item #947380, was opened at 2004-05-04 00:46 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947380&group_id=5470 Please note that this 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: Platform-specific >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Ori Berger (orib) Assigned to: Nobody/Anonymous (nobody) Summary: sys.path is wrong in some cases Initial Comment: Python version tested: 2.3.3 (But if I read the cvs annotate correctly, this goes all the way back to 2.0) OS Version tested: Win2K (but any win32 version should behave the same). On Windows, sys,path sometimes contains the 'current working directory', in which the Python process was started, while the interpreter is still initializing; it shouldn't be there until after the interpreter had completed initializing and is ready for batch or interactive execution. How to reproduce: Use plain-vanilla 2.3.3 Python, without _any_ additional module installed. The HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.3\PythonPath registry key must NOT have any subkey (this is true for a fresh install, but might not be true if packages were installed earlier). Go to a subdirectory of your choice, e.g., C:\HoverCraft\Eels, and run (assuming Python is in c:\python23) > c:\python23\python -c "import sys; print sys.path" The first entry should be the current directory or ''. That's ok - it was added at the end of initialization. The second entry will be a .zip file where the .dll is; That's also ok. The third entry should be the current directory (or '') again. THIS IS NOT OK. How this was discovered: To give credit where credit is due, my friend Oren Gampel created a file called 'stat.py' in a directory, and from that moment on, Python started complaining about failing to import site. The reason is that 'site' imports 'ntpath', which imports 'stat', which unfortunately imported the new 'stat' rather than the library 'stat'. In some convoluted settings, this might have security implications - e.g., if an administrator starts a Python script in a directory to which a user has write permissions, this could result in a privelege escalation (even if the script has no import statements at all - the implicit "import site" is sufficient). I'm submitting a 2-line patch to the patch tracker (and one of them is a comment!) that seems to solve this problem. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 18:06 Message: Logged In: YES user_id=849994 Originator: NO Closing accordingly. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-06 13:21 Message: Logged In: YES user_id=1326842 Originator: NO This was fixed in Python 2.5 with patch #1232023: http://www.python.org/sf/1232023 ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-21 00:06 Message: Logged In: YES user_id=341410 This is the old "module in current path shadows standard library module" issue which will be fixed in Python 2.4 via absolute and relative imports as stated in PEP 328: http://python.org/peps/pep-0328.html ---------------------------------------------------------------------- Comment By: Ori Berger (orib) Date: 2004-05-04 00:59 Message: Logged In: YES user_id=67862 Patch uploaded to http://python.org/sf/947386 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947380&group_id=5470 From noreply at sourceforge.net Tue Mar 6 19:15:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 10:15:02 -0800 Subject: [ python-Bugs-1646728 ] datetime.fromtimestamp fails with negative fractional times Message-ID: Bugs item #1646728, was opened at 2007-01-29 02:21 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 Please note that this 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.5 Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.fromtimestamp fails with negative fractional times Initial Comment: The datetime.fromtimestamp() function works fine with integer timestamps and positive fractional timestamps, but fails if I pass a negative fractional timestamp. For example: >>> import datetime >>> datetime.datetime.fromtimestamp(-1.05) Traceback (most recent call last): File "", line 1, in ValueError: microsecond must be in 0..999999 It should return the same result as datetime.fromtimestamp(-1) - timedelta(seconds=.5). The same bug can be triggered in datetime.utcfromtimestamp(). I have been able to reproduce this bug in Python 2.4.4 and Python 2.5 on Linux. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 18:15 Message: Logged In: YES user_id=849994 Originator: NO Though, the new tests seem to fail on Windows (I noticed that only after backporting, since most other buildbot failures were due to the cmp/key problem in setup.py). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 17:59 Message: Logged In: YES user_id=6380 Originator: NO Georgbot backported this to 2.5. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 15:50 Message: Logged In: YES user_id=6380 Originator: NO Committed revision 54167. I'm leaving this open until it's been backported to the 2.5 branch. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2007-03-06 00:03 Message: Logged In: YES user_id=146903 Originator: YES I just tried the patch, and can confirm that it fixes the problem with datetime.fromtimestamp() and datetime.utcfromtimestamp(). The logic in the patch looks correct. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-05 18:38 Message: Logged In: YES user_id=6380 Originator: NO Attached is a fix. If this is to your liking I'll check it in. File Added: datetime.patch ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 10:23 Message: Logged In: YES user_id=146903 Originator: YES The problem seems to be in datetime_from_timestamp() from datetimemodule.c. It should probably be checking to see whether the microseconds value it calculates is negative, and adjust "timet" and "us" accordingly if so. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 16:05 Message: Logged In: YES user_id=6380 Originator: NO Looks like a bug in the conversion from floats to ints. Anyone care to track it down more precisely? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 From noreply at sourceforge.net Tue Mar 6 19:34:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 10:34:32 -0800 Subject: [ python-Bugs-1631394 ] sre module has misleading docs Message-ID: Bugs item #1631394, was opened at 2007-01-09 11:12 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1631394&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: None >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tom Lynn (tlynn) Assigned to: Nobody/Anonymous (nobody) Summary: sre module has misleading docs Initial Comment: >>> help(sre) ... "$" Matches the end of the string. ... \Z Matches only at the end of the string. ... M MULTILINE "^" matches the beginning of lines as well as the string. "$" matches the end of lines as well as the string. The docs for "$" are misleading - it actually matches in newline-specific ways which the module's built-in docs don't hint at. The MULTILINE docs don't clarify this. I'd also like to see "from sre import __doc__" added to the end of re.py; lack of "help(re)" is a bigger problem than having slightly wrong auto-generated docs for the re module itself. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 18:34 Message: Logged In: YES user_id=849994 Originator: NO Doesn't seem so. Note that the sre.__doc__ problem doesn't exist in 2.5 anymore since re is now what sre was before. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-01-09 18:22 Message: Logged In: YES user_id=21627 Originator: NO Did you mean to include a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1631394&group_id=5470 From noreply at sourceforge.net Tue Mar 6 19:34:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 10:34:41 -0800 Subject: [ python-Bugs-1646728 ] datetime.fromtimestamp fails with negative fractional times Message-ID: Bugs item #1646728, was opened at 2007-01-28 21:21 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 Please note that this 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.5 >Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.fromtimestamp fails with negative fractional times Initial Comment: The datetime.fromtimestamp() function works fine with integer timestamps and positive fractional timestamps, but fails if I pass a negative fractional timestamp. For example: >>> import datetime >>> datetime.datetime.fromtimestamp(-1.05) Traceback (most recent call last): File "", line 1, in ValueError: microsecond must be in 0..999999 It should return the same result as datetime.fromtimestamp(-1) - timedelta(seconds=.5). The same bug can be triggered in datetime.utcfromtimestamp(). I have been able to reproduce this bug in Python 2.4.4 and Python 2.5 on Linux. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 13:34 Message: Logged In: YES user_id=6380 Originator: NO That's too bad. More details? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 13:15 Message: Logged In: YES user_id=849994 Originator: NO Though, the new tests seem to fail on Windows (I noticed that only after backporting, since most other buildbot failures were due to the cmp/key problem in setup.py). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 12:59 Message: Logged In: YES user_id=6380 Originator: NO Georgbot backported this to 2.5. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 10:50 Message: Logged In: YES user_id=6380 Originator: NO Committed revision 54167. I'm leaving this open until it's been backported to the 2.5 branch. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 19:03 Message: Logged In: YES user_id=146903 Originator: YES I just tried the patch, and can confirm that it fixes the problem with datetime.fromtimestamp() and datetime.utcfromtimestamp(). The logic in the patch looks correct. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-05 13:38 Message: Logged In: YES user_id=6380 Originator: NO Attached is a fix. If this is to your liking I'll check it in. File Added: datetime.patch ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 05:23 Message: Logged In: YES user_id=146903 Originator: YES The problem seems to be in datetime_from_timestamp() from datetimemodule.c. It should probably be checking to see whether the microseconds value it calculates is negative, and adjust "timet" and "us" accordingly if so. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 11:05 Message: Logged In: YES user_id=6380 Originator: NO Looks like a bug in the conversion from floats to ints. Anyone care to track it down more precisely? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 From noreply at sourceforge.net Tue Mar 6 19:45:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 10:45:44 -0800 Subject: [ python-Bugs-1646728 ] datetime.fromtimestamp fails with negative fractional times Message-ID: Bugs item #1646728, was opened at 2007-01-29 02:21 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 Please note that this 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.5 Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.fromtimestamp fails with negative fractional times Initial Comment: The datetime.fromtimestamp() function works fine with integer timestamps and positive fractional timestamps, but fails if I pass a negative fractional timestamp. For example: >>> import datetime >>> datetime.datetime.fromtimestamp(-1.05) Traceback (most recent call last): File "", line 1, in ValueError: microsecond must be in 0..999999 It should return the same result as datetime.fromtimestamp(-1) - timedelta(seconds=.5). The same bug can be triggered in datetime.utcfromtimestamp(). I have been able to reproduce this bug in Python 2.4.4 and Python 2.5 on Linux. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 18:45 Message: Logged In: YES user_id=849994 Originator: NO Not from me, no Windows around. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 18:34 Message: Logged In: YES user_id=6380 Originator: NO That's too bad. More details? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 18:15 Message: Logged In: YES user_id=849994 Originator: NO Though, the new tests seem to fail on Windows (I noticed that only after backporting, since most other buildbot failures were due to the cmp/key problem in setup.py). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 17:59 Message: Logged In: YES user_id=6380 Originator: NO Georgbot backported this to 2.5. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 15:50 Message: Logged In: YES user_id=6380 Originator: NO Committed revision 54167. I'm leaving this open until it's been backported to the 2.5 branch. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2007-03-06 00:03 Message: Logged In: YES user_id=146903 Originator: YES I just tried the patch, and can confirm that it fixes the problem with datetime.fromtimestamp() and datetime.utcfromtimestamp(). The logic in the patch looks correct. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-05 18:38 Message: Logged In: YES user_id=6380 Originator: NO Attached is a fix. If this is to your liking I'll check it in. File Added: datetime.patch ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 10:23 Message: Logged In: YES user_id=146903 Originator: YES The problem seems to be in datetime_from_timestamp() from datetimemodule.c. It should probably be checking to see whether the microseconds value it calculates is negative, and adjust "timet" and "us" accordingly if so. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 16:05 Message: Logged In: YES user_id=6380 Originator: NO Looks like a bug in the conversion from floats to ints. Anyone care to track it down more precisely? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 From noreply at sourceforge.net Tue Mar 6 19:53:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 10:53:37 -0800 Subject: [ python-Bugs-1650903 ] PyFloat_FromString deprecated form Message-ID: Bugs item #1650903, was opened at 2007-02-02 19:41 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650903&group_id=5470 Please note that this 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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: PyFloat_FromString deprecated form Initial Comment: PyFloat_FromString takes two arguments, and the only purpose of the second is to avoid changing the API. Extracts from Tim's 2000 comment: Since we can't change the interface of a public API function, pend is still supported but now *officially* useless: if pend is not NULL, *pend is set to NULL. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 18:53 Message: Logged In: YES user_id=849994 Originator: NO What do you propose to do? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650903&group_id=5470 From noreply at sourceforge.net Tue Mar 6 19:54:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 10:54:19 -0800 Subject: [ python-Bugs-1650903 ] PyFloat_FromString deprecated form Message-ID: Bugs item #1650903, was opened at 2007-02-02 19:41 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650903&group_id=5470 Please note that this 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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: PyFloat_FromString deprecated form Initial Comment: PyFloat_FromString takes two arguments, and the only purpose of the second is to avoid changing the API. Extracts from Tim's 2000 comment: Since we can't change the interface of a public API function, pend is still supported but now *officially* useless: if pend is not NULL, *pend is set to NULL. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 18:54 Message: Logged In: YES user_id=849994 Originator: NO (cont'd) C API functions shouldn't even change signature in Py 3000. Therefore, a new name would be needed... ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 18:53 Message: Logged In: YES user_id=849994 Originator: NO What do you propose to do? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650903&group_id=5470 From noreply at sourceforge.net Tue Mar 6 20:32:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 11:32:42 -0800 Subject: [ python-Bugs-1668565 ] inspect.getargspec() fails with keyword-only arguments Message-ID: Bugs item #1668565, was opened at 2007-02-25 13:12 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668565&group_id=5470 Please note that this 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 3000 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getargspec() fails with keyword-only arguments Initial Comment: If a function's signature includes both keyword-only arguments and *args or **kwargs then inspect.getargspec() assigns the name for the * and ** arguments to the first one or two keyword-only arguments. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2007-03-06 11:32 Message: Logged In: YES user_id=357491 Originator: YES Fixed by r54043. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668565&group_id=5470 From noreply at sourceforge.net Tue Mar 6 21:47:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 12:47:23 -0800 Subject: [ python-Bugs-1633621 ] curses should reset curses.{COLS, LINES} when term. resized Message-ID: Bugs item #1633621, was opened at 2007-01-12 00:38 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633621&group_id=5470 Please note that this 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.5 >Status: Closed >Resolution: Fixed Priority: 3 Private: No Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: curses should reset curses.{COLS,LINES} when term. resized Initial Comment: [forwarded from http://bugs.debian.org/366698] The curses module does not reset curses.COLS and curses.LINES when the terminal is resized. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2007-03-06 21:47 Message: Logged In: YES user_id=89016 Originator: NO Checked in as revision 54180 and 54181 (2.5) ---------------------------------------------------------------------- Comment By: Scott Dial (geekmug) Date: 2007-03-05 23:14 Message: Logged In: YES user_id=383208 Originator: NO I've reviewed this patch and I believe it to be the correct patch. I believe it would be prudent to add a test case for this. I'm unable to attach, but here is a link to a patch for that: http://scottdial.com/python-dev/curses-test.patch ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2007-02-12 19:59 Message: Logged In: YES user_id=89016 Originator: NO Here's a patch that implements the requested changes. File Added: diff.txt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633621&group_id=5470 From noreply at sourceforge.net Tue Mar 6 21:55:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 12:55:23 -0800 Subject: [ python-Bugs-1631394 ] sre module has misleading docs Message-ID: Bugs item #1631394, was opened at 2007-01-09 12:12 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1631394&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tom Lynn (tlynn) >Assigned to: Fredrik Lundh (effbot) Summary: sre module has misleading docs Initial Comment: >>> help(sre) ... "$" Matches the end of the string. ... \Z Matches only at the end of the string. ... M MULTILINE "^" matches the beginning of lines as well as the string. "$" matches the end of lines as well as the string. The docs for "$" are misleading - it actually matches in newline-specific ways which the module's built-in docs don't hint at. The MULTILINE docs don't clarify this. I'd also like to see "from sre import __doc__" added to the end of re.py; lack of "help(re)" is a bigger problem than having slightly wrong auto-generated docs for the re module itself. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-06 21:55 Message: Logged In: YES user_id=21627 Originator: NO The re.__doc__ problem is gone; the problem that the $ documentation doesn't give a complete specification persists. Fredrik, do you have an opinion on this? If not, please unassign. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 19:34 Message: Logged In: YES user_id=849994 Originator: NO Doesn't seem so. Note that the sre.__doc__ problem doesn't exist in 2.5 anymore since re is now what sre was before. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-01-09 19:22 Message: Logged In: YES user_id=21627 Originator: NO Did you mean to include a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1631394&group_id=5470 From noreply at sourceforge.net Tue Mar 6 23:39:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 14:39:16 -0800 Subject: [ python-Bugs-1647654 ] No obvious and correct way to get the time zone offset Message-ID: Bugs item #1647654, was opened at 2007-01-30 00:48 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1647654&group_id=5470 Please note that this 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 Private: No Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: No obvious and correct way to get the time zone offset Initial Comment: It would be nice if the Python time module provided an obvious way to get the local time UTC offset for an arbitrary time stamp. The existing constants included in the module are not sufficient to correctly determine this value. As context, the Bazaar version control system (written in Python), the local time UTC offset is recorded in a commit. The method used in releases prior to 0.14 made use of the "daylight", "timezone" and "altzone" constants from the time module like this: if time.localtime(t).tm_isdst and time.daylight: return -time.altzone else: return -time.timezone This worked most of the time, but would occasionally give incorrect results. On Linux, the local time system can handle different daylight saving rules for different spans of years. For years where the rules change, these constants can provide incorrect data. Furthermore, they may be incorrect for time stamps in the past. I personally ran into this problem last December when Western Australia adopted daylight saving -- time.altzone gave an incorrect value until the start of 2007. Having a function in the standard library to calculate this offset would solve the problem. The implementation we ended up with for Bazaar was: offset = datetime.fromtimestamp(t) - datetime.utcfromtimestamp(t) return offset.days * 86400 + offset.seconds Another alternative would be to expose tm_gmtoff on time tuples (perhaps using the above code to synthesise it on platforms that don't have the field). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 17:39 Message: Logged In: YES user_id=6380 Originator: NO I see. There is code to decide the values for time.timezone, time.altzone and time.daylight that compares tm_gmtoff for Jan 1st of the current year to tm_gmtoff for July 1st; it uses this to decide whether DST is in effect and on which hemisphere you're on. I don't know why I didn't think of checking the tm_isdst flag instead, but either way the code would have failed for you prior to Jan 1st 07, because it could not have seen a difference if your timezone database was correct. You're just lucky you weren't running CYGWIN; the code inside #ifdef __CYGWIN__ doesn't even entertain the possibility that there's life possible on the Southern hemisphere. ;-) I think we should do two things; (a) export tm_zone and tm_gmtoff if they exist; (b) change the code that probes Jan 1st and Jul 1st of the current year to instead probe 4-6 spots starting today and covering the year forward. Unfortunately tm_zone and tm_gmtoff appear glibc inventions, so for supporting Solaris, Windows etc. I think we still need these. We really could use a module that accesses the entire timezone database but that's even more platform specific. If you want this to happen, please lobby for someone to help out on python-dev or c.l.py; I'm kind of overcommitted. :-) ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 05:03 Message: Logged In: YES user_id=146903 Originator: YES In Western Australia, a 3 year daylight saving trial was introduced starting on 3rd December 2006. Prior to that, we had no daylight saving shifts (the previous time we had daylight saving was 15 years ago in another trial). Since there was no daylight savings for 1st January 2006 and 1st July 2006, time.timezone and time.altzone were both equal to -28800 (UTC+8) for Python interpreters run in 2006. I am sure that I had the tzdata updates installed: my computer displayed the correct time, and listed the UTC offset as +0900 in December. Creating a time tuple for a date in December 2006 had the tm_isdst flag set to 1. If I was programming this in C, I'd use the tm_gmtoff field of "struct tm" if it was available. On platforms that don't provide tm_gmtoff, other platform specific methods would be needed (e.g. using timezone/altzone). The other alternative is to do date arithmetic on the results of localtime() and gmtime(), as you say. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 10:48 Message: Logged In: YES user_id=6380 Originator: NO Hm.... I'm not sure I understand why the first bit of code didn't work. Can you give a concrete example? (I.e. what was t, what was returned by localtime(t), and what were the three time variables that day.) I don't know the details of Western Australia's DST change. But looking at the source of timemodule.c, I notice that it simply samples the timezone on Jan 1st and July 1st, and if they differ, decides which one is summer time by which one is smaller. Your remark that the problem righted itself in January makes me wonder -- between what dates did you have DST? Alternatively, it could be that your system simply didn't have the correct DST change data loaded yet (this happens all the time when governments change the rules). Can you rule that out? I really don't want to have to change Python in order to correct for *that* problem. Yet another question, if you were to code this in C, how would you write it? Regardless, I think that it would be useful to support tm_gmtoff and other struct tm entries, the same way that we do this in struct stat. You could probably also get the correct result (assuming your system's timezone database is correct) by comparing localtime() and gmtime(). But the reverse engineering is a bit painful; your trick using datetime essentially does that. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2007-03-01 05:09 Message: Logged In: YES user_id=146903 Originator: YES The localtime_tz() function sounds like it would probably fit the bill. Another option would be to expose tm_gmtoff and tm_zone as non-sequence fields of time.struct_time for systems that support them. This would provide the data without needing new APIs. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-02-23 19:31 Message: Logged In: YES user_id=226443 Originator: NO See patch #1667546 for a time module function returning extended time tuples. The datetime-based solution you provide is quite a clever workaround using "naive" datetime objects, but I'm inclined to think that some more convenient way of getting "aware" datetime objects would be nicer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1647654&group_id=5470 From noreply at sourceforge.net Wed Mar 7 00:20:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 15:20:17 -0800 Subject: [ python-Bugs-1115886 ] os.path.splitext don't handle unix hidden file correctly Message-ID: Bugs item #1115886, was opened at 2005-02-03 20:27 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115886&group_id=5470 Please note that this 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 Private: No Submitted By: Jeong-Min Lee (falsetru) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.splitext don't handle unix hidden file correctly Initial Comment: I expected this. >>> os.path.splitext('/path/to/.Hiddenfile') ('/path/to/.Hiddenfile', '') but got this. >>> os.path.splitext('/path/to/.Hiddenfile') ('/path/to/', '.Hiddenfile') ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-03-06 18:20 Message: Logged In: YES user_id=764593 Originator: NO 1462106 is a patch, though perhaps not the latest. python-dev is currently debating whether to fix this behavior or maintain backwards-compatibility. That suggests that it at least won't be changed in a bugfix version (like 2.4.x), and the group should be changed to 2.6. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 09:44 Message: Logged In: YES user_id=261020 -1 I hate to be a stick-in-the-mud, but the existing behaviour is what I would expect, and seems to be regular -- always picks the last dot: >>> os.path.splitext('a/b/c/foo.bar') ('a/b/c/foo', '.bar') >>> os.path.splitext('a/b/c/f.oo.bar') ('a/b/c/f.oo', '.bar') >>> os.path.splitext('a/b/c/.foo') ('a/b/c/', '.foo') >>> os.path.splitext('a/b/c/.foo.txt') ('a/b/c/.foo', '.txt') Changing it would surely break somebody's code too, of course. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-06-18 17:05 Message: Logged In: YES user_id=1188172 Interestingly, altering the behaviour of splitext in such a way does not contradict the documentation, which is: """ Split the pathname path into a pair (root, ext) such that root + ext == path, and ext is empty or begins with a period and contains at most one period. """ Personally I'm in favour of this change (on Unix it makes sense, while on Windows you can hardly find an "extension-only" file). ---------------------------------------------------------------------- Comment By: engelbert gruber (grubert) Date: 2005-06-13 10:12 Message: Logged In: YES user_id=147070 from test_posixpath.py :: self.assertEqual(posixpath.splitext(".ext"), ("", ".ext")) IMHO should then return (".ext",""). if this is desired :: if i<=p.rfind('/'): return p, '' else: return p[:i], p[i:] should do ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115886&group_id=5470 From noreply at sourceforge.net Wed Mar 7 00:50:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 15:50:48 -0800 Subject: [ python-Feature Requests-1656675 ] Drop-Handler for Python files Message-ID: Feature Requests item #1656675, was opened at 2007-02-10 06:36 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1656675&group_id=5470 Please note that this 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 Private: No Submitted By: Marek Kubica (leonidasxiv) Assigned to: Martin v. L?wis (loewis) Summary: Drop-Handler for Python files Initial Comment: Hi! We had a dscussion about what happens when one drops a file on a python sourcecode-file in the python-forum [1]. It turned out, that nothing happens at all. So someone brought up a solution. It is not really a problem with Python but it would be nice to add this to the Windows Installer. The proposed solution was to add the following to the registry (this is the format of the registry editor): Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\Python.File\shellex\DropHandler] @="{86C86720-42A0-1069-A2E8-08002B30309D}" [HKEY_CLASSES_ROOT\Python.NoConFile\shellex\DropHandler] @="{86C86720-42A0-1069-A2E8-08002B30309D}" [HKEY_CLASSES_ROOT\Python.CompiledFile\shellex\DropHandler] @="{86C86720-42A0-1069-A2E8-08002B30309D}" That should be simple thing to do using the MSI-Installer. [1] only in german, sorry: http://www.python-forum.de/topic-7493.html ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-03-06 18:50 Message: Logged In: YES user_id=764593 Originator: NO What would happen then? For example, should it cause python to start up, running with that file, and the dropped file as stdin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1656675&group_id=5470 From noreply at sourceforge.net Wed Mar 7 01:06:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 16:06:13 -0800 Subject: [ python-Bugs-1650903 ] PyFloat_FromString deprecated form Message-ID: Bugs item #1650903, was opened at 2007-02-02 14:41 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650903&group_id=5470 Please note that this 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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: PyFloat_FromString deprecated form Initial Comment: PyFloat_FromString takes two arguments, and the only purpose of the second is to avoid changing the API. Extracts from Tim's 2000 comment: Since we can't change the interface of a public API function, pend is still supported but now *officially* useless: if pend is not NULL, *pend is set to NULL. ---------------------------------------------------------------------- >Comment By: Jim Jewett (jimjjewett) Date: 2007-03-06 19:06 Message: Logged In: YES user_id=764593 Originator: YES I didn't realize that a decision had been made about the C API stability. I would indeed propose changing it, but probably not if it the rest of the API (even for strings and unicode?) is supposed to stay stable. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 13:54 Message: Logged In: YES user_id=849994 Originator: NO (cont'd) C API functions shouldn't even change signature in Py 3000. Therefore, a new name would be needed... ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 13:53 Message: Logged In: YES user_id=849994 Originator: NO What do you propose to do? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650903&group_id=5470 From noreply at sourceforge.net Wed Mar 7 01:35:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 16:35:19 -0800 Subject: [ python-Bugs-670311 ] sys.exit and PYTHONINSPECT Message-ID: Bugs item #670311, was opened at 2003-01-18 16:43 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=670311&group_id=5470 Please note that this 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 Private: No Submitted By: Kevin Altis (kasplat) Assigned to: Nobody/Anonymous (nobody) Summary: sys.exit and PYTHONINSPECT Initial Comment: If you invoke the Python interpreter with -i, then even sys.exit shouldn't kill the interpreter, especially since sys.exit generates a SystemExit exception which can be caught. I can't think of any other case where -i fails to keep the interpreter alive after a script exits, whether because of an syntax or runtime error or normal termination. I started a thread on python-dev about this issue: http://mail.python.org/pipermail/python-dev/2003- January/032217.html ka ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 00:35 Message: Logged In: YES user_id=849994 Originator: NO This was now fixed in rev. 54188. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-03-04 23:26 Message: Logged In: YES user_id=670441 See patch 697613 for a possible fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=670311&group_id=5470 From noreply at sourceforge.net Wed Mar 7 08:34:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 23:34:45 -0800 Subject: [ python-Bugs-1646728 ] datetime.fromtimestamp fails with negative fractional times Message-ID: Bugs item #1646728, was opened at 2007-01-29 11:21 Message generated for change (Comment added) made by ocean-city You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 Please note that this 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.5 Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.fromtimestamp fails with negative fractional times Initial Comment: The datetime.fromtimestamp() function works fine with integer timestamps and positive fractional timestamps, but fails if I pass a negative fractional timestamp. For example: >>> import datetime >>> datetime.datetime.fromtimestamp(-1.05) Traceback (most recent call last): File "", line 1, in ValueError: microsecond must be in 0..999999 It should return the same result as datetime.fromtimestamp(-1) - timedelta(seconds=.5). The same bug can be triggered in datetime.utcfromtimestamp(). I have been able to reproduce this bug in Python 2.4.4 and Python 2.5 on Linux. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2007-03-07 16:34 Message: Logged In: YES user_id=1200846 Originator: NO Hello, I'm user of Windows (Now building Python2.5 with VC6) I heard localtime() can only handle positive time_t on windows, so datetime.fromtimestamp() also fails for negative value. >>> datetime.datetime.fromtimestamp(-1.05) Traceback (most recent call last): File "", line 1, in ValueError: timestamp out of range for platform localtime()/gmtime() function >>> datetime.datetime.fromtimestamp(-1) Traceback (most recent call last): File "", line 1, in ValueError: timestamp out of range for platform localtime()/gmtime() function I'll attach workaround for unittest. Probably there is better way skip this test on non-negative platform though :-) Index: Lib/test/test_datetime.py =================================================================== --- Lib/test/test_datetime.py (revision 54194) +++ Lib/test/test_datetime.py (working copy) @@ -1428,9 +1428,17 @@ def test_negative_float_fromtimestamp(self): # The result is tz-dependent; at least test that this doesn't # fail (like it did before bug 1646728 was fixed). + try: + self.theclass.fromtimestamp(-1) + except ValueError: # cannot handle negative value + return self.theclass.fromtimestamp(-1.05) def test_negative_float_utcfromtimestamp(self): + try: + self.theclass.utcfromtimestamp(-1) + except ValueError: # cannot handle negative value + return d = self.theclass.utcfromtimestamp(-1.05) self.assertEquals(d, self.theclass(1969, 12, 31, 23, 59, 58, 950000)) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 03:45 Message: Logged In: YES user_id=849994 Originator: NO Not from me, no Windows around. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-07 03:34 Message: Logged In: YES user_id=6380 Originator: NO That's too bad. More details? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 03:15 Message: Logged In: YES user_id=849994 Originator: NO Though, the new tests seem to fail on Windows (I noticed that only after backporting, since most other buildbot failures were due to the cmp/key problem in setup.py). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-07 02:59 Message: Logged In: YES user_id=6380 Originator: NO Georgbot backported this to 2.5. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-07 00:50 Message: Logged In: YES user_id=6380 Originator: NO Committed revision 54167. I'm leaving this open until it's been backported to the 2.5 branch. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2007-03-06 09:03 Message: Logged In: YES user_id=146903 Originator: YES I just tried the patch, and can confirm that it fixes the problem with datetime.fromtimestamp() and datetime.utcfromtimestamp(). The logic in the patch looks correct. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 03:38 Message: Logged In: YES user_id=6380 Originator: NO Attached is a fix. If this is to your liking I'll check it in. File Added: datetime.patch ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 19:23 Message: Logged In: YES user_id=146903 Originator: YES The problem seems to be in datetime_from_timestamp() from datetimemodule.c. It should probably be checking to see whether the microseconds value it calculates is negative, and adjust "timet" and "us" accordingly if so. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-03 01:05 Message: Logged In: YES user_id=6380 Originator: NO Looks like a bug in the conversion from floats to ints. Anyone care to track it down more precisely? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 From noreply at sourceforge.net Wed Mar 7 08:54:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 23:54:07 -0800 Subject: [ python-Bugs-1675511 ] Python still uses broken -xcode option on Solaris/x86 Message-ID: Bugs item #1675511, was opened at 2007-03-07 02:54 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=1675511&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: Python still uses broken -xcode option on Solaris/x86 Initial Comment: Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting a new bug against 2.5 in the hopes that someone will read it... text updated with minor corrections. Python 2.5, Solaris x86 10 Update 3, Sun Studio 11 xcode=pic32 option is not supported on Solaris x86 Sun C . Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when any compiler other than gcc is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates an error that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 From noreply at sourceforge.net Wed Mar 7 09:02:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 00:02:51 -0800 Subject: [ python-Bugs-1561333 ] -xcode=pic32 option is not supported on Solaris x86 Sun C Message-ID: Bugs item #1561333, was opened at 2006-09-19 10:15 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1561333&group_id=5470 Please note that this 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: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: James Lick (jlick) Assigned to: Nobody/Anonymous (nobody) Summary: -xcode=pic32 option is not supported on Solaris x86 Sun C Initial Comment: Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when Sun C is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates a warning that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 08:02 Message: Logged In: YES user_id=849994 Originator: NO Superseded by #1675511. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1561333&group_id=5470 From noreply at sourceforge.net Wed Mar 7 09:10:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 00:10:19 -0800 Subject: [ python-Bugs-1675516 ] random.randint fails on lists Message-ID: Bugs item #1675516, was opened at 2007-03-07 08:10 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=1675516&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: sardonics (sardonics) Assigned to: Nobody/Anonymous (nobody) Summary: random.randint fails on lists Initial Comment: >>> for i in range(400): ... l[random.randint(0,7)] ... 'g' 'g' 'c' 'c' 'b' 'b' 'g' 'g' 'd' 'g' 'd' 'f' 'd' 'a' Traceback (most recent call last): File "", line 2, in ? IndexError: list index out of range >>> l ['a', 'b', 'c', 'd', 'e', 'f', 'g'] >>> have no idea what the problem is. check out the error though ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675516&group_id=5470 From noreply at sourceforge.net Wed Mar 7 09:34:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 00:34:56 -0800 Subject: [ python-Bugs-1675511 ] Python still uses broken -xcode option on Solaris/x86 Message-ID: Bugs item #1675511, was opened at 2007-03-07 15:54 Message generated for change (Comment added) made by jlick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: Python still uses broken -xcode option on Solaris/x86 Initial Comment: Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting a new bug against 2.5 in the hopes that someone will read it... text updated with minor corrections. Python 2.5, Solaris x86 10 Update 3, Sun Studio 11 xcode=pic32 option is not supported on Solaris x86 Sun C . Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when any compiler other than gcc is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates an error that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-07 16:34 Message: Logged In: YES user_id=673069 Originator: NO Perhaps I was unclear in bug #1561333 that this resulted in only a warning. Actually the build will fail because of the incorrect flag. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 From noreply at sourceforge.net Wed Mar 7 09:35:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 00:35:00 -0800 Subject: [ python-Bugs-1675516 ] random.randint fails on lists Message-ID: Bugs item #1675516, was opened at 2007-03-07 17:10 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675516&group_id=5470 Please note that this 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.5 >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: sardonics (sardonics) Assigned to: Nobody/Anonymous (nobody) Summary: random.randint fails on lists Initial Comment: >>> for i in range(400): ... l[random.randint(0,7)] ... 'g' 'g' 'c' 'c' 'b' 'b' 'g' 'g' 'd' 'g' 'd' 'f' 'd' 'a' Traceback (most recent call last): File "", line 2, in ? IndexError: list index out of range >>> l ['a', 'b', 'c', 'd', 'e', 'f', 'g'] >>> have no idea what the problem is. check out the error though ---------------------------------------------------------------------- >Comment By: George Yoshida (quiver) Date: 2007-03-07 17:35 Message: Logged In: YES user_id=671362 Originator: NO Please read the doc carefully. randint(a, b) can return b: http://docs.python.org/lib/module-random.html > Return a random integer N such that a <= N <= b. So in your case, randint(0,7) is returning 7 and tries to access l's 8th element, which results in IndexError. Closing as invalid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675516&group_id=5470 From noreply at sourceforge.net Wed Mar 7 09:45:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 00:45:07 -0800 Subject: [ python-Bugs-1675533 ] setup.py LDFLAGS regexp is wrong Message-ID: Bugs item #1675533, was opened at 2007-03-07 03: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=1675533&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: setup.py LDFLAGS regexp is wrong Initial Comment: Python 2.5 setup.py mangles LDFLAGS and CPPFLAGS via: env_val = re.sub(r'(^|\s+)-(-|(?!%s))' % arg_name[1], '', env_val) This causes '-L/path/to/foo -R/path/to/bar' to become '-L/path/to/fooR/path/to/bar', which obviously doesn't work. The fix is simple - eat non-whitespace after the unrecognized option: env_val = re.sub(r'(^|\s+)-(-|(?!%s))\S+' % arg_name[1], '', env_val) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675533&group_id=5470 From noreply at sourceforge.net Wed Mar 7 09:48:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 00:48:47 -0800 Subject: [ python-Bugs-1675533 ] setup.py LDFLAGS regexp is wrong Message-ID: Bugs item #1675533, was opened at 2007-03-07 03:45 Message generated for change (Comment added) made by cgaspar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675533&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None >Priority: 7 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: setup.py LDFLAGS regexp is wrong Initial Comment: Python 2.5 setup.py mangles LDFLAGS and CPPFLAGS via: env_val = re.sub(r'(^|\s+)-(-|(?!%s))' % arg_name[1], '', env_val) This causes '-L/path/to/foo -R/path/to/bar' to become '-L/path/to/fooR/path/to/bar', which obviously doesn't work. The fix is simple - eat non-whitespace after the unrecognized option: env_val = re.sub(r'(^|\s+)-(-|(?!%s))\S+' % arg_name[1], '', env_val) ---------------------------------------------------------------------- >Comment By: Carson Gaspar (cgaspar) Date: 2007-03-07 03:48 Message: Logged In: YES user_id=664506 Originator: YES Or I could get the regexp correct and eat _option_ non-whitespace... env_val = re.sub(r'(^|\s+)-(-|(?!%s))\S*' % arg_name[1], '', env_val) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675533&group_id=5470 From noreply at sourceforge.net Wed Mar 7 09:49:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 00:49:00 -0800 Subject: [ python-Bugs-1675511 ] Python still uses broken -xcode option on Solaris/x86 Message-ID: Bugs item #1675511, was opened at 2007-03-07 02:54 Message generated for change (Settings changed) made by cgaspar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None >Priority: 7 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: Python still uses broken -xcode option on Solaris/x86 Initial Comment: Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting a new bug against 2.5 in the hopes that someone will read it... text updated with minor corrections. Python 2.5, Solaris x86 10 Update 3, Sun Studio 11 xcode=pic32 option is not supported on Solaris x86 Sun C . Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when any compiler other than gcc is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates an error that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-07 03:34 Message: Logged In: YES user_id=673069 Originator: NO Perhaps I was unclear in bug #1561333 that this resulted in only a warning. Actually the build will fail because of the incorrect flag. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 From noreply at sourceforge.net Wed Mar 7 10:05:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 01:05:29 -0800 Subject: [ python-Bugs-1648957 ] HP-UX: _ctypes/libffi/src/ia64/ffi/__attribute__/native cc Message-ID: Bugs item #1648957, was opened at 2007-01-31 10:07 Message generated for change (Comment added) made by cgaspar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1648957&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Johannes Abt (jabt) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX: _ctypes/libffi/src/ia64/ffi/__attribute__/native cc Initial Comment: _ctypes/libffi/src/ia64/ffi.c uses __attribute__((...)) twice. Consequently, ffi.c does not compile with the native compiler (cc: HP C/aC++ B3910B A.06.12 [Aug 17 2006]). ---------------------------------------------------------------------- Comment By: Carson Gaspar (cgaspar) Date: 2007-03-07 04:05 Message: Logged In: YES user_id=664506 Originator: NO Fails on Solaris x86 10 U3 / Sun Studio 11 for the same reasons. It's uncompilable on x86_64 anyway though, as Sun has no 128-bit integer type, so the __int128_t in x86/ffi64.c will never compile. I haven't tried building it in 32-bit mode. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2007-01-31 14:43 Message: Logged In: YES user_id=11105 Originator: NO I tried that on a HP testdrive machine. While the _ctypes extension buils fine with GCC (*), it does indeed not compile with the native C compiler. But cc not understanding __attribute__ is only the first problem; if it is removed there are lots of other compilation problems. Unless someone can provide a patch, I'll close this as 'won't fix'. (*) _ctypes_test.so is also built but fails to load as shared library, because the symbol __divsf3 is not defined. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1648957&group_id=5470 From noreply at sourceforge.net Wed Mar 7 10:35:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 01:35:09 -0800 Subject: [ python-Bugs-1669331 ] document that shutil.copyfileobj does not seek() Message-ID: Bugs item #1669331, was opened at 2007-02-26 17:53 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669331&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: document that shutil.copyfileobj does not seek() Initial Comment: This should close bug 1656578 which asks for documentation that shutil.copyfileobj() copies only from the current file position to the end of the file. While this is standard behavior for pretty much any function that accepts a file-like object, the phrase "the contents of the file-like object" could be confusing. The patch adds a little clarification text. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 09:35 Message: Logged In: YES user_id=849994 Originator: NO Committed as rev. 54202, 54203 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669331&group_id=5470 From noreply at sourceforge.net Wed Mar 7 10:35:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 01:35:41 -0800 Subject: [ python-Bugs-1656578 ] shutil.copyfileobj description is incomplete Message-ID: Bugs item #1656578, was opened at 2007-02-10 05:37 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656578&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Witten (herrwitten) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.copyfileobj description is incomplete Initial Comment: shutil.copyfileobj reads the source's data starting from the source's current file position. Thus, a user must issue seek(0) in order to have all of the source file object's contents read. This needs to be documented. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 09:35 Message: Logged In: YES user_id=849994 Originator: NO Patch #1669331 fixed this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656578&group_id=5470 From noreply at sourceforge.net Wed Mar 7 12:05:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 03:05:25 -0800 Subject: [ python-Bugs-1115886 ] os.path.splitext don't handle unix hidden file correctly Message-ID: Bugs item #1115886, was opened at 2005-02-04 02:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115886&group_id=5470 Please note that this 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: Fixed Priority: 5 Private: No Submitted By: Jeong-Min Lee (falsetru) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.splitext don't handle unix hidden file correctly Initial Comment: I expected this. >>> os.path.splitext('/path/to/.Hiddenfile') ('/path/to/.Hiddenfile', '') but got this. >>> os.path.splitext('/path/to/.Hiddenfile') ('/path/to/', '.Hiddenfile') ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-07 12:05 Message: Logged In: YES user_id=21627 Originator: NO After some discussion on python-dev, I fixed this in r54204. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-03-07 00:20 Message: Logged In: YES user_id=764593 Originator: NO 1462106 is a patch, though perhaps not the latest. python-dev is currently debating whether to fix this behavior or maintain backwards-compatibility. That suggests that it at least won't be changed in a bugfix version (like 2.4.x), and the group should be changed to 2.6. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 15:44 Message: Logged In: YES user_id=261020 -1 I hate to be a stick-in-the-mud, but the existing behaviour is what I would expect, and seems to be regular -- always picks the last dot: >>> os.path.splitext('a/b/c/foo.bar') ('a/b/c/foo', '.bar') >>> os.path.splitext('a/b/c/f.oo.bar') ('a/b/c/f.oo', '.bar') >>> os.path.splitext('a/b/c/.foo') ('a/b/c/', '.foo') >>> os.path.splitext('a/b/c/.foo.txt') ('a/b/c/.foo', '.txt') Changing it would surely break somebody's code too, of course. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-06-18 23:05 Message: Logged In: YES user_id=1188172 Interestingly, altering the behaviour of splitext in such a way does not contradict the documentation, which is: """ Split the pathname path into a pair (root, ext) such that root + ext == path, and ext is empty or begins with a period and contains at most one period. """ Personally I'm in favour of this change (on Unix it makes sense, while on Windows you can hardly find an "extension-only" file). ---------------------------------------------------------------------- Comment By: engelbert gruber (grubert) Date: 2005-06-13 16:12 Message: Logged In: YES user_id=147070 from test_posixpath.py :: self.assertEqual(posixpath.splitext(".ext"), ("", ".ext")) IMHO should then return (".ext",""). if this is desired :: if i<=p.rfind('/'): return p, '' else: return p[:i], p[i:] should do ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115886&group_id=5470 From noreply at sourceforge.net Wed Mar 7 12:38:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 03:38:34 -0800 Subject: [ python-Bugs-1550263 ] Enhance and correct unittest's docs (redux) Message-ID: Bugs item #1550263, was opened at 2006-09-01 02:02 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550263&group_id=5470 Please note that this 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 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Enhance and correct unittest's docs (redux) Initial Comment: Following up on SF #1534922 ("Cleanup/error-correction for unittest's docs"), this patch adds the following corrections and clairifications to Doc/lib/libunittest.tex: 1) Add language to the section on TestLoader.loadTestsFromName() to make it explicit in what order the "module/test case class/TestSuite instance/test method within a test case class/callable object which returns a TestCase or TestSuite instance" tests are applied. 2) Add language to the section on TestLoader.getTestCaseNames() to make it explicit that the method's argument should be a subclass of TestCase. 3) Add language to the docs for TestCase.run() to clairfying the relationship between TestCase.run() and TestCase.defaultTestResult(). 4) Better specify the purpose of TestCase.defaultTestResult(). The previous docs were vague and misleading. 5) Add language to the docs for the TestCase class that better explains and illustrates the class's purpose and usage. In particular, docs on the constructor's optional ``methodName'' parameter were added; this parameter was previously undocumented. 6) Add a brief mention of TestResult to the "Classes and functions" section. 7) Add information on the default implementation of several TestResult methods. In addition, numerous smaller tweaks to grammar and phrasing were made. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 11:38 Message: Logged In: YES user_id=849994 Originator: NO Now that there will be no 2.4.x anymore, closing again. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-09-01 04:02 Message: Logged In: YES user_id=3066 Re-opening; these should be considered for Python 2.4.4 as well. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-09-01 03:58 Message: Logged In: YES user_id=3066 Committed as revisions 51675 (Python 2.5) and 51676 (Python 2.6). Anthony agreed that documentation improvements were acceptable changes from 2.5 release candidate to 2.5 final. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550263&group_id=5470 From noreply at sourceforge.net Wed Mar 7 12:55:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 03:55:39 -0800 Subject: [ python-Bugs-878275 ] Handle: class MyTest(unittest.TestSuite) Message-ID: Bugs item #878275, was opened at 2004-01-16 14:22 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=878275&group_id=5470 Please note that this 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: Fixed Priority: 6 Private: No Submitted By: Raymond Hettinger (rhettinger) Assigned to: Steve Purcell (purcell) Summary: Handle: class MyTest(unittest.TestSuite) Initial Comment: TestCases are supposed to be derived from unittest.TestCase; however, if they are derived from unittest.TestSuite, the traceback is inexplicable and hard to diagnose: Traceback (most recent call last): File "C:/pydev/tmp.py", line 10, in -toplevel- unittest.TextTestRunner(verbosity=2).run(suite) File "C:\PY24\lib\unittest.py", line 690, in run test(result) File "C:\PY24\lib\unittest.py", line 423, in __call__ test(result) File "C:\PY24\lib\unittest.py", line 423, in __call__ test(result) File "C:\PY24\lib\unittest.py", line 423, in __call__ test(result) TypeError: 'str' object is not callable Let's either improve the error message or make it possible to derive from TestSuite. The above traceback is produced by the following script: import unittest class TestStats(unittest.TestSuite): def testtwo(self): self.assertEqual(2,2) suite = unittest.TestSuite() suite.addTest(unittest.makeSuite(TestStats)) unittest.TextTestRunner(verbosity=2).run(suite) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 11:55 Message: Logged In: YES user_id=849994 Originator: NO Added a few sanity checks in rev. 54207, 54208 (2.5). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 19:24 Message: Logged In: YES user_id=261020 In fact in jlgijsbers' case (TestSuite class passed to TestSuite, rather than another bug: TestCase class passed to TestSuite), that check just pushes the problem back a bit: import unittest class TestStats(unittest.TestSuite): def testtwo(self): self.assertEqual(2,2) suite = unittest.TestSuite([TestStats('testtwo')]) unittest.TextTestRunner(verbosity=2).run(suite) TypeError: 'str' object is not callable Another test could be added to TestSuite addTest(): if not callable(test): raise TypeError('addTest argument 1 must be callable') Again, though it does makes the error clearer, it seems debatable that it's worth the change... ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 18:52 Message: Logged In: YES user_id=261020 Just to be clear: The issue with jlgijsbers' odd error message (in his 2004-11-07 followup) is not that a TestSuite is passed to the TestSuite constructor, but rather that he's passing in a class, not an instance. The error would show up a bit earlier if a check were added to TestSuite.addTest(): if type(test) == type: raise TypeError('addTest argument 1 must be instance, not class') I will post that line as a patch if anyone emails me to request it! ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-11-07 15:53 Message: Logged In: YES user_id=469548 Well, the error message above has been fixed, but here's another equally confusing variant: import unittest class TestStats(unittest.TestSuite): def testtwo(self): self.assertEqual(2,2) suite = unittest.TestSuite([TestStats]) unittest.TextTestRunner(verbosity=2).run(suite) giving: Traceback (most recent call last): File "test-foo.py", line 8, in ? unittest.TextTestRunner(verbosity=2).run(suite) File "/home/johannes/python/Lib/unittest.py", line 695, in run test(result) File "/home/johannes/python/Lib/unittest.py", line 426, in __call__ test(result) File "/home/johannes/python/Lib/unittest.py", line 396, in __init__ self.addTests(tests) File "/home/johannes/python/Lib/unittest.py", line 416, in addTests for test in tests: TypeError: iteration over non-sequence so I'm leaving this open. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-11-07 13:39 Message: Logged In: YES user_id=129426 patch is at #1061904 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=878275&group_id=5470 From noreply at sourceforge.net Wed Mar 7 16:17:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 07:17:12 -0800 Subject: [ python-Bugs-1646728 ] datetime.fromtimestamp fails with negative fractional times Message-ID: Bugs item #1646728, was opened at 2007-01-28 21:21 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 Please note that this 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.5 Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.fromtimestamp fails with negative fractional times Initial Comment: The datetime.fromtimestamp() function works fine with integer timestamps and positive fractional timestamps, but fails if I pass a negative fractional timestamp. For example: >>> import datetime >>> datetime.datetime.fromtimestamp(-1.05) Traceback (most recent call last): File "", line 1, in ValueError: microsecond must be in 0..999999 It should return the same result as datetime.fromtimestamp(-1) - timedelta(seconds=.5). The same bug can be triggered in datetime.utcfromtimestamp(). I have been able to reproduce this bug in Python 2.4.4 and Python 2.5 on Linux. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-07 10:17 Message: Logged In: YES user_id=6380 Originator: NO Thanks! I'm skipping these tests on Windows now. Committed revision 54209. Georgbot, would you be so kind... :-) ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2007-03-07 02:34 Message: Logged In: YES user_id=1200846 Originator: NO Hello, I'm user of Windows (Now building Python2.5 with VC6) I heard localtime() can only handle positive time_t on windows, so datetime.fromtimestamp() also fails for negative value. >>> datetime.datetime.fromtimestamp(-1.05) Traceback (most recent call last): File "", line 1, in ValueError: timestamp out of range for platform localtime()/gmtime() function >>> datetime.datetime.fromtimestamp(-1) Traceback (most recent call last): File "", line 1, in ValueError: timestamp out of range for platform localtime()/gmtime() function I'll attach workaround for unittest. Probably there is better way skip this test on non-negative platform though :-) Index: Lib/test/test_datetime.py =================================================================== --- Lib/test/test_datetime.py (revision 54194) +++ Lib/test/test_datetime.py (working copy) @@ -1428,9 +1428,17 @@ def test_negative_float_fromtimestamp(self): # The result is tz-dependent; at least test that this doesn't # fail (like it did before bug 1646728 was fixed). + try: + self.theclass.fromtimestamp(-1) + except ValueError: # cannot handle negative value + return self.theclass.fromtimestamp(-1.05) def test_negative_float_utcfromtimestamp(self): + try: + self.theclass.utcfromtimestamp(-1) + except ValueError: # cannot handle negative value + return d = self.theclass.utcfromtimestamp(-1.05) self.assertEquals(d, self.theclass(1969, 12, 31, 23, 59, 58, 950000)) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 13:45 Message: Logged In: YES user_id=849994 Originator: NO Not from me, no Windows around. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 13:34 Message: Logged In: YES user_id=6380 Originator: NO That's too bad. More details? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 13:15 Message: Logged In: YES user_id=849994 Originator: NO Though, the new tests seem to fail on Windows (I noticed that only after backporting, since most other buildbot failures were due to the cmp/key problem in setup.py). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 12:59 Message: Logged In: YES user_id=6380 Originator: NO Georgbot backported this to 2.5. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 10:50 Message: Logged In: YES user_id=6380 Originator: NO Committed revision 54167. I'm leaving this open until it's been backported to the 2.5 branch. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 19:03 Message: Logged In: YES user_id=146903 Originator: YES I just tried the patch, and can confirm that it fixes the problem with datetime.fromtimestamp() and datetime.utcfromtimestamp(). The logic in the patch looks correct. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-05 13:38 Message: Logged In: YES user_id=6380 Originator: NO Attached is a fix. If this is to your liking I'll check it in. File Added: datetime.patch ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 05:23 Message: Logged In: YES user_id=146903 Originator: YES The problem seems to be in datetime_from_timestamp() from datetimemodule.c. It should probably be checking to see whether the microseconds value it calculates is negative, and adjust "timet" and "us" accordingly if so. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 11:05 Message: Logged In: YES user_id=6380 Originator: NO Looks like a bug in the conversion from floats to ints. Anyone care to track it down more precisely? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 From noreply at sourceforge.net Wed Mar 7 17:13:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 08:13:10 -0800 Subject: [ python-Bugs-1646728 ] datetime.fromtimestamp fails with negative fractional times Message-ID: Bugs item #1646728, was opened at 2007-01-29 02:21 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 Please note that this 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.5 >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.fromtimestamp fails with negative fractional times Initial Comment: The datetime.fromtimestamp() function works fine with integer timestamps and positive fractional timestamps, but fails if I pass a negative fractional timestamp. For example: >>> import datetime >>> datetime.datetime.fromtimestamp(-1.05) Traceback (most recent call last): File "", line 1, in ValueError: microsecond must be in 0..999999 It should return the same result as datetime.fromtimestamp(-1) - timedelta(seconds=.5). The same bug can be triggered in datetime.utcfromtimestamp(). I have been able to reproduce this bug in Python 2.4.4 and Python 2.5 on Linux. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 16:13 Message: Logged In: YES user_id=849994 Originator: NO Certainly. Backported in rev. 54211. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-07 15:17 Message: Logged In: YES user_id=6380 Originator: NO Thanks! I'm skipping these tests on Windows now. Committed revision 54209. Georgbot, would you be so kind... :-) ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2007-03-07 07:34 Message: Logged In: YES user_id=1200846 Originator: NO Hello, I'm user of Windows (Now building Python2.5 with VC6) I heard localtime() can only handle positive time_t on windows, so datetime.fromtimestamp() also fails for negative value. >>> datetime.datetime.fromtimestamp(-1.05) Traceback (most recent call last): File "", line 1, in ValueError: timestamp out of range for platform localtime()/gmtime() function >>> datetime.datetime.fromtimestamp(-1) Traceback (most recent call last): File "", line 1, in ValueError: timestamp out of range for platform localtime()/gmtime() function I'll attach workaround for unittest. Probably there is better way skip this test on non-negative platform though :-) Index: Lib/test/test_datetime.py =================================================================== --- Lib/test/test_datetime.py (revision 54194) +++ Lib/test/test_datetime.py (working copy) @@ -1428,9 +1428,17 @@ def test_negative_float_fromtimestamp(self): # The result is tz-dependent; at least test that this doesn't # fail (like it did before bug 1646728 was fixed). + try: + self.theclass.fromtimestamp(-1) + except ValueError: # cannot handle negative value + return self.theclass.fromtimestamp(-1.05) def test_negative_float_utcfromtimestamp(self): + try: + self.theclass.utcfromtimestamp(-1) + except ValueError: # cannot handle negative value + return d = self.theclass.utcfromtimestamp(-1.05) self.assertEquals(d, self.theclass(1969, 12, 31, 23, 59, 58, 950000)) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 18:45 Message: Logged In: YES user_id=849994 Originator: NO Not from me, no Windows around. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 18:34 Message: Logged In: YES user_id=6380 Originator: NO That's too bad. More details? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 18:15 Message: Logged In: YES user_id=849994 Originator: NO Though, the new tests seem to fail on Windows (I noticed that only after backporting, since most other buildbot failures were due to the cmp/key problem in setup.py). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 17:59 Message: Logged In: YES user_id=6380 Originator: NO Georgbot backported this to 2.5. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 15:50 Message: Logged In: YES user_id=6380 Originator: NO Committed revision 54167. I'm leaving this open until it's been backported to the 2.5 branch. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2007-03-06 00:03 Message: Logged In: YES user_id=146903 Originator: YES I just tried the patch, and can confirm that it fixes the problem with datetime.fromtimestamp() and datetime.utcfromtimestamp(). The logic in the patch looks correct. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-05 18:38 Message: Logged In: YES user_id=6380 Originator: NO Attached is a fix. If this is to your liking I'll check it in. File Added: datetime.patch ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 10:23 Message: Logged In: YES user_id=146903 Originator: YES The problem seems to be in datetime_from_timestamp() from datetimemodule.c. It should probably be checking to see whether the microseconds value it calculates is negative, and adjust "timet" and "us" accordingly if so. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 16:05 Message: Logged In: YES user_id=6380 Originator: NO Looks like a bug in the conversion from floats to ints. Anyone care to track it down more precisely? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 From noreply at sourceforge.net Wed Mar 7 19:16:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 10:16:08 -0800 Subject: [ python-Bugs-1675967 ] Python2.5 can't read a (complex) pickle build by python2.4 Message-ID: Bugs item #1675967, was opened at 2007-03-07 18:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675967&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michael Vogt (mvo) Assigned to: Nobody/Anonymous (nobody) Summary: Python2.5 can't read a (complex) pickle build by python2.4 Initial Comment: Part of gnome-app-install in ubuntu is a pickle data structure cache. If I create this pickle with python 2.4 and read it later with 2.5. I get the following error: $ python2.5 -c 'import pickle; pickle.load(open("/var/cache/app-install/menu.p"))' /usr/lib/python2.5/pickle.py:1124: DeprecationWarning: The sre module is deprecated, please import re. __import__(module) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/pickle.py", line 1370, in load return Unpickler(file).load() File "/usr/lib/python2.5/pickle.py", line 858, in load dispatch[key](self) File "/usr/lib/python2.5/pickle.py", line 1090, in load_global klass = self.find_class(module, name) File "/usr/lib/python2.5/pickle.py", line 1126, in find_class klass = getattr(mod, name) AttributeError: 'module' object has no attribute '_compile' With: $ python2.4 -c 'import pickle; pickle.load(open("/var/cache/app-install/menu.p"))' egon at top ~ $ It loads just fine. The test pickle can be found here: http://people.ubuntu.com/~mvo/gnome-app-install/menu.p.gz Cheers, Michael ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675967&group_id=5470 From noreply at sourceforge.net Wed Mar 7 20:27:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 11:27:51 -0800 Subject: [ python-Bugs-974757 ] urllib2's HTTPPasswordMgr and uri's with port numbers Message-ID: Bugs item #974757, was opened at 2004-06-17 09:09 Message generated for change (Comment added) made by akrherz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=974757&group_id=5470 Please note that this 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: Fixed Priority: 5 Private: No Submitted By: Chris Withers (fresh) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2's HTTPPasswordMgr and uri's with port numbers Initial Comment: Python 2.3.3 The title just about sums it up. If you add a password with a uri containing a port number using add_password, then it probably won't be returned by find_user_password. That's not right ;-) ---------------------------------------------------------------------- Comment By: Daryl Herzmann (akrherz) Date: 2007-03-07 13:27 Message: Logged In: YES user_id=341971 Originator: NO Just for anybody like me stumbling into this. It isn't fixed in python 2.4.3 and only works in python 2.5 . Another reason to upgrade :) ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2004-12-22 08:27 Message: Logged In: YES user_id=31392 Fixed in rev 1.78 of urllib2 ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2004-11-05 04:08 Message: Logged In: YES user_id=24723 This patch fixes it for me: --- urllib2.py.cvs Fri Nov 05 10:02:26 2004 +++ urllib2.py.new Fri Nov 05 10:05:48 2004 @@ -720,7 +720,7 @@ return self.retry_http_basic_auth(host, req, realm) def retry_http_basic_auth(self, host, req, realm): - user,pw = self.passwd.find_user_password(realm, host) + user,pw = self.passwd.find_user_password(realm, req.get_full_url()) if pw is not None: raw = "%s:%s" % (user, pw) auth = 'Basic %s' % base64.encodestring(raw).strip() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=974757&group_id=5470 From noreply at sourceforge.net Wed Mar 7 20:43:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 11:43:19 -0800 Subject: [ python-Bugs-1675967 ] Python2.5 can't read a (complex) pickle build by python2.4 Message-ID: Bugs item #1675967, was opened at 2007-03-07 19:16 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675967&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michael Vogt (mvo) Assigned to: Nobody/Anonymous (nobody) Summary: Python2.5 can't read a (complex) pickle build by python2.4 Initial Comment: Part of gnome-app-install in ubuntu is a pickle data structure cache. If I create this pickle with python 2.4 and read it later with 2.5. I get the following error: $ python2.5 -c 'import pickle; pickle.load(open("/var/cache/app-install/menu.p"))' /usr/lib/python2.5/pickle.py:1124: DeprecationWarning: The sre module is deprecated, please import re. __import__(module) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/pickle.py", line 1370, in load return Unpickler(file).load() File "/usr/lib/python2.5/pickle.py", line 858, in load dispatch[key](self) File "/usr/lib/python2.5/pickle.py", line 1090, in load_global klass = self.find_class(module, name) File "/usr/lib/python2.5/pickle.py", line 1126, in find_class klass = getattr(mod, name) AttributeError: 'module' object has no attribute '_compile' With: $ python2.4 -c 'import pickle; pickle.load(open("/var/cache/app-install/menu.p"))' egon at top ~ $ It loads just fine. The test pickle can be found here: http://people.ubuntu.com/~mvo/gnome-app-install/menu.p.gz Cheers, Michael ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-07 20:43 Message: Logged In: YES user_id=1326842 Originator: NO This happens because of SRE_Pattern objects in jour pickle. The sre module was renamed to re in Python 2.5, but the old pickles still expect the _compile function in sre module. I posted the patch here: http://freeweb.siol.net/chollus/ Could you try if it fixes the problem for you and in that case, attach it to this report? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675967&group_id=5470 From noreply at sourceforge.net Wed Mar 7 20:55:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 11:55:42 -0800 Subject: [ python-Feature Requests-665194 ] datetime-RFC2822 roundtripping Message-ID: Feature Requests item #665194, was opened at 2003-01-09 19:24 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=665194&group_id=5470 Please note that this 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 Private: No Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: datetime-RFC2822 roundtripping Initial Comment: It would be good to have a simply way to convert between datetime objects and RFC2822 style strings. >From string to datetime is easy with datetime.datetime(*email.Utils.parsedate(m)[:7]) (but this drops the timezone), but the other direction seems impossible. email.Utils.formatdate takes a timestamp argument, but AFAICT there's no way to get a timestamp out of a datetime object. Of course the best solution (ignoring backwards compatibility) would be for parsedate und formatdate to return/accept datetime objects or for datetime to have the appropriate methods. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2007-03-07 20:55 Message: Logged In: YES user_id=89016 Originator: YES Here is a patch that implements to formatting part. It adds a method mimeformat() to the datetime class. The datetime object must have a tzinfo for this to work. File Added: datetime-mimeformat.diff ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-21 16:16 Message: Logged In: YES user_id=11375 Originator: NO Moving to feature requests. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-26 18:56 Message: Logged In: YES user_id=89016 time.strptime() is locale aware, but RFC1123 & RFC822 require english day and month names, so time.strptime() can't be used as-is. (And of course time.strptime() only works for formatting, not for parsing) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-24 00:46 Message: Logged In: YES user_id=357491 time.strptime doesn't solve your problem? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-01-13 14:05 Message: Logged In: YES user_id=89016 totimestamp() should be the inverse of fromtimestamp(), i.e. foo.totimestamp() should be the same as time.mktime(foo.timetuple()). datetime.datetime.totimestamp() should raise OverflowError iff time.mktime() raises OverflowError. But as this may lose precision, I'd say it would be better, if datetime supported RFC1123 conversion directly, i.e. two methods frommime() and tomime(), that parse and format strings like "Sun, 06 Nov 1994 08:49:37 GMT" (what rfc822.parsedate() and rfc822.formatdate() do) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-11 17:32 Message: Logged In: YES user_id=31435 Define what totimestamp() should do. The range of timestamps supported by the *platform* C library (and so indirectly by Python's time module) isn't defined by any standard, and isn't easily discoverable either. It may or may not work before 1970, may or may not after 2038. datetime covers days far outside that range. Note that even a double doesn't have enough bits of precision to cover the full range of datetime values, either. In contrast, ordinals are wholly under Python's control, so we can promise surprise-free conversion in both directions. All we can promise about timestamps is that if the platform supports a timestamp for a time in datetime's range, datetime can make sense of it. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-01-11 13:33 Message: Logged In: YES user_id=89016 OK, I'll mark this a feature request. datetime has fromordinal() and toordinal(), it has fromtimestamp(), so I'd say a totimestamp() method would be a logical addition. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-11 06:10 Message: Logged In: YES user_id=31435 You can get a timestamp like so: >>> time.mktime(datetime.date(2002, 1, 1).timetuple()) 1009861200.0 >>> The dates for which this works depends on the platform mktime implementation, though. BTW, this sounds a lot more like a new feature request than a bug! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=665194&group_id=5470 From noreply at sourceforge.net Wed Mar 7 23:07:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 14:07:56 -0800 Subject: [ python-Bugs-1676121 ] Problem linking to readline lib on x86(64) Solaris Message-ID: Bugs item #1676121, was opened at 2007-03-07 17:07 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=1676121&group_id=5470 Please note that this 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 Private: No Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Problem linking to readline lib on x86(64) Solaris Initial Comment: Configuring with ./configure --with-gcc="gcc -m64 -L/usr/sfw/lib/64 -R/usr/sfw/lib/64" where 64bit libreadline is found in /usr/sfw/lib/64, configure script fails to realize that readline lib is present. I was able to fix the problem by editing config script manually as follows: $ diff configure~ configure 20744c20744 < if test "$ac_cv_have_readline_readline" = no --- > if test "$ac_cv_lib_readline_readline" = no 20747c20747 < echo "$as_me:$LINENO: checking for readline in -ltermcap" >&5 --- > echo "$as_me:$LINENO: checking for readline in -lreadline -ltermcap" >&5 20753c20753 < LIBS="-ltermcap $LIBS" --- > LIBS="-lreadline -ltermcap $LIBS" A proper fix would be to change configure.in, but I don't know enough about autoconf to submit a proper patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676121&group_id=5470 From noreply at sourceforge.net Thu Mar 8 01:30:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 16:30:42 -0800 Subject: [ python-Bugs-1647654 ] No obvious and correct way to get the time zone offset Message-ID: Bugs item #1647654, was opened at 2007-01-30 06:48 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1647654&group_id=5470 Please note that this 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 Private: No Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: No obvious and correct way to get the time zone offset Initial Comment: It would be nice if the Python time module provided an obvious way to get the local time UTC offset for an arbitrary time stamp. The existing constants included in the module are not sufficient to correctly determine this value. As context, the Bazaar version control system (written in Python), the local time UTC offset is recorded in a commit. The method used in releases prior to 0.14 made use of the "daylight", "timezone" and "altzone" constants from the time module like this: if time.localtime(t).tm_isdst and time.daylight: return -time.altzone else: return -time.timezone This worked most of the time, but would occasionally give incorrect results. On Linux, the local time system can handle different daylight saving rules for different spans of years. For years where the rules change, these constants can provide incorrect data. Furthermore, they may be incorrect for time stamps in the past. I personally ran into this problem last December when Western Australia adopted daylight saving -- time.altzone gave an incorrect value until the start of 2007. Having a function in the standard library to calculate this offset would solve the problem. The implementation we ended up with for Bazaar was: offset = datetime.fromtimestamp(t) - datetime.utcfromtimestamp(t) return offset.days * 86400 + offset.seconds Another alternative would be to expose tm_gmtoff on time tuples (perhaps using the above code to synthesise it on platforms that don't have the field). ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-08 01:30 Message: Logged In: YES user_id=226443 Originator: NO Patch #1667546 now tries to export tm_gmtoff in a covertly extended time tuple. (I think tm_gmtoff originates from BSD, by the way.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 23:39 Message: Logged In: YES user_id=6380 Originator: NO I see. There is code to decide the values for time.timezone, time.altzone and time.daylight that compares tm_gmtoff for Jan 1st of the current year to tm_gmtoff for July 1st; it uses this to decide whether DST is in effect and on which hemisphere you're on. I don't know why I didn't think of checking the tm_isdst flag instead, but either way the code would have failed for you prior to Jan 1st 07, because it could not have seen a difference if your timezone database was correct. You're just lucky you weren't running CYGWIN; the code inside #ifdef __CYGWIN__ doesn't even entertain the possibility that there's life possible on the Southern hemisphere. ;-) I think we should do two things; (a) export tm_zone and tm_gmtoff if they exist; (b) change the code that probes Jan 1st and Jul 1st of the current year to instead probe 4-6 spots starting today and covering the year forward. Unfortunately tm_zone and tm_gmtoff appear glibc inventions, so for supporting Solaris, Windows etc. I think we still need these. We really could use a module that accesses the entire timezone database but that's even more platform specific. If you want this to happen, please lobby for someone to help out on python-dev or c.l.py; I'm kind of overcommitted. :-) ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 11:03 Message: Logged In: YES user_id=146903 Originator: YES In Western Australia, a 3 year daylight saving trial was introduced starting on 3rd December 2006. Prior to that, we had no daylight saving shifts (the previous time we had daylight saving was 15 years ago in another trial). Since there was no daylight savings for 1st January 2006 and 1st July 2006, time.timezone and time.altzone were both equal to -28800 (UTC+8) for Python interpreters run in 2006. I am sure that I had the tzdata updates installed: my computer displayed the correct time, and listed the UTC offset as +0900 in December. Creating a time tuple for a date in December 2006 had the tm_isdst flag set to 1. If I was programming this in C, I'd use the tm_gmtoff field of "struct tm" if it was available. On platforms that don't provide tm_gmtoff, other platform specific methods would be needed (e.g. using timezone/altzone). The other alternative is to do date arithmetic on the results of localtime() and gmtime(), as you say. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 16:48 Message: Logged In: YES user_id=6380 Originator: NO Hm.... I'm not sure I understand why the first bit of code didn't work. Can you give a concrete example? (I.e. what was t, what was returned by localtime(t), and what were the three time variables that day.) I don't know the details of Western Australia's DST change. But looking at the source of timemodule.c, I notice that it simply samples the timezone on Jan 1st and July 1st, and if they differ, decides which one is summer time by which one is smaller. Your remark that the problem righted itself in January makes me wonder -- between what dates did you have DST? Alternatively, it could be that your system simply didn't have the correct DST change data loaded yet (this happens all the time when governments change the rules). Can you rule that out? I really don't want to have to change Python in order to correct for *that* problem. Yet another question, if you were to code this in C, how would you write it? Regardless, I think that it would be useful to support tm_gmtoff and other struct tm entries, the same way that we do this in struct stat. You could probably also get the correct result (assuming your system's timezone database is correct) by comparing localtime() and gmtime(). But the reverse engineering is a bit painful; your trick using datetime essentially does that. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2007-03-01 11:09 Message: Logged In: YES user_id=146903 Originator: YES The localtime_tz() function sounds like it would probably fit the bill. Another option would be to expose tm_gmtoff and tm_zone as non-sequence fields of time.struct_time for systems that support them. This would provide the data without needing new APIs. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-02-24 01:31 Message: Logged In: YES user_id=226443 Originator: NO See patch #1667546 for a time module function returning extended time tuples. The datetime-based solution you provide is quite a clever workaround using "naive" datetime objects, but I'm inclined to think that some more convenient way of getting "aware" datetime objects would be nicer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1647654&group_id=5470 From noreply at sourceforge.net Thu Mar 8 04:57:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 19:57:53 -0800 Subject: [ python-Bugs-1671411 ] python code fails with "MemoryError" on HP-UX 11.11 PA_RISC Message-ID: Bugs item #1671411, was opened at 2007-03-01 11:27 Message generated for change (Comment added) made by shashikala You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671411&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Performance Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: shashi (shashikala) Assigned to: Nobody/Anonymous (nobody) Summary: python code fails with "MemoryError" on HP-UX 11.11 PA_RISC Initial Comment: Hi, Python-2.5 code fails with "MemoryError". This is happening only on one system, PA-RISC running HP-UX 11.11.Failing system has 12 GB of RAM installed, non-failing system has 8 GB. 1) spark 9GB phys mem(Python is working fine) 2) stalker 12GB phys mem (that has problem with python 2.5 ) please assist me in this. Thanks in advance Shashi ---------------------------------------------------------------------- >Comment By: shashi (shashikala) Date: 2007-03-08 10:57 Message: Logged In: YES user_id=1506183 Originator: YES Hi , I added "import gc" and "gc.collect()" , it worked out fine , I dint get any further MemoryError is this the correct approach , please let me know about the same. Thanks and Reagrds, shashi ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-02 04:34 Message: Logged In: YES user_id=21627 Originator: NO Can you also provide a gdb/dbx backtrace of where the problem occurred? ---------------------------------------------------------------------- Comment By: shashi (shashikala) Date: 2007-03-01 18:47 Message: Logged In: YES user_id=1506183 Originator: YES File Added: Pythonmemoryerror.txt ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-01 13:38 Message: Logged In: YES user_id=21627 Originator: NO This tracker is not about assistance. If at all, we need you to assist us. Can you please report more details, like stack traces, causes of the crash, patches? If not, I think there is little we can do about this report ("it crashes" is pretty unspecific). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671411&group_id=5470 From noreply at sourceforge.net Thu Mar 8 05:00:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 20:00:51 -0800 Subject: [ python-Feature Requests-1673409 ] datetime module missing some important methods Message-ID: Feature Requests item #1673409, was opened at 2007-03-04 06:59 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673409&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jon Ribbens (jribbens) >Assigned to: Tim Peters (tim_one) Summary: datetime module missing some important methods Initial Comment: The datetime module is missing some important methods for interacting with timestamps (i.e. seconds since 1970-01-01T00:00:00). There are methods to convert from a timestamp, i.e. date.fromtimestamp and datetime.fromtimestamp, but there are no methods to convert back. In addition, timedelta has no method for returning the number of seconds it represents (i.e. days*86400+seconds+microseconds/1000000). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673409&group_id=5470 From noreply at sourceforge.net Thu Mar 8 07:25:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 22:25:20 -0800 Subject: [ python-Bugs-1643369 ] function breakpoints in pdb Message-ID: Bugs item #1643369, was opened at 2007-01-24 02:22 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1643369&group_id=5470 Please note that this 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: 6 Private: No Submitted By: decitre (decitre) Assigned to: Nobody/Anonymous (nobody) Summary: function breakpoints in pdb Initial Comment: pdb.Pdb.find_function method is not able to recognize class methods, since the regular expression it uses only looks for "def" at beginning of lines. Please replace r'def\s+%s\s*[(]' % funcname with r'\s*def\s+%s\s*[(]' % funcname test file in attachment. this file shows that pdb can set a breakpoint on foo but not on readline function. Regards, Emmanuel www.e-rsatz.info ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2007-03-07 22:25 Message: Logged In: YES user_id=971153 Originator: NO I think it's a bit more complicated than it seems: it's more than common for different classes to have methods with the same name. So looking for "\s*def func" will just grab the first matching method...Which is probably not what one would want...And dealing with multiple matches might be more hassle than it's worth.. So maybe the current behaviour should be kept as is NOTE: you CAN currently set breakpoints in methods by doing b Class.method ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1643369&group_id=5470 From noreply at sourceforge.net Thu Mar 8 09:50:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 00:50:01 -0800 Subject: [ python-Bugs-1676321 ] scheduler.empty() in module sched appears broken Message-ID: Bugs item #1676321, was opened at 2007-03-08 00: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=1676321&group_id=5470 Please note that this 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 Private: No Submitted By: Mark (theshtat) Assigned to: Nobody/Anonymous (nobody) Summary: scheduler.empty() in module sched appears broken Initial Comment: In: Python 2.5 (r25:51918, Sep 19 2006, 08:49:13) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin The sched.scheduler.empty() method appears to be broken. Its implementation is: return not not self.queue Which returns true when the event queue is *not* empty. http://www.google.com/codesearch?hl=en&q=+file:sched.py+%22not+not%22+show:_EUH1sHctjI:SV8rbKB68UQ:wZlnTyplW4c&sa=N&cd=1&ct=rc&cs_p=http://svn.python.org/snapshots/python25.tar.bz2&cs_f=python/Lib/sched.py#a0 Other Python builds seem to have a correct implementation: http://www.google.com/codesearch?hl=en&q=+file:sched.py+%22len(self.queue)%22+show:tKxWDv9S6Xg:d-f-3CzYpHc:iU9xQ6L5s1s&sa=N&cd=1&ct=rc&cs_p=http://www.python.org/ftp/python/2.4.3/Python-2.4.3.tar.bz2&cs_f=Python-2.4.3/Lib/sched.py#a0 Thanks, Mark mayzenshtat at) gmail (dot com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676321&group_id=5470 From noreply at sourceforge.net Thu Mar 8 10:19:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 01:19:39 -0800 Subject: [ python-Bugs-1671411 ] python code fails with "MemoryError" on HP-UX 11.11 PA_RISC Message-ID: Bugs item #1671411, was opened at 2007-03-01 05:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671411&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Performance Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: shashi (shashikala) Assigned to: Nobody/Anonymous (nobody) Summary: python code fails with "MemoryError" on HP-UX 11.11 PA_RISC Initial Comment: Hi, Python-2.5 code fails with "MemoryError". This is happening only on one system, PA-RISC running HP-UX 11.11.Failing system has 12 GB of RAM installed, non-failing system has 8 GB. 1) spark 9GB phys mem(Python is working fine) 2) stalker 12GB phys mem (that has problem with python 2.5 ) please assist me in this. Thanks in advance Shashi ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-08 10:19 Message: Logged In: YES user_id=21627 Originator: NO If you think your problem is solved, then fine (you seem to have found a work-around). If Python raises a MemoryError, this is still a problem; it sholdn't normally do that, and it should normally invoke garbage collection itself. To analyse this further, we still would need a debug stack trace. However, I'm closing this as "won't fix" now; if you ever feel like analysing it further, and have data to help there, feel free to reopen the report. ---------------------------------------------------------------------- Comment By: shashi (shashikala) Date: 2007-03-08 04:57 Message: Logged In: YES user_id=1506183 Originator: YES Hi , I added "import gc" and "gc.collect()" , it worked out fine , I dint get any further MemoryError is this the correct approach , please let me know about the same. Thanks and Reagrds, shashi ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-01 22:34 Message: Logged In: YES user_id=21627 Originator: NO Can you also provide a gdb/dbx backtrace of where the problem occurred? ---------------------------------------------------------------------- Comment By: shashi (shashikala) Date: 2007-03-01 12:47 Message: Logged In: YES user_id=1506183 Originator: YES File Added: Pythonmemoryerror.txt ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-01 07:38 Message: Logged In: YES user_id=21627 Originator: NO This tracker is not about assistance. If at all, we need you to assist us. Can you please report more details, like stack traces, causes of the crash, patches? If not, I think there is little we can do about this report ("it crashes" is pretty unspecific). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671411&group_id=5470 From noreply at sourceforge.net Thu Mar 8 17:34:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 08:34:55 -0800 Subject: [ python-Bugs-1676656 ] Stdlib reference is in italics Message-ID: Bugs item #1676656, was opened at 2007-03-08 17: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=1676656&group_id=5470 Please note that this 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 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Stdlib reference is in italics Initial Comment: The development version of the stdlib reference is messed up. All pages after this one http://docs.python.org/dev/lib/module-SocketServer.html has all the text in italics. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676656&group_id=5470 From noreply at sourceforge.net Thu Mar 8 18:50:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 09:50:40 -0800 Subject: [ python-Bugs-1676656 ] Stdlib reference is in italics Message-ID: Bugs item #1676656, was opened at 2007-03-08 16:34 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676656&group_id=5470 Please note that this 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 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Stdlib reference is in italics Initial Comment: The development version of the stdlib reference is messed up. All pages after this one http://docs.python.org/dev/lib/module-SocketServer.html has all the text in italics. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 17:50 Message: Logged In: YES user_id=849994 Originator: NO The problem was that \em sets italics for the whole LaTeX "scope" while \emph does that only for the following argument. Fixed in rev. 54220, 54221 (2.5) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676656&group_id=5470 From noreply at sourceforge.net Thu Mar 8 19:19:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 10:19:02 -0800 Subject: [ python-Bugs-1514617 ] evaluated code filename changed to instead of ? Message-ID: Bugs item #1514617, was opened at 2006-06-29 16:07 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514617&group_id=5470 Please note that this 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.5 >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: James Y Knight (foom) Assigned to: Nobody/Anonymous (nobody) Summary: evaluated code filename changed to instead of ? Initial Comment: It seems as though the default filename for evaluated changed from "?" to "". Was this intentional? (it's causing some test failures for me. The tests are correctable of course, but it doesn't seem to be an obvious improvement in behavior, so if it wasn't intentional, perhaps it should be changed back.) Python 2.3.5 (#1, Mar 20 2005, 20:38:20) [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin >>> eval("0/0") Traceback (most recent call last): File "", line 1, in ? File "", line 0, in ? Python 2.5b1 (trunk:47096, Jun 25 2006, 23:18:21) [GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin >>> eval("0/0") Traceback (most recent call last): File "", line 1, in File "", line 1, in ZeroDivisionError: integer division or modulo by zero ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-08 13:18 Message: Logged In: YES user_id=1344176 Originator: NO 1) An interpreter session is essentially a module that the user types in, one statement at a time. 2) "?" tells me considerably less about where the error occurred than does "". "?" could mean anything. 3) Since Python 2.5 has already been released with the objected-to behavior, I'd say it's incredibly unlikely that this change will be reverted. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2006-07-02 16:20 Message: Logged In: YES user_id=366566 Also see https://sourceforge.net/tracker/?func=detail&aid=1512007&group_id=5470&atid=305470 for a patch to revert to the old behavior. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2006-07-02 16:18 Message: Logged In: YES user_id=366566 Note that in the example James included, the code is /not/ in a module. A clear improvement to me would be to say something like or in the case James pasted and for the case of top-level code. "" is about as information-free as "?". ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-07-01 14:26 Message: Logged In: YES user_id=1344176 For me, this is indeed an obvious improvement in behaviour. "" is a much clearer indicator of where the code in question is located; using "?" could mean that it's anywhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514617&group_id=5470 From noreply at sourceforge.net Thu Mar 8 19:24:35 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 10:24:35 -0800 Subject: [ python-Bugs-1676321 ] scheduler.empty() in module sched appears broken Message-ID: Bugs item #1676321, was opened at 2007-03-08 08:50 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676321&group_id=5470 Please note that this 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 Private: No Submitted By: Mark (theshtat) >Assigned to: Raymond Hettinger (rhettinger) Summary: scheduler.empty() in module sched appears broken Initial Comment: In: Python 2.5 (r25:51918, Sep 19 2006, 08:49:13) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin The sched.scheduler.empty() method appears to be broken. Its implementation is: return not not self.queue Which returns true when the event queue is *not* empty. http://www.google.com/codesearch?hl=en&q=+file:sched.py+%22not+not%22+show:_EUH1sHctjI:SV8rbKB68UQ:wZlnTyplW4c&sa=N&cd=1&ct=rc&cs_p=http://svn.python.org/snapshots/python25.tar.bz2&cs_f=python/Lib/sched.py#a0 Other Python builds seem to have a correct implementation: http://www.google.com/codesearch?hl=en&q=+file:sched.py+%22len(self.queue)%22+show:tKxWDv9S6Xg:d-f-3CzYpHc:iU9xQ6L5s1s&sa=N&cd=1&ct=rc&cs_p=http://www.python.org/ftp/python/2.4.3/Python-2.4.3.tar.bz2&cs_f=Python-2.4.3/Lib/sched.py#a0 Thanks, Mark mayzenshtat at) gmail (dot com ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 18:24 Message: Logged In: YES user_id=849994 Originator: NO This was your change, Raymond. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676321&group_id=5470 From noreply at sourceforge.net Thu Mar 8 20:25:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 11:25:49 -0800 Subject: [ python-Bugs-1676321 ] scheduler.empty() in module sched appears broken Message-ID: Bugs item #1676321, was opened at 2007-03-08 03:50 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676321&group_id=5470 Please note that this 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: Fixed Priority: 5 Private: No Submitted By: Mark (theshtat) Assigned to: Raymond Hettinger (rhettinger) Summary: scheduler.empty() in module sched appears broken Initial Comment: In: Python 2.5 (r25:51918, Sep 19 2006, 08:49:13) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin The sched.scheduler.empty() method appears to be broken. Its implementation is: return not not self.queue Which returns true when the event queue is *not* empty. http://www.google.com/codesearch?hl=en&q=+file:sched.py+%22not+not%22+show:_EUH1sHctjI:SV8rbKB68UQ:wZlnTyplW4c&sa=N&cd=1&ct=rc&cs_p=http://svn.python.org/snapshots/python25.tar.bz2&cs_f=python/Lib/sched.py#a0 Other Python builds seem to have a correct implementation: http://www.google.com/codesearch?hl=en&q=+file:sched.py+%22len(self.queue)%22+show:tKxWDv9S6Xg:d-f-3CzYpHc:iU9xQ6L5s1s&sa=N&cd=1&ct=rc&cs_p=http://www.python.org/ftp/python/2.4.3/Python-2.4.3.tar.bz2&cs_f=Python-2.4.3/Lib/sched.py#a0 Thanks, Mark mayzenshtat at) gmail (dot com ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-03-08 14:25 Message: Logged In: YES user_id=80475 Originator: NO Fixed in revs 54224 and 54225. Thanks for the bug report. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 13:24 Message: Logged In: YES user_id=849994 Originator: NO This was your change, Raymond. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676321&group_id=5470 From noreply at sourceforge.net Thu Mar 8 21:55:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 12:55:46 -0800 Subject: [ python-Bugs-1673403 ] date-datetime comparison doesn't work Message-ID: Bugs item #1673403, was opened at 2007-03-04 06:51 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673403&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jon Ribbens (jribbens) Assigned to: Nobody/Anonymous (nobody) Summary: date-datetime comparison doesn't work Initial Comment: Summary: bug #1028306 was not a bug, but the fix for it introduced one Comparing a date to a datetime currently throws an exception. This makes no sense. In what way is: datetime(2006, 1, 1, 0, 0, 0) < date(2007, 1, 1) not a perfectly reasonable and well-defined comparison? Throwing an exception here violates the "Principle of Least Surprise" to a considerable degree. Obviously some slight ambiguity arises if the date and the datetime differ only in the time part. There are two sensible responses in this situation that I can see: Treat dates as if they have a time-part of midnight. This is my preferred solution, and it is already what the datetime module does, for example, when subtracting two dates. Treat dates as if they refer to the entire day, i.e. if the date and datetime differ only in the time part then they are equal. This is consistent but becomes confusing in other situations such as when subtracting dates. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-08 15:55 Message: Logged In: YES user_id=1344176 Originator: NO I think this warrants discussion on python-dev (http://mail.python.org/mailman/listinfo/python-dev) as to which of the two date interpretations to pick. Please post a description of the problem there and ask for suggestions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673403&group_id=5470 From noreply at sourceforge.net Thu Mar 8 22:09:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 13:09:53 -0800 Subject: [ python-Bugs-1673403 ] date-datetime comparison doesn't work Message-ID: Bugs item #1673403, was opened at 2007-03-04 06:51 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673403&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jon Ribbens (jribbens) >Assigned to: Tim Peters (tim_one) Summary: date-datetime comparison doesn't work Initial Comment: Summary: bug #1028306 was not a bug, but the fix for it introduced one Comparing a date to a datetime currently throws an exception. This makes no sense. In what way is: datetime(2006, 1, 1, 0, 0, 0) < date(2007, 1, 1) not a perfectly reasonable and well-defined comparison? Throwing an exception here violates the "Principle of Least Surprise" to a considerable degree. Obviously some slight ambiguity arises if the date and the datetime differ only in the time part. There are two sensible responses in this situation that I can see: Treat dates as if they have a time-part of midnight. This is my preferred solution, and it is already what the datetime module does, for example, when subtracting two dates. Treat dates as if they refer to the entire day, i.e. if the date and datetime differ only in the time part then they are equal. This is consistent but becomes confusing in other situations such as when subtracting dates. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-03-08 16:09 Message: Logged In: YES user_id=80475 Originator: NO Tim, any thoughts? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-08 15:55 Message: Logged In: YES user_id=1344176 Originator: NO I think this warrants discussion on python-dev (http://mail.python.org/mailman/listinfo/python-dev) as to which of the two date interpretations to pick. Please post a description of the problem there and ask for suggestions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673403&group_id=5470 From noreply at sourceforge.net Thu Mar 8 22:19:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 13:19:01 -0800 Subject: [ python-Bugs-1628987 ] inspect trouble when source file changes Message-ID: Bugs item #1628987, was opened at 2007-01-05 13:43 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1628987&group_id=5470 Please note that this 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 Private: No Submitted By: phil (philipdumont) Assigned to: Nobody/Anonymous (nobody) Summary: inspect trouble when source file changes Initial Comment: backtrace (relevant outer frames only): File "/path/to/myfile", line 1198, in get_hook_name for frame_record in inspect.stack(): File "/usr/mbench2.2/lib/python2.4/inspect.py", line 819, in stack return getouterframes(sys._getframe(1), context) File "/usr/mbench2.2/lib/python2.4/inspect.py", line 800, in getouterframes framelist.append((frame,) + getframeinfo(frame, context)) File "/usr/mbench2.2/lib/python2.4/inspect.py", line 775, in getframeinfo lines, lnum = findsource(frame) File "/usr/mbench2.2/lib/python2.4/inspect.py", line 437, in findsource if pat.match(lines[lnum]): break IndexError: list index out of range Based on a quick look at the inspect code, I think this happens when you: - Start python and load a module - While it's running, edit the source file for the module (before inspect tries to look into it). - Call a routine in the edited module that will lead to a call to inspect.stack(). During an inspect.stack() call, inspect will open source files to get the source code for the routines on the stack. If the source file that is opened doesn't match the byte compiled code that's being run, there are problems. Inspect caches the files it reads (using the linecache module), so if the file gets cached before it is edited, nothing should go wrong. But if the source file is edited after the module is loaded and before inspect has a chance to cache the source, you're out of luck. Of course, this shouldn't be a problem in production code, but it has bit us more than once in a development environment. Seems like it would be easy to avoid by just comparing the timestamps on the source/object files. If the source file is newer, just behave the same as if it wasn't there. Attached is a stupid little python script that reproduces the problem. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-08 16:19 Message: Logged In: YES user_id=1344176 Originator: NO Could you possibly work up a patch demonstrating exactly what you're proposing with the "comparing the timestamps" solution? That seems like a lot of complication for such a rare issue, but I'd be interested in seeing a patch all the same. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1628987&group_id=5470 From noreply at sourceforge.net Thu Mar 8 22:30:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 13:30:04 -0800 Subject: [ python-Bugs-1676656 ] Stdlib reference is in italics Message-ID: Bugs item #1676656, was opened at 2007-03-08 17:34 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676656&group_id=5470 Please note that this 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 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Stdlib reference is in italics Initial Comment: The development version of the stdlib reference is messed up. All pages after this one http://docs.python.org/dev/lib/module-SocketServer.html has all the text in italics. ---------------------------------------------------------------------- >Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-08 22:30 Message: Logged In: YES user_id=51702 Originator: YES That was FAST. Thanks! ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 18:50 Message: Logged In: YES user_id=849994 Originator: NO The problem was that \em sets italics for the whole LaTeX "scope" while \emph does that only for the following argument. Fixed in rev. 54220, 54221 (2.5) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676656&group_id=5470 From noreply at sourceforge.net Thu Mar 8 22:35:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 13:35:32 -0800 Subject: [ python-Bugs-1637850 ] make_table in difflib does not work with unicode Message-ID: Bugs item #1637850, was opened at 2007-01-17 11:22 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1637850&group_id=5470 Please note that this 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: Fixed Priority: 5 Private: No Submitted By: y-unno (y-unno) >Assigned to: Raymond Hettinger (rhettinger) Summary: make_table in difflib does not work with unicode Initial Comment: make_table function in difflib.HtmlDiff does not work correctly when input strings are unicode. This is because the library uses cStringIO.StringIO classes, and cStringIO.StringIO returns strings encoded by the default encoding. When the default encoding is 'ascii', for example, this behaviour becomes a problem because some unicode characters cannot be encoded in 'ascii'. So, please change cStringIO to StringIO in difflib.py. When I use StringIO in difflib.py, this function returns unicode strings and no problems occured. This problem occured in Python 2.5/2.4 on Windows XP. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-03-08 16:35 Message: Logged In: YES user_id=80475 Originator: NO Fixed in revs 54229 and 54230. It wasn't necessary to use StringIO at all. A simple list of strings and join works fine (and handles unicode transparently). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-01-17 16:13 Message: Logged In: YES user_id=849994 Originator: NO I don't know. Perhaps we should rather fix cStringIO to accept Unicode strings. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1637850&group_id=5470 From noreply at sourceforge.net Thu Mar 8 22:38:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 13:38:57 -0800 Subject: [ python-Feature Requests-1624674 ] webbrowser.open_new() suggestion Message-ID: Feature Requests item #1624674, was opened at 2006-12-29 19:03 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1624674&group_id=5470 Please note that this 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 Private: No Submitted By: Imre P?ntek (imi1984) Assigned to: Georg Brandl (gbrandl) Summary: webbrowser.open_new() suggestion Initial Comment: Hello, under Linux if I use webbrowser.open_new('...') a konqueror gets invoked. At the time when invoking konqueror (maybe you probe first, but anyways) you assume that user has a properly installed kde. But if you assume the user has a properly installed KDE you have a better opportunity to open a webpage, even in the browser preferred by the user -- no matter really what it is. Try this one: kfmclient exec http://sourceforge.net/ using this one the client associated with .html in kcontrol gets invoked. I suppose that (becouse of the ability to customize the browser) this way would be better if available than guessing which browser would the user prefer. ---------------------------------------------------------------------- Comment By: Mark Roberts (mark-roberts) Date: 2007-01-14 18:08 Message: Logged In: YES user_id=1591633 Originator: NO A quick look at the code makes me think that it does try to run kfmclient first. Specifically, line 351 of webbrowser.py tries kfmclient, while like line 363 of webbrowser.py opens konqueror. I don't really run KDE, Gnome, or Windows, so I'm not a lot of help for testing this for you. I can, however, tell you that it does the "right thing" for me, in that it opens Firefox. When I did Python development on Windows, it also "did the right thing" there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1624674&group_id=5470 From noreply at sourceforge.net Thu Mar 8 23:18:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 14:18:49 -0800 Subject: [ python-Bugs-1676121 ] Problem linking to readline lib on x86(64) Solaris Message-ID: Bugs item #1676121, was opened at 2007-03-07 23:07 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676121&group_id=5470 Please note that this 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 Private: No Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Problem linking to readline lib on x86(64) Solaris Initial Comment: Configuring with ./configure --with-gcc="gcc -m64 -L/usr/sfw/lib/64 -R/usr/sfw/lib/64" where 64bit libreadline is found in /usr/sfw/lib/64, configure script fails to realize that readline lib is present. I was able to fix the problem by editing config script manually as follows: $ diff configure~ configure 20744c20744 < if test "$ac_cv_have_readline_readline" = no --- > if test "$ac_cv_lib_readline_readline" = no 20747c20747 < echo "$as_me:$LINENO: checking for readline in -ltermcap" >&5 --- > echo "$as_me:$LINENO: checking for readline in -lreadline -ltermcap" >&5 20753c20753 < LIBS="-ltermcap $LIBS" --- > LIBS="-lreadline -ltermcap $LIBS" A proper fix would be to change configure.in, but I don't know enough about autoconf to submit a proper patch. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-08 23:18 Message: Logged In: YES user_id=21627 Originator: NO The right solution in this case is to edit Modules/Setup ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676121&group_id=5470 From noreply at sourceforge.net Thu Mar 8 23:25:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 14:25:46 -0800 Subject: [ python-Bugs-1676121 ] Problem linking to readline lib on x86(64) Solaris Message-ID: Bugs item #1676121, was opened at 2007-03-07 17:07 Message generated for change (Comment added) made by belopolsky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676121&group_id=5470 Please note that this 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 Private: No Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Problem linking to readline lib on x86(64) Solaris Initial Comment: Configuring with ./configure --with-gcc="gcc -m64 -L/usr/sfw/lib/64 -R/usr/sfw/lib/64" where 64bit libreadline is found in /usr/sfw/lib/64, configure script fails to realize that readline lib is present. I was able to fix the problem by editing config script manually as follows: $ diff configure~ configure 20744c20744 < if test "$ac_cv_have_readline_readline" = no --- > if test "$ac_cv_lib_readline_readline" = no 20747c20747 < echo "$as_me:$LINENO: checking for readline in -ltermcap" >&5 --- > echo "$as_me:$LINENO: checking for readline in -lreadline -ltermcap" >&5 20753c20753 < LIBS="-ltermcap $LIBS" --- > LIBS="-lreadline -ltermcap $LIBS" A proper fix would be to change configure.in, but I don't know enough about autoconf to submit a proper patch. ---------------------------------------------------------------------- >Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-08 17:25 Message: Logged In: YES user_id=835142 Originator: YES Can you explain how to edit Module/Setup to solve this problem? Note that the problem that I see comes before modules are built. In fact it comes even before make. In any case, I think the check for $ac_cv_have_readline_readline" = no instead of "$ac_cv_lib_readline_readline" = no looks like a typo in configure.in. And looking for readline in libtermcap does not look like sound logic either. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-08 17:18 Message: Logged In: YES user_id=21627 Originator: NO The right solution in this case is to edit Modules/Setup ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676121&group_id=5470 From noreply at sourceforge.net Fri Mar 9 01:04:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 16:04:20 -0800 Subject: [ python-Bugs-1666807 ] Incorrect file path reported by inspect.getabsfile() Message-ID: Bugs item #1666807, was opened at 2007-02-23 02:08 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666807&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Fernando P?rez (fer_perez) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect file path reported by inspect.getabsfile() Initial Comment: The following code demonstrates the problem succinctly: ### import inspect,sys print 'Version info:',sys.version_info print f1 = inspect.getabsfile(inspect) f2 = inspect.getabsfile(inspect.iscode) print 'File for `inspect` :',f1 print 'File for `inspect.iscode`:',f2 print 'Do these match?',f1==f2 if f1==f2: print 'OK' else: print 'BUG - this is a bug in this version of Python' ### EOF Running this on my system (Linux, Ubuntu Edgy) with 2.3, 2.4 and 2.5 produces: tlon[bin]> ./python2.3 ~/code/python/inspect_bug.py Version info: (2, 3, 6, 'final', 0) File for `inspect` : /home/fperez/tmp/local/lib/python2.3/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/lib/python2.3/inspect.py Do these match? True OK tlon[bin]> python2.4 ~/code/python/inspect_bug.py Version info: (2, 4, 4, 'candidate', 1) File for `inspect` : /usr/lib/python2.4/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/bin/inspect.py Do these match? False BUG - this is a bug in this version of Python tlon[bin]> python2.5 ~/code/python/inspect_bug.py Version info: (2, 5, 0, 'final', 0) File for `inspect` : /usr/lib/python2.5/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/bin/inspect.py Do these match? False BUG - this is a bug in this version of Python ### The problem arises in the fact that inspect relies, for functions (at least), on the func_code.co_filename attribute to contain a complete path. This changed between 2.3 and 2.4, but the inspect module was never updated. This code: ### import inspect,sys print 'Python version info:',sys.version_info print 'File info for `inspect.iscode function`:' print ' ',inspect.iscode.func_code.co_filename print ### EOF shows the problem: tlon[bin]> ./python2.3 ~/code/python/inspect_bug_details.py Python version info: (2, 3, 6, 'final', 0) File info for `inspect.iscode function`: /home/fperez/tmp/local//lib/python2.3/inspect.py tlon[bin]> python2.5 ~/code/python/inspect_bug_details.py Python version info: (2, 5, 0, 'final', 0) File info for `inspect.iscode function`: inspect.py ### (2.4 has the same issue). Basically, if the func_code.co_filename attribute now stores only the final filename without the full path, then the logic in the inspect module needs to be changed to accomodate this so that correct paths are reported to the user like they were in the 2.3 days. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-08 19:04 Message: Logged In: YES user_id=1344176 Originator: NO I haven't been able to reproduce this with Python 2.3.5, 2.4.4, 2.5.0 or SVN HEAD (all hand-built on Slackware Linux). What options are you providing to ./configure? ---------------------------------------------------------------------- Comment By: Fernando P?rez (fer_perez) Date: 2007-02-24 02:22 Message: Logged In: YES user_id=395388 Originator: YES No, in my case the original tests with 2.4 and 2.5 were done with the Ubuntu-provided (Edgy) versions, unmodified from their apt-get install state. But your comments are interesting. I just rebuilt 2.5 by hand from source on the same system, and this is what I get: tlon[bin]> ./python2.5 ~/code/python/inspect_bug.py Version info: (2, 5, 0, 'final', 0) File for `inspect` : /home/fperez/tmp/local/lib/python2.5/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/lib/python2.5/inspect.py Do these match? True OK tlon[bin]> ./python2.5 ~/code/python/inspect_bug_details.py Python version info: (2, 5, 0, 'final', 0) File info for `inspect.iscode function`: /home/fperez/tmp/local//lib/python2.5/inspect.py So basically it seems that there's a difference in the value of the func_code.co_filename object attribute depending on how the build was made. At this point I'm not really sure if this should be considered a Python bug or an Ubuntu one... Perhaps the Python build process can be made more robust, I simply don't know. But the end-user behavior /is/ a bug, so it would be nice to know how to fix it. Thanks for your info! ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-02-24 01:51 Message: Logged In: YES user_id=1727609 Originator: NO Hi, On a custom-compiled Python 2.5 on Ubuntu Dapper, I get: yello at outback:~/code/python $ python bug_1666807.py Version info: (2, 5, 0, 'final', 0) File for `inspect` : /usr/local/lib/python2.5/inspect.py File for `inspect.iscode`: /usr/local/lib/python2.5/inspect.py Do these match? True OK On a system python 2.4.3 on another Ubuntu Dapper system, I get: yello at adelaide:~/code/python $ python bug_1666807.py Version info: (2, 4, 3, 'final', 0) File for `inspect` : /usr/lib/python2.4/inspect.py File for `inspect.iscode`: /usr/lib/python2.4/inspect.py Do these match? True OK However, I can recreate this issue on another system (CentOS4) with a custom install where a symlink is involved. I get: [prompt goes here python]$ python bug_1666807.py Version info: (2, 2, 3, 'final', 0) File for `inspect` : /xxx/yyyy/PythonHome/lib/python2.2/inspect.py File for `inspect.iscode`: /xxx/yyyy/Python-2.2/lib/python2.2/inspect.py Do these match? 0 BUG - this is a bug in this version of Python Is a symlink involved on the system where you saw this behaviour? ---------------------------------------------------------------------- Comment By: Fernando P?rez (fer_perez) Date: 2007-02-23 11:57 Message: Logged In: YES user_id=395388 Originator: YES Note: a colleague just tested this under Python 2.4 for Mac OSX (intel), and the problem didn't show up there: import inspect print 'File for `code` :',inspect.getabsfile(code) print 'File for `code.interact`:',inspect.getabsfile(code.interact) Gives: File for `code` : /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/code.py File for `code.interact`: /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/code.py My original tests were done under Ubuntu Edgy Eft, using the Ubuntu-provided 2.4 and 2.5, and a hand-compiled 2.3.6 from the source download at python.org. HTH, f ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666807&group_id=5470 From noreply at sourceforge.net Fri Mar 9 01:21:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 16:21:06 -0800 Subject: [ python-Bugs-1625381 ] re module documentation on search/match is unclear Message-ID: Bugs item #1625381, was opened at 2006-12-31 11:42 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1625381&group_id=5470 Please note that this 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 Private: No Submitted By: Richard Boulton (richardb) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: re module documentation on search/match is unclear Initial Comment: Section 4.2.2 ("Matching vs Searching") of the Python Library Reference covers the match and search methods of regular expression objects. However, it doesn't begin by describing the difference between these methods. Each time I try to remember which way round match and search are, it takes several minutes of checking the documentation to work out which is which. I suggest that the first paragraph of the section is replaced with the following text (in two paragraphs), to make the distinction between the methods clearer: "Python offers two different primitive operations based on regular expressions: match and search. match() checks for a match at the beginning of the search string, whereas search() checks for a match anywhere in the string. If you want something equivalent to Perl's semantics, the search operation is what you're looking for. See the search() function and corresponding method of compiled regular expression objects." ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-08 19:21 Message: Logged In: YES user_id=1344176 Originator: NO +1 on the general idea, though I'd change your "match() checks for a match at the beginning..." to "match() checks for a match starting at the beginning...". I'd also like to drop the reference to Perl entirely; saying that I should look to search() for Perl's semantics makes it sound like match() doesn't support PCREs. Fred, any thoughts? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1625381&group_id=5470 From noreply at sourceforge.net Fri Mar 9 02:02:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 17:02:46 -0800 Subject: [ python-Feature Requests-1625576 ] add ability to specify name to os.fdopen Message-ID: Feature Requests item #1625576, was opened at 2007-01-01 02:19 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1625576&group_id=5470 Please note that this 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 Private: No Submitted By: Mark Diekhans (diekhans) Assigned to: Nobody/Anonymous (nobody) Summary: add ability to specify name to os.fdopen Initial Comment: Please add an optional argument to os.fdopen() to specify the name field in the resulting file object. This would allow for a more useful name than: '...> ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-08 20:02 Message: Logged In: YES user_id=1344176 Originator: NO Changing this to a "feature request", since it's certainly not a bug. I can see both sides of this; on the one hand, isn't the most descriptive string and doesn't give you an idea where it came from; on the other hand, you lose the distinction between files opened by filename and those by file descriptor. If the purpose is to distinguish between fdopen()'d files, what if fdopen() was changed so that the filename matched , where \d+ is the file descriptor passed to fdopen()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1625576&group_id=5470 From noreply at sourceforge.net Fri Mar 9 03:00:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 18:00:53 -0800 Subject: [ python-Bugs-1666807 ] Incorrect file path reported by inspect.getabsfile() Message-ID: Bugs item #1666807, was opened at 2007-02-23 07:08 Message generated for change (Comment added) made by fer_perez You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666807&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Fernando P?rez (fer_perez) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect file path reported by inspect.getabsfile() Initial Comment: The following code demonstrates the problem succinctly: ### import inspect,sys print 'Version info:',sys.version_info print f1 = inspect.getabsfile(inspect) f2 = inspect.getabsfile(inspect.iscode) print 'File for `inspect` :',f1 print 'File for `inspect.iscode`:',f2 print 'Do these match?',f1==f2 if f1==f2: print 'OK' else: print 'BUG - this is a bug in this version of Python' ### EOF Running this on my system (Linux, Ubuntu Edgy) with 2.3, 2.4 and 2.5 produces: tlon[bin]> ./python2.3 ~/code/python/inspect_bug.py Version info: (2, 3, 6, 'final', 0) File for `inspect` : /home/fperez/tmp/local/lib/python2.3/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/lib/python2.3/inspect.py Do these match? True OK tlon[bin]> python2.4 ~/code/python/inspect_bug.py Version info: (2, 4, 4, 'candidate', 1) File for `inspect` : /usr/lib/python2.4/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/bin/inspect.py Do these match? False BUG - this is a bug in this version of Python tlon[bin]> python2.5 ~/code/python/inspect_bug.py Version info: (2, 5, 0, 'final', 0) File for `inspect` : /usr/lib/python2.5/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/bin/inspect.py Do these match? False BUG - this is a bug in this version of Python ### The problem arises in the fact that inspect relies, for functions (at least), on the func_code.co_filename attribute to contain a complete path. This changed between 2.3 and 2.4, but the inspect module was never updated. This code: ### import inspect,sys print 'Python version info:',sys.version_info print 'File info for `inspect.iscode function`:' print ' ',inspect.iscode.func_code.co_filename print ### EOF shows the problem: tlon[bin]> ./python2.3 ~/code/python/inspect_bug_details.py Python version info: (2, 3, 6, 'final', 0) File info for `inspect.iscode function`: /home/fperez/tmp/local//lib/python2.3/inspect.py tlon[bin]> python2.5 ~/code/python/inspect_bug_details.py Python version info: (2, 5, 0, 'final', 0) File info for `inspect.iscode function`: inspect.py ### (2.4 has the same issue). Basically, if the func_code.co_filename attribute now stores only the final filename without the full path, then the logic in the inspect module needs to be changed to accomodate this so that correct paths are reported to the user like they were in the 2.3 days. ---------------------------------------------------------------------- >Comment By: Fernando P?rez (fer_perez) Date: 2007-03-09 02:00 Message: Logged In: YES user_id=395388 Originator: YES As I mentioned, on hand-built Pythons I don't get the bug at all. So it may be a problem with how Ubuntu builds its Python, since I can reproduce the problem with both 2.4 and 2.5, but only with the default ones provided by Ubuntu Edgy. I don't know enough about their packaging system to know how to retrieve build info. There may be something odd in their build, but it would be nice if this simply couldn't happen at all. If anyone knows how to retrieve the relevant info from an ubuntu build, I'll be happy to try and provide it. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-09 00:04 Message: Logged In: YES user_id=1344176 Originator: NO I haven't been able to reproduce this with Python 2.3.5, 2.4.4, 2.5.0 or SVN HEAD (all hand-built on Slackware Linux). What options are you providing to ./configure? ---------------------------------------------------------------------- Comment By: Fernando P?rez (fer_perez) Date: 2007-02-24 07:22 Message: Logged In: YES user_id=395388 Originator: YES No, in my case the original tests with 2.4 and 2.5 were done with the Ubuntu-provided (Edgy) versions, unmodified from their apt-get install state. But your comments are interesting. I just rebuilt 2.5 by hand from source on the same system, and this is what I get: tlon[bin]> ./python2.5 ~/code/python/inspect_bug.py Version info: (2, 5, 0, 'final', 0) File for `inspect` : /home/fperez/tmp/local/lib/python2.5/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/lib/python2.5/inspect.py Do these match? True OK tlon[bin]> ./python2.5 ~/code/python/inspect_bug_details.py Python version info: (2, 5, 0, 'final', 0) File info for `inspect.iscode function`: /home/fperez/tmp/local//lib/python2.5/inspect.py So basically it seems that there's a difference in the value of the func_code.co_filename object attribute depending on how the build was made. At this point I'm not really sure if this should be considered a Python bug or an Ubuntu one... Perhaps the Python build process can be made more robust, I simply don't know. But the end-user behavior /is/ a bug, so it would be nice to know how to fix it. Thanks for your info! ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-02-24 06:51 Message: Logged In: YES user_id=1727609 Originator: NO Hi, On a custom-compiled Python 2.5 on Ubuntu Dapper, I get: yello at outback:~/code/python $ python bug_1666807.py Version info: (2, 5, 0, 'final', 0) File for `inspect` : /usr/local/lib/python2.5/inspect.py File for `inspect.iscode`: /usr/local/lib/python2.5/inspect.py Do these match? True OK On a system python 2.4.3 on another Ubuntu Dapper system, I get: yello at adelaide:~/code/python $ python bug_1666807.py Version info: (2, 4, 3, 'final', 0) File for `inspect` : /usr/lib/python2.4/inspect.py File for `inspect.iscode`: /usr/lib/python2.4/inspect.py Do these match? True OK However, I can recreate this issue on another system (CentOS4) with a custom install where a symlink is involved. I get: [prompt goes here python]$ python bug_1666807.py Version info: (2, 2, 3, 'final', 0) File for `inspect` : /xxx/yyyy/PythonHome/lib/python2.2/inspect.py File for `inspect.iscode`: /xxx/yyyy/Python-2.2/lib/python2.2/inspect.py Do these match? 0 BUG - this is a bug in this version of Python Is a symlink involved on the system where you saw this behaviour? ---------------------------------------------------------------------- Comment By: Fernando P?rez (fer_perez) Date: 2007-02-23 16:57 Message: Logged In: YES user_id=395388 Originator: YES Note: a colleague just tested this under Python 2.4 for Mac OSX (intel), and the problem didn't show up there: import inspect print 'File for `code` :',inspect.getabsfile(code) print 'File for `code.interact`:',inspect.getabsfile(code.interact) Gives: File for `code` : /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/code.py File for `code.interact`: /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/code.py My original tests were done under Ubuntu Edgy Eft, using the Ubuntu-provided 2.4 and 2.5, and a hand-compiled 2.3.6 from the source download at python.org. HTH, f ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666807&group_id=5470 From noreply at sourceforge.net Fri Mar 9 05:58:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 20:58:28 -0800 Subject: [ python-Feature Requests-1625576 ] add ability to specify name to os.fdopen Message-ID: Feature Requests item #1625576, was opened at 2007-01-01 07:19 Message generated for change (Comment added) made by diekhans You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1625576&group_id=5470 Please note that this 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 Private: No Submitted By: Mark Diekhans (diekhans) Assigned to: Nobody/Anonymous (nobody) Summary: add ability to specify name to os.fdopen Initial Comment: Please add an optional argument to os.fdopen() to specify the name field in the resulting file object. This would allow for a more useful name than: '...> ---------------------------------------------------------------------- >Comment By: Mark Diekhans (diekhans) Date: 2007-03-09 04:58 Message: Logged In: YES user_id=66101 Originator: YES thanks collin; that was suppose to be a feature request! doesn't really help. For end user message, a file name is very use, the fact that it is opened by fdopen is not. If one is debugging a program and knows the file name, one can usually figure out where it is opened, the file number, or for that matter that fdopen was used is less useful. The particular case that prompted this request was the need use os.open to get non-blocking mode and then pass the result to fdopen. However this now loses the file name, replacing it with something not useful. thanks. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-09 01:02 Message: Logged In: YES user_id=1344176 Originator: NO Changing this to a "feature request", since it's certainly not a bug. I can see both sides of this; on the one hand, isn't the most descriptive string and doesn't give you an idea where it came from; on the other hand, you lose the distinction between files opened by filename and those by file descriptor. If the purpose is to distinguish between fdopen()'d files, what if fdopen() was changed so that the filename matched , where \d+ is the file descriptor passed to fdopen()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1625576&group_id=5470 From noreply at sourceforge.net Fri Mar 9 06:00:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 21:00:30 -0800 Subject: [ python-Feature Requests-1625576 ] add ability to specify name to os.fdopen Message-ID: Feature Requests item #1625576, was opened at 2007-01-01 07:19 Message generated for change (Comment added) made by diekhans You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1625576&group_id=5470 Please note that this 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 Private: No Submitted By: Mark Diekhans (diekhans) Assigned to: Nobody/Anonymous (nobody) Summary: add ability to specify name to os.fdopen Initial Comment: Please add an optional argument to os.fdopen() to specify the name field in the resulting file object. This would allow for a more useful name than: '...> ---------------------------------------------------------------------- >Comment By: Mark Diekhans (diekhans) Date: 2007-03-09 05:00 Message: Logged In: YES user_id=66101 Originator: YES p.s. I will happy implement the change. ---------------------------------------------------------------------- Comment By: Mark Diekhans (diekhans) Date: 2007-03-09 04:58 Message: Logged In: YES user_id=66101 Originator: YES thanks collin; that was suppose to be a feature request! doesn't really help. For end user message, a file name is very use, the fact that it is opened by fdopen is not. If one is debugging a program and knows the file name, one can usually figure out where it is opened, the file number, or for that matter that fdopen was used is less useful. The particular case that prompted this request was the need use os.open to get non-blocking mode and then pass the result to fdopen. However this now loses the file name, replacing it with something not useful. thanks. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-09 01:02 Message: Logged In: YES user_id=1344176 Originator: NO Changing this to a "feature request", since it's certainly not a bug. I can see both sides of this; on the one hand, isn't the most descriptive string and doesn't give you an idea where it came from; on the other hand, you lose the distinction between files opened by filename and those by file descriptor. If the purpose is to distinguish between fdopen()'d files, what if fdopen() was changed so that the filename matched , where \d+ is the file descriptor passed to fdopen()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1625576&group_id=5470 From noreply at sourceforge.net Fri Mar 9 06:21:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 21:21:37 -0800 Subject: [ python-Bugs-1676971 ] Complex OverflowError has a typo Message-ID: Bugs item #1676971, was opened at 2007-03-09 05: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=1676971&group_id=5470 Please note that this 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 Private: No Submitted By: John Dong (jdong2002) Assigned to: Nobody/Anonymous (nobody) Summary: Complex OverflowError has a typo Initial Comment: >>> (1-24j)**34324324 Traceback (most recent call last): File "", line 1, in OverflowError: complex exponentiaion Exponentiation is spelled incorrectly. This has been reproduced on Python 2.4 and 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676971&group_id=5470 From noreply at sourceforge.net Fri Mar 9 07:02:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 22:02:05 -0800 Subject: [ python-Bugs-1676971 ] Complex OverflowError has a typo Message-ID: Bugs item #1676971, was opened at 2007-03-08 21:21 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676971&group_id=5470 Please note that this 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.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: John Dong (jdong2002) >Assigned to: Neal Norwitz (nnorwitz) Summary: Complex OverflowError has a typo Initial Comment: >>> (1-24j)**34324324 Traceback (most recent call last): File "", line 1, in OverflowError: complex exponentiaion Exponentiation is spelled incorrectly. This has been reproduced on Python 2.4 and 2.5. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-08 22:02 Message: Logged In: YES user_id=33168 Originator: NO Thanks for the report! Committed revision 54237. Committed revision 54238. (2.5) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1676971&group_id=5470 From noreply at sourceforge.net Fri Mar 9 08:08:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 23:08:08 -0800 Subject: [ python-Bugs-1675511 ] Python still uses broken -xcode option on Solaris/x86 Message-ID: Bugs item #1675511, was opened at 2007-03-07 08:54 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None >Priority: 5 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: Python still uses broken -xcode option on Solaris/x86 Initial Comment: Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting a new bug against 2.5 in the hopes that someone will read it... text updated with minor corrections. Python 2.5, Solaris x86 10 Update 3, Sun Studio 11 xcode=pic32 option is not supported on Solaris x86 Sun C . Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when any compiler other than gcc is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates an error that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-09 08:08 Message: Logged In: YES user_id=21627 Originator: NO One problem is that the proposed change is incorrect. According to the C User's Guide of Sun Studio 11 (document 819-3688-10), -KPIC is an obsolete option on SPARC, and should be replaced with -xcode=pic32 (section A.1.15). So I think a patch should be architecture-specific. Can somebody come up with a patch that does that? ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-07 09:34 Message: Logged In: YES user_id=673069 Originator: NO Perhaps I was unclear in bug #1561333 that this resulted in only a warning. Actually the build will fail because of the incorrect flag. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 From noreply at sourceforge.net Fri Mar 9 08:10:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 23:10:12 -0800 Subject: [ python-Bugs-1675026 ] Redirect cause invalid descriptor error Message-ID: Bugs item #1675026, was opened at 2007-03-06 16:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675026&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jean-Marc Ranger (jmranger) Assigned to: Nobody/Anonymous (nobody) Summary: Redirect cause invalid descriptor error Initial Comment: Test setup: - Windows 2000 (french) - Python 2.5 (reproducible with 2.4.2 and 2.4.4) One python source file, test.py: --- import os print os.system("echo test") --- Console output: --- C:\test>test.py test 0 C:\test>test.py > test.log Descripteur non valide C:\test>type test.log 0 C:\test>c:\python25\python test.py test 0 C:\test>c:\python25\python test.py > test.log C:\test>type test.log test 0 C:\test> --- The "Descripteur non valide" error would translate to "invalid file descriptor". I would expect the 2nd call to perform the same way the 4th does. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-09 08:10 Message: Logged In: YES user_id=21627 Originator: NO Do you have an explanation for the cause of the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675026&group_id=5470 From noreply at sourceforge.net Fri Mar 9 09:06:24 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 00:06:24 -0800 Subject: [ python-Bugs-1675511 ] Python still uses broken -xcode option on Solaris/x86 Message-ID: Bugs item #1675511, was opened at 2007-03-07 02:54 Message generated for change (Comment added) made by cgaspar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None >Priority: 7 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: Python still uses broken -xcode option on Solaris/x86 Initial Comment: Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting a new bug against 2.5 in the hopes that someone will read it... text updated with minor corrections. Python 2.5, Solaris x86 10 Update 3, Sun Studio 11 xcode=pic32 option is not supported on Solaris x86 Sun C . Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when any compiler other than gcc is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates an error that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. ---------------------------------------------------------------------- >Comment By: Carson Gaspar (cgaspar) Date: 2007-03-09 03:06 Message: Logged In: YES user_id=664506 Originator: YES While the doc labels the -KPIC option as "obsolete" for SPARC, it works fine. Perhaps Studio 12 will break it, but all current compilers understand it fine. If you want to be pedantically correct and use -xcode=pic32, you don't need an architecture test, you need to actually _try_ the option, as older SPARC compilers won't accept it either. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-09 02:08 Message: Logged In: YES user_id=21627 Originator: NO One problem is that the proposed change is incorrect. According to the C User's Guide of Sun Studio 11 (document 819-3688-10), -KPIC is an obsolete option on SPARC, and should be replaced with -xcode=pic32 (section A.1.15). So I think a patch should be architecture-specific. Can somebody come up with a patch that does that? ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-07 03:34 Message: Logged In: YES user_id=673069 Originator: NO Perhaps I was unclear in bug #1561333 that this resulted in only a warning. Actually the build will fail because of the incorrect flag. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 From noreply at sourceforge.net Fri Mar 9 09:25:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 00:25:57 -0800 Subject: [ python-Bugs-1675026 ] Redirect cause invalid descriptor error Message-ID: Bugs item #1675026, was opened at 2007-03-06 16:58 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675026&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jean-Marc Ranger (jmranger) Assigned to: Nobody/Anonymous (nobody) Summary: Redirect cause invalid descriptor error Initial Comment: Test setup: - Windows 2000 (french) - Python 2.5 (reproducible with 2.4.2 and 2.4.4) One python source file, test.py: --- import os print os.system("echo test") --- Console output: --- C:\test>test.py test 0 C:\test>test.py > test.log Descripteur non valide C:\test>type test.log 0 C:\test>c:\python25\python test.py test 0 C:\test>c:\python25\python test.py > test.log C:\test>type test.log test 0 C:\test> --- The "Descripteur non valide" error would translate to "invalid file descriptor". I would expect the 2nd call to perform the same way the 4th does. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2007-03-09 09:25 Message: Logged In: YES user_id=11105 Originator: NO This is a windows bug. See the Microsoft Knowledge Base: http://support.microsoft.com/kb/321788 This entry talks about Windows 2000. I do not use Windows 2000 anymore, so I cannot test on this version. I have created the registry entry that is mentioned on WinXP SP2 (German version, fwiw), and it does fix the problem. I had to open a new command window after changing the registry. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-09 08:10 Message: Logged In: YES user_id=21627 Originator: NO Do you have an explanation for the cause of the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675026&group_id=5470 From noreply at sourceforge.net Fri Mar 9 09:56:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 00:56:06 -0800 Subject: [ python-Bugs-1675511 ] Python still uses broken -xcode option on Solaris/x86 Message-ID: Bugs item #1675511, was opened at 2007-03-07 08:54 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None >Priority: 5 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: Python still uses broken -xcode option on Solaris/x86 Initial Comment: Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting a new bug against 2.5 in the hopes that someone will read it... text updated with minor corrections. Python 2.5, Solaris x86 10 Update 3, Sun Studio 11 xcode=pic32 option is not supported on Solaris x86 Sun C . Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when any compiler other than gcc is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates an error that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-09 09:56 Message: Logged In: YES user_id=21627 Originator: NO I don't want to make a change now, just to have to deal with a bug report two years from now which then will sit again in this tracker for years again. I'm fine with documenting that older SunPRO compilers are not supported; -xcode has been supported atleast since Sun Forte 6 (released in 2000); earlier products had reached their end-of-life long ago. So either this gets fixed properly now, or not at all. ---------------------------------------------------------------------- Comment By: Carson Gaspar (cgaspar) Date: 2007-03-09 09:06 Message: Logged In: YES user_id=664506 Originator: YES While the doc labels the -KPIC option as "obsolete" for SPARC, it works fine. Perhaps Studio 12 will break it, but all current compilers understand it fine. If you want to be pedantically correct and use -xcode=pic32, you don't need an architecture test, you need to actually _try_ the option, as older SPARC compilers won't accept it either. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-09 08:08 Message: Logged In: YES user_id=21627 Originator: NO One problem is that the proposed change is incorrect. According to the C User's Guide of Sun Studio 11 (document 819-3688-10), -KPIC is an obsolete option on SPARC, and should be replaced with -xcode=pic32 (section A.1.15). So I think a patch should be architecture-specific. Can somebody come up with a patch that does that? ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-07 09:34 Message: Logged In: YES user_id=673069 Originator: NO Perhaps I was unclear in bug #1561333 that this resulted in only a warning. Actually the build will fail because of the incorrect flag. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 From noreply at sourceforge.net Fri Mar 9 11:16:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 02:16:09 -0800 Subject: [ python-Bugs-1675026 ] Redirect cause invalid descriptor error Message-ID: Bugs item #1675026, was opened at 2007-03-06 15:58 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675026&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jean-Marc Ranger (jmranger) Assigned to: Nobody/Anonymous (nobody) Summary: Redirect cause invalid descriptor error Initial Comment: Test setup: - Windows 2000 (french) - Python 2.5 (reproducible with 2.4.2 and 2.4.4) One python source file, test.py: --- import os print os.system("echo test") --- Console output: --- C:\test>test.py test 0 C:\test>test.py > test.log Descripteur non valide C:\test>type test.log 0 C:\test>c:\python25\python test.py test 0 C:\test>c:\python25\python test.py > test.log C:\test>type test.log test 0 C:\test> --- The "Descripteur non valide" error would translate to "invalid file descriptor". I would expect the 2nd call to perform the same way the 4th does. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-09 10:16 Message: Logged In: YES user_id=849994 Originator: NO So we can do nothing about the bug, but we should definitely document that somewhere and link to the Knowledge Base. What would be the correct location? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2007-03-09 08:25 Message: Logged In: YES user_id=11105 Originator: NO This is a windows bug. See the Microsoft Knowledge Base: http://support.microsoft.com/kb/321788 This entry talks about Windows 2000. I do not use Windows 2000 anymore, so I cannot test on this version. I have created the registry entry that is mentioned on WinXP SP2 (German version, fwiw), and it does fix the problem. I had to open a new command window after changing the registry. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-09 07:10 Message: Logged In: YES user_id=21627 Originator: NO Do you have an explanation for the cause of the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675026&group_id=5470 From noreply at sourceforge.net Fri Mar 9 17:33:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 08:33:06 -0800 Subject: [ python-Feature Requests-1665292 ] Datetime enhancements Message-ID: Feature Requests item #1665292, was opened at 2007-02-21 15:55 Message generated for change (Comment added) made by jcrocholl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1665292&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Nobody/Anonymous (nobody) Summary: Datetime enhancements Initial Comment: I'm proposing some small enhancements to the datetime module: Add a totimestamp() method to datetime.datetime that returns the seconds since 1/1/1970 00:00:00. The datetime class has already a fromtimestamp() factory but is missing a totimestamp() method. Add a __int__() and __float__() method to datetime.timedelta which return the seconds (seconds + 86400 * days) as int and seconds + miliseconds as float. It would save some typing if somebody needs an integer representation of a timedelta object :] The datetime module is implemented in C. I've never written a Python C extension so I can't help with a patch. Thx ---------------------------------------------------------------------- Comment By: Johann C. Rocholl (jcrocholl) Date: 2007-03-09 17:33 Message: Logged In: YES user_id=656137 Originator: NO The patch confuses microseconds with milliseconds. The divisor in delta_float should be 1000000.0, not 1000.0. The result of the last test should be 86401.000001, not 86401.001. ---------------------------------------------------------------------- Comment By: Christian Heimes (tiran) Date: 2007-02-21 17:16 Message: Logged In: YES user_id=560817 Originator: YES File Added: timedelta.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1665292&group_id=5470 From noreply at sourceforge.net Fri Mar 9 17:53:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 08:53:26 -0800 Subject: [ python-Bugs-805194 ] Inappropriate error received using socket timeout Message-ID: Bugs item #805194, was opened at 2003-09-12 12:56 Message generated for change (Comment added) made by dmeranda You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805194&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Popov (evgeni_popov) Assigned to: Nobody/Anonymous (nobody) Summary: Inappropriate error received using socket timeout Initial Comment: When using the timeout option with a socket object (python 2.3), I don't have the same behaviour under Windows than under Linux / Mac. Specifically, if trying to connect to an unopened port of the localhost, I get a timeout exception on Windows (tested under W2K Server), whereas I get a "111 - Connection Refused" exception on Linux and "22 - Invalid Argument" on Mac (OS X). Even if the error message under Mac is not really appropriate (someone said to me he got the right 'Connection Refused' on his MAC), I think that the behaviour under Linux and Mac is the right one, in that it sends (quickly) an error message and not timeouting. Note that when using blocking socket the behaviour is ok under all platforms: they each return back quickly a "Connection refused" error message (err codes are different depending on the platform (61=Mac, 111=Linux, 10061=Windows)). FYI, I don't use firewall or similar prog on my windows box (but that should not matter, because it does work in blocking mode, so that can't be a firewall problem). I heard that the timeout option was implemented based on Timothy O'Malley timeoutsocket.py. Then, maybe the pb can come from the usage of select in the connection function: select is not asked to get back exceptions in the returned triple, whereas I think some errors can be returned back through this mean under Windows (according to Tip 25 of Jon C. Snader book's "Effective TCP/IP Programming"). So, by not checking the returned exceptions, we would miss the "connection refused" error and get instead the timeout error... ---------------------------------------------------------------------- Comment By: Deron Meranda (dmeranda) Date: 2007-03-09 11:53 Message: Logged In: YES user_id=847188 Originator: NO This is also a problem under HP-UX 11.0 with Python 2.5 The socket connect_ex() will return errno 22 EINVAL instead of the more appropriate 239 ECONNREFUSED when connecting to a non-listening socket ... but only if a socket timeout is being used. A system call trace reveils a little more what is going on. For the python code import socket s = socket.socket( socket.AF_INET, socket.SOCK_STREAM ) s.settimeout(15.0) res = s.connect_ex( ('127.0.0.1', 8099) ) # An unused port number the system call sequence is as follows: Calling socket.socket() socket(AF_INET, SOCK_STREAM, 0) = 3 Calling s.settimeout(15.0) fcntl(3, F_GETFL, 0) = 2 fcntl(3, F_SETFL, 65538) = 0 Calling s.connect_ex(...) connect(3, 0x400b43f0, 16) = -1 -> ERR#245 EINPROGRESS poll(0x7cff1914, 1, 15000) = 1 connect(3, 0x400b43f0, 16) = -1 -> ERR#22 EINVAL If the call to settimeout is removed, then an ERR#239 ECONNREFUSED is returned by the first connect() and no subsequent poll+connect is attempted. With the timeout set, note that the poll() returns immediately no timeout actually occurs. Note that tracing the same code under Linux shows the exact same set of system calls, but that the second connect() call returns ECONNREFUSED instead. So this appears to be a specific behavior of HP-UX (and perhaps other Unixes). Excerpted from the HP man pages for connect(2): [EINVAL] The socket has already been shut down or has a listen() active on it; addrlen is a bad value; an attempt was made to connect() an AF_UNIX socket to an NFS- mounted (remote) name; the X.121 address length is zero, negative, or greater than 15 digits. For datagram sockets, if addrlen is a bad value, the peer address is no longer maintained by the system. [ECONNREFUSED] The attempt to connect was forcefully rejected. [EINPROGRESS] Nonblocking I/O is enabled using O_NONBLOCK, O_NDELAY, or FIOSNBIO, and the connection cannot be completed immediately. This is not a failure. Make the connect() call again a few seconds later. Alternatively, wait for completion by calling select() and selecting for write. ---------------------------------------------------------------------- Comment By: Troels Walsted Hansen (troels) Date: 2004-06-02 04:51 Message: Logged In: YES user_id=32863 The Windows part of this bug is a duplicate of bug #777597. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805194&group_id=5470 From noreply at sourceforge.net Fri Mar 9 18:52:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 09:52:39 -0800 Subject: [ python-Bugs-1629566 ] documentation of email.utils.parsedate is confusing Message-ID: Bugs item #1629566, was opened at 2007-01-06 16:37 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1629566&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nicholas Riley (nriley) >Assigned to: Collin Winter (collinwinter) Summary: documentation of email.utils.parsedate is confusing Initial Comment: This sentence in the documentation for email.utils.parsedate confused me: "Note that fields 6, 7, and 8 of the result tuple are not usable." These indices are zero-based, so it's actually fields 7, 8 and 9 that they are talking about (in normal English). Either this should be changed to 7-9 or be re-expressed in a way that makes it clear it's zero-based, for example by using Python indexing notation. Thanks. ---------------------------------------------------------------------- Comment By: Mark Roberts (mark-roberts) Date: 2007-01-19 20:16 Message: Logged In: YES user_id=1591633 Originator: NO Link to document in question: http://www.python.org/doc/lib/module-email.utils.html www.python.org/sf/1639973 for doc patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1629566&group_id=5470 From noreply at sourceforge.net Fri Mar 9 19:13:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 10:13:57 -0800 Subject: [ python-Bugs-1629566 ] documentation of email.utils.parsedate is confusing Message-ID: Bugs item #1629566, was opened at 2007-01-06 16:37 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1629566&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nicholas Riley (nriley) Assigned to: Collin Winter (collinwinter) Summary: documentation of email.utils.parsedate is confusing Initial Comment: This sentence in the documentation for email.utils.parsedate confused me: "Note that fields 6, 7, and 8 of the result tuple are not usable." These indices are zero-based, so it's actually fields 7, 8 and 9 that they are talking about (in normal English). Either this should be changed to 7-9 or be re-expressed in a way that makes it clear it's zero-based, for example by using Python indexing notation. Thanks. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-09 13:13 Message: Logged In: YES user_id=1344176 Originator: NO Fixed in r54243. I changed the ambiguous word "fields" to "indexes", which should make it perfectly clear where the count starts from. Thanks for the bug report! ---------------------------------------------------------------------- Comment By: Mark Roberts (mark-roberts) Date: 2007-01-19 20:16 Message: Logged In: YES user_id=1591633 Originator: NO Link to document in question: http://www.python.org/doc/lib/module-email.utils.html www.python.org/sf/1639973 for doc patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1629566&group_id=5470 From noreply at sourceforge.net Fri Mar 9 19:25:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 10:25:40 -0800 Subject: [ python-Bugs-1628987 ] inspect trouble when source file changes Message-ID: Bugs item #1628987, was opened at 2007-01-05 13:43 Message generated for change (Comment added) made by philipdumont You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1628987&group_id=5470 Please note that this 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 Private: No Submitted By: phil (philipdumont) Assigned to: Nobody/Anonymous (nobody) Summary: inspect trouble when source file changes Initial Comment: backtrace (relevant outer frames only): File "/path/to/myfile", line 1198, in get_hook_name for frame_record in inspect.stack(): File "/usr/mbench2.2/lib/python2.4/inspect.py", line 819, in stack return getouterframes(sys._getframe(1), context) File "/usr/mbench2.2/lib/python2.4/inspect.py", line 800, in getouterframes framelist.append((frame,) + getframeinfo(frame, context)) File "/usr/mbench2.2/lib/python2.4/inspect.py", line 775, in getframeinfo lines, lnum = findsource(frame) File "/usr/mbench2.2/lib/python2.4/inspect.py", line 437, in findsource if pat.match(lines[lnum]): break IndexError: list index out of range Based on a quick look at the inspect code, I think this happens when you: - Start python and load a module - While it's running, edit the source file for the module (before inspect tries to look into it). - Call a routine in the edited module that will lead to a call to inspect.stack(). During an inspect.stack() call, inspect will open source files to get the source code for the routines on the stack. If the source file that is opened doesn't match the byte compiled code that's being run, there are problems. Inspect caches the files it reads (using the linecache module), so if the file gets cached before it is edited, nothing should go wrong. But if the source file is edited after the module is loaded and before inspect has a chance to cache the source, you're out of luck. Of course, this shouldn't be a problem in production code, but it has bit us more than once in a development environment. Seems like it would be easy to avoid by just comparing the timestamps on the source/object files. If the source file is newer, just behave the same as if it wasn't there. Attached is a stupid little python script that reproduces the problem. ---------------------------------------------------------------------- >Comment By: phil (philipdumont) Date: 2007-03-09 13:25 Message: Logged In: YES user_id=1364034 Originator: YES What I had in mind was something like changing: def getsourcefile(object): """Return the Python source file an object was defined in, if it exists.""" filename = getfile(object) if string.lower(filename[-4:]) in ['.pyc', '.pyo']: filename = filename[:-4] + '.py' # ...the rest of the function... to def getsourcefile(object): """Return the Python source file an object was defined in, if it exists.""" filename = getfile(object) if string.lower(filename[-4:]) in ['.pyc', '.pyo']: src_filename = filename[:-4] + '.py' try: # if src file has been edited since we loaded the obj file, ignore it if os.stat(filename).st_mtime > os.stat(src_filename).st_mtime: filename = src_filename except OSError: pass # ...the rest of the function... But now that I've tried to implement it, and thought about it a bit more, I see some of the issues with what I thought would be a simple fix: - I originally thought that, if a module is loaded from source (either because the objfile did not exist, or because objfile was older), and the compiled src was successfully written to a new objfile, that inspect.getfile() would return the path to the objfile. I see now that that is not the case; it returns the srcfile. That makes my fix a bit more difficult -- now you have to find out if there is an obj file, and if so, what it's called. And even if you had a handle on both the srcfile and the objfile: - Even if the srcfile's timestamp is newer than the objfile's, it doesn't necessarily mean that the srcfile has been edited since it was loaded. It could be that the srcfile was already newer than the objfile before the module was loaded, so the module was loaded from the srcfile, and the objfile was not updated because it was not writable by the user. - Even if the srcfile's timestamp is older than the objfile's, it doesn't necessarily mean that the srcfile represents what you have loaded in memory. It could be that after you loaded the module, your colleague down the hall edited the source, loaded the module, and in the process was successful in updating the objfile. (Not a likely scenario, but...) - If the module was loaded from source, there was no objfile, and an objfile could not be created because the directory was not writable, the fix doesn't help at all. To be able to fix this right, you'd have to know what the timestamp was on whatever file was loaded at the time that import loaded it. I guess import itself would have to stash this away somewhere. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-08 16:19 Message: Logged In: YES user_id=1344176 Originator: NO Could you possibly work up a patch demonstrating exactly what you're proposing with the "comparing the timestamps" solution? That seems like a lot of complication for such a rare issue, but I'd be interested in seeing a patch all the same. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1628987&group_id=5470 From noreply at sourceforge.net Fri Mar 9 19:49:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 10:49:23 -0800 Subject: [ python-Bugs-805194 ] Inappropriate error received using socket timeout Message-ID: Bugs item #805194, was opened at 2003-09-12 12:56 Message generated for change (Comment added) made by dmeranda You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805194&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Popov (evgeni_popov) Assigned to: Nobody/Anonymous (nobody) Summary: Inappropriate error received using socket timeout Initial Comment: When using the timeout option with a socket object (python 2.3), I don't have the same behaviour under Windows than under Linux / Mac. Specifically, if trying to connect to an unopened port of the localhost, I get a timeout exception on Windows (tested under W2K Server), whereas I get a "111 - Connection Refused" exception on Linux and "22 - Invalid Argument" on Mac (OS X). Even if the error message under Mac is not really appropriate (someone said to me he got the right 'Connection Refused' on his MAC), I think that the behaviour under Linux and Mac is the right one, in that it sends (quickly) an error message and not timeouting. Note that when using blocking socket the behaviour is ok under all platforms: they each return back quickly a "Connection refused" error message (err codes are different depending on the platform (61=Mac, 111=Linux, 10061=Windows)). FYI, I don't use firewall or similar prog on my windows box (but that should not matter, because it does work in blocking mode, so that can't be a firewall problem). I heard that the timeout option was implemented based on Timothy O'Malley timeoutsocket.py. Then, maybe the pb can come from the usage of select in the connection function: select is not asked to get back exceptions in the returned triple, whereas I think some errors can be returned back through this mean under Windows (according to Tip 25 of Jon C. Snader book's "Effective TCP/IP Programming"). So, by not checking the returned exceptions, we would miss the "connection refused" error and get instead the timeout error... ---------------------------------------------------------------------- Comment By: Deron Meranda (dmeranda) Date: 2007-03-09 13:49 Message: Logged In: YES user_id=847188 Originator: NO Verified that AIX 5.2 works fine, it returns an ECONNREFUSED in all cases. Some interesting related links though: Twisted bug# 2022 http://twistedmatrix.com/trac/ticket/2022 "Non-blocking BSD socket connections" by D.J. Bernstein http://cr.yp.to/docs/connect.html There's also an interesting comment in Apache's APR change notes for APR 0.9 which seems to indicate that perhaps doing a second connect() is wrong: "*) Non-blocking connects shouldn't be calling connect a second time. According to Single Unix, a non-blocking connect has succeeded when the select pops successfully. It has failed if the select failed. The second connect was causing 502's in the httpd-proxy. [John Barbee barbee at veribox.net]" If the APR comment is correct, then perhaps this is a Python bug after all?? ---------------------------------------------------------------------- Comment By: Deron Meranda (dmeranda) Date: 2007-03-09 11:53 Message: Logged In: YES user_id=847188 Originator: NO This is also a problem under HP-UX 11.0 with Python 2.5 The socket connect_ex() will return errno 22 EINVAL instead of the more appropriate 239 ECONNREFUSED when connecting to a non-listening socket ... but only if a socket timeout is being used. A system call trace reveils a little more what is going on. For the python code import socket s = socket.socket( socket.AF_INET, socket.SOCK_STREAM ) s.settimeout(15.0) res = s.connect_ex( ('127.0.0.1', 8099) ) # An unused port number the system call sequence is as follows: Calling socket.socket() socket(AF_INET, SOCK_STREAM, 0) = 3 Calling s.settimeout(15.0) fcntl(3, F_GETFL, 0) = 2 fcntl(3, F_SETFL, 65538) = 0 Calling s.connect_ex(...) connect(3, 0x400b43f0, 16) = -1 -> ERR#245 EINPROGRESS poll(0x7cff1914, 1, 15000) = 1 connect(3, 0x400b43f0, 16) = -1 -> ERR#22 EINVAL If the call to settimeout is removed, then an ERR#239 ECONNREFUSED is returned by the first connect() and no subsequent poll+connect is attempted. With the timeout set, note that the poll() returns immediately no timeout actually occurs. Note that tracing the same code under Linux shows the exact same set of system calls, but that the second connect() call returns ECONNREFUSED instead. So this appears to be a specific behavior of HP-UX (and perhaps other Unixes). Excerpted from the HP man pages for connect(2): [EINVAL] The socket has already been shut down or has a listen() active on it; addrlen is a bad value; an attempt was made to connect() an AF_UNIX socket to an NFS- mounted (remote) name; the X.121 address length is zero, negative, or greater than 15 digits. For datagram sockets, if addrlen is a bad value, the peer address is no longer maintained by the system. [ECONNREFUSED] The attempt to connect was forcefully rejected. [EINPROGRESS] Nonblocking I/O is enabled using O_NONBLOCK, O_NDELAY, or FIOSNBIO, and the connection cannot be completed immediately. This is not a failure. Make the connect() call again a few seconds later. Alternatively, wait for completion by calling select() and selecting for write. ---------------------------------------------------------------------- Comment By: Troels Walsted Hansen (troels) Date: 2004-06-02 04:51 Message: Logged In: YES user_id=32863 The Windows part of this bug is a duplicate of bug #777597. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805194&group_id=5470 From noreply at sourceforge.net Fri Mar 9 21:23:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 12:23:22 -0800 Subject: [ python-Bugs-1646630 ] ctypes.string_at(buf, 0) is seen as zero-terminated-string Message-ID: Bugs item #1646630, was opened at 2007-01-28 23:18 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646630&group_id=5470 Please note that this 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.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Johannes H?lzl (johannes) Assigned to: Thomas Heller (theller) Summary: ctypes.string_at(buf, 0) is seen as zero-terminated-string Initial Comment: ctypes.string_at() interprets size=0 wrong. When the size argument is 0, ctypes.string_at (and probably wstring_at too) string_at tries to read an zero-terminated string instead of an empty string. Python 2.5 (r25:51908, Oct 6 2006, 15:22:41) [GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from ctypes import * >>> bytes = (c_char*3)("1", "2", "\0") >>> string_at(pointer(bytes)) '12' >>> string_at(pointer(bytes), 0) '12' >>> string_at(pointer(bytes), 1) '1' instead of: >>> string_at(pointer(bytes), 0) '' ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2007-03-09 21:23 Message: Logged In: YES user_id=11105 Originator: NO Fixed in rev. 54244 (trunk) and rev. 54246 (release25-maint). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646630&group_id=5470 From noreply at sourceforge.net Fri Mar 9 21:42:27 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 12:42:27 -0800 Subject: [ python-Bugs-1516995 ] test_logging fails with reference count-checking enabled Message-ID: Bugs item #1516995, was opened at 2006-07-04 10:34 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516995&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) >Assigned to: Vinay Sajip (vsajip) Summary: test_logging fails with reference count-checking enabled Initial Comment: When running from the following, test_logging fails: ./python Lib/test/regrtest.py -R :: test_logging. Here's the traceback: test test_logging crashed -- : Traceback (most recent call last): File "Lib/test/regrtest.py", line 554, in runtest_inner dash_R(the_module, test, indirect_test, huntrleaks) File "Lib/test/regrtest.py", line 673, in dash_R run_the_test() File "Lib/test/regrtest.py", line 660, in run_the_test indirect_test() File "/home/collin/src/python/Lib/test/test_support.py", line 299, in inner return func(*args, **kwds) File "/home/collin/src/python/Lib/test/test_logging.py", line 677, in test_main test_main_inner() File "/home/collin/src/python/Lib/test/test_logging.py", line 640, in test_main_inner globals()['test%d' % t]() File "/home/collin/src/python/Lib/test/test_logging.py", line 347, in test2 sh.close() File "/home/collin/src/python/Lib/logging/__init__.py", line 687, in close del _handlers[self] KeyError: This problem does not occur when run without reference count-checking. System info: Python SVN r47224 Linux 2.6.13 x86 ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-09 15:42 Message: Logged In: YES user_id=1344176 Originator: YES Still present as of 54248. Vinay, do you have any insights on this? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 00:03 Message: Logged In: YES user_id=1344176 This issue is still present as of r51654. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516995&group_id=5470 From noreply at sourceforge.net Fri Mar 9 21:50:35 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 12:50:35 -0800 Subject: [ python-Bugs-1651235 ] ctypes.Structure formal parameter dies given tuple Message-ID: Bugs item #1651235, was opened at 2007-02-03 15:05 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1651235&group_id=5470 Please note that this 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.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Gary Bishop (tgbishop) Assigned to: Thomas Heller (theller) Summary: ctypes.Structure formal parameter dies given tuple Initial Comment: With a structure like: class CvRect(ctypes.Structure): _fields_ = [("x", ctypes.c_int), ("y", ctypes.c_int), ("width", ctypes.c_int), ("height", ctypes.c_int)] and a foreign function like: cvSetImageROI = _cxDLL.cvSetImageROI cvSetImageROI.restype = None # void cvSetImageROI.argtypes = [ ctypes.c_void_p, # IplImage* image CvRect # CvRect rect ] The call cvSetImageROI(img, CvRect(1,2,3,4)) works fine but the mistaken call: cvSetImageROI(img, (1,2,3,4)) Produces the "Send Error Report" dialog from Windows. Other erroneous arguments produce a message about correct argument type but the tuple triggers some other behavior. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2007-03-09 21:50 Message: Logged In: YES user_id=11105 Originator: NO Fixed in rev. 54248 (trunk) and rev. 54249 (release25-maint). Thanks for the report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1651235&group_id=5470 From noreply at sourceforge.net Sat Mar 10 00:18:21 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 15:18:21 -0800 Subject: [ python-Bugs-1628987 ] inspect trouble when source file changes Message-ID: Bugs item #1628987, was opened at 2007-01-05 13:43 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1628987&group_id=5470 Please note that this 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 Private: No Submitted By: phil (philipdumont) Assigned to: Nobody/Anonymous (nobody) Summary: inspect trouble when source file changes Initial Comment: backtrace (relevant outer frames only): File "/path/to/myfile", line 1198, in get_hook_name for frame_record in inspect.stack(): File "/usr/mbench2.2/lib/python2.4/inspect.py", line 819, in stack return getouterframes(sys._getframe(1), context) File "/usr/mbench2.2/lib/python2.4/inspect.py", line 800, in getouterframes framelist.append((frame,) + getframeinfo(frame, context)) File "/usr/mbench2.2/lib/python2.4/inspect.py", line 775, in getframeinfo lines, lnum = findsource(frame) File "/usr/mbench2.2/lib/python2.4/inspect.py", line 437, in findsource if pat.match(lines[lnum]): break IndexError: list index out of range Based on a quick look at the inspect code, I think this happens when you: - Start python and load a module - While it's running, edit the source file for the module (before inspect tries to look into it). - Call a routine in the edited module that will lead to a call to inspect.stack(). During an inspect.stack() call, inspect will open source files to get the source code for the routines on the stack. If the source file that is opened doesn't match the byte compiled code that's being run, there are problems. Inspect caches the files it reads (using the linecache module), so if the file gets cached before it is edited, nothing should go wrong. But if the source file is edited after the module is loaded and before inspect has a chance to cache the source, you're out of luck. Of course, this shouldn't be a problem in production code, but it has bit us more than once in a development environment. Seems like it would be easy to avoid by just comparing the timestamps on the source/object files. If the source file is newer, just behave the same as if it wasn't there. Attached is a stupid little python script that reproduces the problem. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-09 18:18 Message: Logged In: YES user_id=1344176 Originator: NO """ To be able to fix this right, you'd have to know what the timestamp was on whatever file was loaded at the time that import loaded it. I guess import itself would have to stash this away somewhere. """ While I don't see this change being made, you might talk to Brett Cannon about it. He's working on a rewrite of the import machinery in Python and probably knows that system better than most by this point. Unless he/you can come up with something, though, I'm inclined to close the bug because of its provocation difficulty. ---------------------------------------------------------------------- Comment By: phil (philipdumont) Date: 2007-03-09 13:25 Message: Logged In: YES user_id=1364034 Originator: YES What I had in mind was something like changing: def getsourcefile(object): """Return the Python source file an object was defined in, if it exists.""" filename = getfile(object) if string.lower(filename[-4:]) in ['.pyc', '.pyo']: filename = filename[:-4] + '.py' # ...the rest of the function... to def getsourcefile(object): """Return the Python source file an object was defined in, if it exists.""" filename = getfile(object) if string.lower(filename[-4:]) in ['.pyc', '.pyo']: src_filename = filename[:-4] + '.py' try: # if src file has been edited since we loaded the obj file, ignore it if os.stat(filename).st_mtime > os.stat(src_filename).st_mtime: filename = src_filename except OSError: pass # ...the rest of the function... But now that I've tried to implement it, and thought about it a bit more, I see some of the issues with what I thought would be a simple fix: - I originally thought that, if a module is loaded from source (either because the objfile did not exist, or because objfile was older), and the compiled src was successfully written to a new objfile, that inspect.getfile() would return the path to the objfile. I see now that that is not the case; it returns the srcfile. That makes my fix a bit more difficult -- now you have to find out if there is an obj file, and if so, what it's called. And even if you had a handle on both the srcfile and the objfile: - Even if the srcfile's timestamp is newer than the objfile's, it doesn't necessarily mean that the srcfile has been edited since it was loaded. It could be that the srcfile was already newer than the objfile before the module was loaded, so the module was loaded from the srcfile, and the objfile was not updated because it was not writable by the user. - Even if the srcfile's timestamp is older than the objfile's, it doesn't necessarily mean that the srcfile represents what you have loaded in memory. It could be that after you loaded the module, your colleague down the hall edited the source, loaded the module, and in the process was successful in updating the objfile. (Not a likely scenario, but...) - If the module was loaded from source, there was no objfile, and an objfile could not be created because the directory was not writable, the fix doesn't help at all. To be able to fix this right, you'd have to know what the timestamp was on whatever file was loaded at the time that import loaded it. I guess import itself would have to stash this away somewhere. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-08 16:19 Message: Logged In: YES user_id=1344176 Originator: NO Could you possibly work up a patch demonstrating exactly what you're proposing with the "comparing the timestamps" solution? That seems like a lot of complication for such a rare issue, but I'd be interested in seeing a patch all the same. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1628987&group_id=5470 From noreply at sourceforge.net Sat Mar 10 01:32:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 16:32:26 -0800 Subject: [ python-Bugs-1531963 ] SocketServer.TCPServer returns different ports Message-ID: Bugs item #1531963, was opened at 2006-07-31 15:58 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531963&group_id=5470 Please note that this 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: Fixed Priority: 5 Private: No Submitted By: hakker.de (hakker_de) Assigned to: Nobody/Anonymous (nobody) Summary: SocketServer.TCPServer returns different ports Initial Comment: Providing 0 as a port in __init__ of SocketServer.TCPServer leads to different values for port in server_address and socket.getsockname(). Example: import SocketServer s = SocketServer.TCPServer(("0.0.0.0", 0), Handler) s.server_address -> ('0.0.0.0', 0) s.socket.getsockname() -> ('0.0.0.0', 39129) s.server_address should also contain 39129 as the port number for the free port found. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-09 19:32 Message: Logged In: YES user_id=1344176 Originator: NO hakker, you marked this as "fixed"; was that intentional? ---------------------------------------------------------------------- Comment By: Damon Kohler (damonkohler) Date: 2006-08-22 21:36 Message: Logged In: YES user_id=705317 Patch 1545011 is a proposed fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531963&group_id=5470 From noreply at sourceforge.net Sat Mar 10 01:49:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 16:49:51 -0800 Subject: [ python-Bugs-1677694 ] test_timeout refactoring Message-ID: Bugs item #1677694, was opened at 2007-03-10 01: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=1677694&group_id=5470 Please note that this 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 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: test_timeout refactoring Initial Comment: Please see #728815. https://sourceforge.net/tracker/index.php?func=detail&aid=728815&group_id=5470&atid=305470 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1677694&group_id=5470 From noreply at sourceforge.net Sat Mar 10 04:33:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 19:33:55 -0800 Subject: [ python-Bugs-1531963 ] SocketServer.TCPServer returns different ports Message-ID: Bugs item #1531963, was opened at 2006-07-31 15:58 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531963&group_id=5470 Please note that this 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.5 >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: hakker.de (hakker_de) Assigned to: Nobody/Anonymous (nobody) Summary: SocketServer.TCPServer returns different ports Initial Comment: Providing 0 as a port in __init__ of SocketServer.TCPServer leads to different values for port in server_address and socket.getsockname(). Example: import SocketServer s = SocketServer.TCPServer(("0.0.0.0", 0), Handler) s.server_address -> ('0.0.0.0', 0) s.socket.getsockname() -> ('0.0.0.0', 39129) s.server_address should also contain 39129 as the port number for the free port found. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-09 22:33 Message: Logged In: YES user_id=1344176 Originator: NO Fixed in r54253 (for 2.6), r54255 (for 2.5.1). Thanks for the bug report! ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-09 19:32 Message: Logged In: YES user_id=1344176 Originator: NO hakker, you marked this as "fixed"; was that intentional? ---------------------------------------------------------------------- Comment By: Damon Kohler (damonkohler) Date: 2006-08-22 21:36 Message: Logged In: YES user_id=705317 Patch 1545011 is a proposed fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531963&group_id=5470 From noreply at sourceforge.net Sat Mar 10 04:39:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 19:39:10 -0800 Subject: [ python-Bugs-1677694 ] test_timeout refactoring Message-ID: Bugs item #1677694, was opened at 2007-03-09 19:49 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1677694&group_id=5470 Please note that this 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 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: test_timeout refactoring Initial Comment: Please see #728815. https://sourceforge.net/tracker/index.php?func=detail&aid=728815&group_id=5470&atid=305470 ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-09 22:39 Message: Logged In: YES user_id=1344176 Originator: NO In a comment on patch #728815, you (Bjorn) said, "[p]lus, (I think) it fixes a bug which (I think) only happens when you access the internet from behind a web proxy." Could you split any bug fixes into a patch separate from the code cleanup and refactoring? That will make reviewing it/them easier. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1677694&group_id=5470 From noreply at sourceforge.net Sat Mar 10 04:51:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 19:51:47 -0800 Subject: [ python-Bugs-1662529 ] [2.5 regression?] failure to import the ORBit extension Message-ID: Bugs item #1662529, was opened at 2007-02-17 16:38 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1662529&group_id=5470 Please note that this 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 Private: No Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: [2.5 regression?] failure to import the ORBit extension Initial Comment: seen with 2.5 SVN 20070216, with an interpreter built with --enable-pydebug, succeeds with a 2.4.4 interpreter built with --enable-pydebug: pyorbit is version 2.14.1. $ python-dbg -c 'import ORBit' [26750 refs] Fatal Python error: ../Objects/tupleobject.c:169 object at 0x8186bdc has negative ref count -1 Aborted (core dumped) (gdb) bt #0 0xb7f89410 in __kernel_vsyscall () #1 0xb7e11df0 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7e13641 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0x081174f8 in Py_FatalError ( msg=0xbfd0ef78 "../Objects/tupleobject.c:169 object at 0x8186bdc has negative ref count -1") at ../Python/pythonrun.c:1555 #4 0x08093305 in _Py_NegativeRefcount (fname=0x816f958 "../Objects/tupleobject.c", lineno=169, op=0x8186bdc) at ../Objects/object.c:193 #5 0x080add27 in tupledealloc (op=0xb7a1bd1c) at ../Objects/tupleobject.c:169 #6 0x080973a6 in _Py_Dealloc (op=0xb7a1bd1c) at ../Objects/object.c:1928 #7 0x0814d037 in func_dealloc (op=0xb7a1d1c4) at ../Objects/funcobject.c:451 #8 0x080973a6 in _Py_Dealloc (op=0xb7a1d1c4) at ../Objects/object.c:1928 #9 0x0808eb99 in dict_dealloc (mp=0xb7a1c494) at ../Objects/dictobject.c:819 #10 0x080973a6 in _Py_Dealloc (op=0xb7a1c494) at ../Objects/object.c:1928 #11 0x0806459e in class_dealloc (op=0xb7a0bdb4) at ../Objects/classobject.c:184 #12 0x080973a6 in _Py_Dealloc (op=0xb7a0bdb4) at ../Objects/object.c:1928 #13 0x080add3b in tupledealloc (op=0xb7a22edc) at ../Objects/tupleobject.c:169 #14 0x080973a6 in _Py_Dealloc (op=0xb7a22edc) at ../Objects/object.c:1928 #15 0x08064540 in class_dealloc (op=0xb7a2446c) at ../Objects/classobject.c:183 #16 0x080973a6 in _Py_Dealloc (op=0xb7a2446c) at ../Objects/object.c:1928 #17 0x080add3b in tupledealloc (op=0xb7a243dc) at ../Objects/tupleobject.c:169 #18 0x080b13fe in subtype_dealloc (self=0xb7a243dc) at ../Objects/typeobject.c:709 #19 0x080973a6 in _Py_Dealloc (op=0xb7a243dc) at ../Objects/object.c:1928 #20 0x0808eb99 in dict_dealloc (mp=0xb7dcf214) at ../Objects/dictobject.c:819 #21 0x080973a6 in _Py_Dealloc (op=0xb7dcf214) at ../Objects/object.c:1928 #22 0x08112acb in PyInterpreterState_Clear (interp=0x81b8020) at ../Python/pystate.c:107 #23 0x081145be in Py_Finalize () at ../Python/pythonrun.c:441 #24 0x08059eb0 in Py_Main (argc=3, argv=0xbfd0f5b4) at ../Modules/main.c:545 #25 0x08058da6 in main (argc=Cannot access memory at address 0x155c ) at ../Modules/python.c:23 ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-09 22:51 Message: Logged In: YES user_id=1344176 Originator: NO The error message and backtrace here don't prove that it's a regression in Python: it could easily be a problem with an extension module. Do you get this error if you compile Python 2.5 without --with-pydebug? Is "ORBit" provided by the project at http://sourceforge.net/projects/orbit-python/ or the one at http://ftp.gnome.org/pub/GNOME/sources/pyorbit/? If the former, the project's SF page says active development stopped in 2004, so there's no way it could support Python 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1662529&group_id=5470 From noreply at sourceforge.net Sat Mar 10 08:03:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 23:03:59 -0800 Subject: [ python-Bugs-532631 ] Confusions in formatfloat Message-ID: Bugs item #532631, was opened at 2002-03-20 18:34 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=532631&group_id=5470 Please note that this 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 Private: No Submitted By: Tim Peters (tim_one) >Assigned to: Neal Norwitz (nnorwitz) Summary: Confusions in formatfloat Initial Comment: stringobject.c's formatfloat seems confused in a couple respects. 1. Testing "fabs(x)/1e25 >= 1e25" is pretty baffling. What is it intending to do? If it means what it says, it should be the simpler "fabs(x) >= 1e50". But maybe it really intended to test "fabs(x) >= 1e25". 2. The "worst case length calc" is fantasy in some %f cases. It assumes there's one digit before the decimal point, but, e.g., '%.100f'% 1e49 produces dozens of digits before the decimal point. We're saved from a buffer overrun thanks to the PyOS_snprintf () following, but unclear that truncation is sensible here (e.g., the user asked for a precision of 100 here, but only gets back 50 digits after the decimal point). Complication: we're deliberately replacing C's %f with C's %g in some cases, but the docs don't document the rules Python intends for %f. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-10 07:03 Message: Logged In: YES user_id=849994 Originator: NO The docs say, "%f conversions for numbers whose absolute value is over 1e25 are replaced by %g conversions." So is the correct solution "if fabs(x) >= 1e25"? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-08 21:28 Message: Logged In: YES user_id=31435 Leaving this unassgned again, with the first and last points unresolved (I don't have time for this now). The "worst case length calc" point is probably fixed. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-08 19:55 Message: Logged In: YES user_id=38388 Your first finding is baffling indeed. No idea how it came to be (I don't remember having added such code). The test seems to be intended to switch from 'g' format to 'f' format at an arbirary number of decimals before the decimal point. "fabs(x) >= 1e50" should do the same. Feel free to change this. The second point should be fixed after my checkin: >>> '%.100f'% 1e49 Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: formatted float is too long (precision too large?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-08 01:29 Message: Logged In: YES user_id=31435 Marc-Andre is in a better position to tell us what he fixed than I am, so assigned to him. MAL, feel free to close this if you think it's history. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-08 01:24 Message: Logged In: YES user_id=33168 Tim, did MALs recent checkin fix any of these problems? Is doc the only thing left to do? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=532631&group_id=5470 From noreply at sourceforge.net Sat Mar 10 08:22:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 23:22:23 -0800 Subject: [ python-Bugs-633930 ] Nested class __name__ Message-ID: Bugs item #633930, was opened at 2002-11-05 17:56 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633930&group_id=5470 Please note that this 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: 3 Private: No Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: Nested class __name__ Initial Comment: The __name__ attribute of a nested class should be set to 'outer.inner', both for classic and for new-style classes. E.g. >>> class C: ... class C1: pass ... >>> C.C1.__name__ 'C.C1' >>> ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-10 07:22 Message: Logged In: YES user_id=849994 Originator: NO Any interest for Python 3000 on this? Otherwise we can close it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-11 23:01 Message: Logged In: YES user_id=6380 I'm less sure I even want this now, and not at all sure how to do it any more, so lowering priority. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 23:13 Message: Logged In: YES user_id=6380 Hm, but should this also be done for functions inside classes? E.g. class C: def foo(self): pass assert C.foo.__name__ == "C.foo" assert C.__dict__["foo"].__name__ == "C.foo" And what about classes inside functions? def f(): class C: pass return C assert f().__name__ == "f.C" ??? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633930&group_id=5470 From noreply at sourceforge.net Sat Mar 10 15:39:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 06:39:09 -0800 Subject: [ python-Bugs-1677694 ] test_timeout refactoring Message-ID: Bugs item #1677694, was opened at 2007-03-10 01:49 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1677694&group_id=5470 Please note that this 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 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: test_timeout refactoring Initial Comment: Please see #728815. https://sourceforge.net/tracker/index.php?func=detail&aid=728815&group_id=5470&atid=305470 ---------------------------------------------------------------------- >Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-10 15:39 Message: Logged In: YES user_id=51702 Originator: YES But the bugfix is so simple. :) The original author Dmitry Vasiliev claimed that connecting to www.google.com with port 80 did not always work for him because of a transparent proxy. I believe what he meant was that connection was not guaranteed to timeout. So he changed the port to 21 which www.google.com does not respond to. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-10 04:39 Message: Logged In: YES user_id=1344176 Originator: NO In a comment on patch #728815, you (Bjorn) said, "[p]lus, (I think) it fixes a bug which (I think) only happens when you access the internet from behind a web proxy." Could you split any bug fixes into a patch separate from the code cleanup and refactoring? That will make reviewing it/them easier. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1677694&group_id=5470 From noreply at sourceforge.net Sat Mar 10 15:44:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 06:44:23 -0800 Subject: [ python-Bugs-1595742 ] SocketServer allow_reuse_address checked in constructor Message-ID: Bugs item #1595742, was opened at 2006-11-13 11:54 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595742&group_id=5470 Please note that this 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.6 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Peter Parente (parente) Assigned to: Nobody/Anonymous (nobody) Summary: SocketServer allow_reuse_address checked in constructor Initial Comment: Python 2.4.3 (#1, Oct 1 2006, 18:00:19) [GCC 4.1.1 20060928 (Red Hat 4.1.1-28)] on linux2 The documentation in the SocketServer class indicates that the allow_reuse_address flag may be set on a SocketServer subclass *or instance.* However, the flag is read in a call to the server_bind() from the constructor of the server object. Therefore, setting the flag on a created instance has no effect. This is problematic when trying to set the flag on SimpleXMLRPCServer instances, for instance, which are often not subclassed. This flag should probably become one of the keyword arguments in the constructor of a SocketServer object. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-10 09:44 Message: Logged In: YES user_id=1344176 Originator: NO Fixed by applying patch #1599845 as r54262. Thanks for your bug report! ---------------------------------------------------------------------- Comment By: Peter Parente (parente) Date: 2006-11-20 12:16 Message: Logged In: YES user_id=624776 Originator: YES Submitted as patch #1599845 in patch tracker. ---------------------------------------------------------------------- Comment By: Peter Parente (parente) Date: 2006-11-20 12:07 Message: Logged In: YES user_id=624776 Originator: YES The SimpleXMLRPCServer class in SVN HEAD now has allow_reuse_address set to True by default. This mimics the implementation of the BaseHTTPServer class which also has it set to True. Therefore, this patch should probably not concentrate on just making allow_reuse_address flag accessible on instances via __init__. Instead, the patch should probably be for TCPServer and specify whether server_bind and server_activate are called automatically or not by the constructor. The default behavior will remain the same as it is now. Specifying False on this flag will allow a developer to set the various variables on a TCPServer server instance before invoking bind/activate manually. ---------------------------------------------------------------------- Comment By: Peter Parente (parente) Date: 2006-11-16 22:28 Message: Logged In: YES user_id=624776 Originator: YES Will do. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-15 12:34 Message: Logged In: YES user_id=849994 Originator: NO Would you want to work on a patch for this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595742&group_id=5470 From noreply at sourceforge.net Sat Mar 10 17:14:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 08:14:16 -0800 Subject: [ python-Bugs-1675511 ] Python still uses broken -xcode option on Solaris/x86 Message-ID: Bugs item #1675511, was opened at 2007-03-07 15:54 Message generated for change (Comment added) made by jlick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: Python still uses broken -xcode option on Solaris/x86 Initial Comment: Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting a new bug against 2.5 in the hopes that someone will read it... text updated with minor corrections. Python 2.5, Solaris x86 10 Update 3, Sun Studio 11 xcode=pic32 option is not supported on Solaris x86 Sun C . Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when any compiler other than gcc is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates an error that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-11 00:14 Message: Logged In: YES user_id=673069 Originator: NO I'm willing to take a stab at a patch. I've reviewed the Sun Studio 11 documentation and it appears that the preferred options are: Sun cc Sparc: -xcode=pic32 Sun cc X86: -Kpic Does that match the way you read it, loewis? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-09 16:56 Message: Logged In: YES user_id=21627 Originator: NO I don't want to make a change now, just to have to deal with a bug report two years from now which then will sit again in this tracker for years again. I'm fine with documenting that older SunPRO compilers are not supported; -xcode has been supported atleast since Sun Forte 6 (released in 2000); earlier products had reached their end-of-life long ago. So either this gets fixed properly now, or not at all. ---------------------------------------------------------------------- Comment By: Carson Gaspar (cgaspar) Date: 2007-03-09 16:06 Message: Logged In: YES user_id=664506 Originator: YES While the doc labels the -KPIC option as "obsolete" for SPARC, it works fine. Perhaps Studio 12 will break it, but all current compilers understand it fine. If you want to be pedantically correct and use -xcode=pic32, you don't need an architecture test, you need to actually _try_ the option, as older SPARC compilers won't accept it either. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-09 15:08 Message: Logged In: YES user_id=21627 Originator: NO One problem is that the proposed change is incorrect. According to the C User's Guide of Sun Studio 11 (document 819-3688-10), -KPIC is an obsolete option on SPARC, and should be replaced with -xcode=pic32 (section A.1.15). So I think a patch should be architecture-specific. Can somebody come up with a patch that does that? ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-07 16:34 Message: Logged In: YES user_id=673069 Originator: NO Perhaps I was unclear in bug #1561333 that this resulted in only a warning. Actually the build will fail because of the incorrect flag. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 From noreply at sourceforge.net Sat Mar 10 18:07:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 09:07:01 -0800 Subject: [ python-Bugs-1675511 ] Python still uses broken -xcode option on Solaris/x86 Message-ID: Bugs item #1675511, was opened at 2007-03-07 08:54 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: Python still uses broken -xcode option on Solaris/x86 Initial Comment: Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting a new bug against 2.5 in the hopes that someone will read it... text updated with minor corrections. Python 2.5, Solaris x86 10 Update 3, Sun Studio 11 xcode=pic32 option is not supported on Solaris x86 Sun C . Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when any compiler other than gcc is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates an error that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-10 18:07 Message: Logged In: YES user_id=21627 Originator: NO Looks fine, although you might want to consider AMD64 as well. I think it should be -KPIC (although I'm uncertain whether Python works on that system at all). See http://blogs.sun.com/x86be/category/Sun ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-10 17:14 Message: Logged In: YES user_id=673069 Originator: NO I'm willing to take a stab at a patch. I've reviewed the Sun Studio 11 documentation and it appears that the preferred options are: Sun cc Sparc: -xcode=pic32 Sun cc X86: -Kpic Does that match the way you read it, loewis? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-09 09:56 Message: Logged In: YES user_id=21627 Originator: NO I don't want to make a change now, just to have to deal with a bug report two years from now which then will sit again in this tracker for years again. I'm fine with documenting that older SunPRO compilers are not supported; -xcode has been supported atleast since Sun Forte 6 (released in 2000); earlier products had reached their end-of-life long ago. So either this gets fixed properly now, or not at all. ---------------------------------------------------------------------- Comment By: Carson Gaspar (cgaspar) Date: 2007-03-09 09:06 Message: Logged In: YES user_id=664506 Originator: YES While the doc labels the -KPIC option as "obsolete" for SPARC, it works fine. Perhaps Studio 12 will break it, but all current compilers understand it fine. If you want to be pedantically correct and use -xcode=pic32, you don't need an architecture test, you need to actually _try_ the option, as older SPARC compilers won't accept it either. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-09 08:08 Message: Logged In: YES user_id=21627 Originator: NO One problem is that the proposed change is incorrect. According to the C User's Guide of Sun Studio 11 (document 819-3688-10), -KPIC is an obsolete option on SPARC, and should be replaced with -xcode=pic32 (section A.1.15). So I think a patch should be architecture-specific. Can somebody come up with a patch that does that? ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-07 09:34 Message: Logged In: YES user_id=673069 Originator: NO Perhaps I was unclear in bug #1561333 that this resulted in only a warning. Actually the build will fail because of the incorrect flag. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 From noreply at sourceforge.net Sat Mar 10 18:09:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 09:09:14 -0800 Subject: [ python-Bugs-1672332 ] cPickle can pickle, but cannot unpickle on 64bit machines Message-ID: Bugs item #1672332, was opened at 2007-03-02 12:10 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672332&group_id=5470 Please note that this 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 Private: No Submitted By: Bartlomiej Ogryczak (oneg) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle can pickle, but cannot unpickle on 64bit machines Initial Comment: Seems that on 64-bit machines cPickle is able to pickle floats smaller then DBL_MIN, but it's unable to unpickle them. 64-bit machine (Solaris 10 on Sparc) Python 2.4.4 (#1, Oct 26 2006, 10:01:37) [GCC 3.3.4] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import cPickle >>> cPickle.dumps(1e-310) 'F9.9999999999999694e-311\n.' >>> cPickle.loads(_) Traceback (most recent call last): File "", line 1, in ? ValueError: could not convert string to float Same thing works fine on 32-bit machine (P4 with MS Windows) Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import cPickle >>> cPickle.dumps(1e-310) 'F0\n.' >>> ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-10 18:09 Message: Logged In: YES user_id=21627 Originator: NO If python is a 32-bit binary, it should be completely irrelevant that the processor is a 64-bit processor. Python can't tell the difference. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-05 22:46 Message: Logged In: YES user_id=849994 Originator: NO I seem to remember that float pickling has been overhauled for 2.5, could you try with a 2.5 Python and report the results? ---------------------------------------------------------------------- Comment By: Bartlomiej Ogryczak (oneg) Date: 2007-03-05 17:49 Message: Logged In: YES user_id=1733256 Originator: YES I forgot to specify, it's 32-bit Python binary. I'm guessing yours is 64-bit binary on 64-bit system? Some additional info: gcc --version gcc (GCC) 3.3.4 $ file `which python` ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped $ ldd `which python` libresolv.so.2 => /usr/lib/libresolv.so.2 libsocket.so.1 => /usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 librt.so.1 => /usr/lib/librt.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libstdc++.so.5 => /usr/local/lib/libstdc++.so.5 libm.so.2 => /usr/lib/libm.so.2 libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 libc.so.1 => /usr/lib/libc.so.1 libmp.so.2 => /usr/lib/libmp.so.2 libmd5.so.1 => /usr/lib/libmd5.so.1 libscf.so.1 => /usr/lib/libscf.so.1 libaio.so.1 => /usr/lib/libaio.so.1 libdoor.so.1 => /usr/lib/libdoor.so.1 libuutil.so.1 => /usr/lib/libuutil.so.1 /platform/SUNW,Sun-Fire-15000/lib/libc_psr.so.1 /platform/SUNW,Sun-Fire-15000/lib/libmd5_psr.so.1 ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2007-03-05 17:38 Message: Logged In: YES user_id=178886 Originator: NO FYI: it doesn't happen for me in python 2.4.3, 2.5svn and 2.6svn built on linux (x86_64) with gcc-4.1.2, so it looks compiler version or hw platform specific. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672332&group_id=5470 From noreply at sourceforge.net Sat Mar 10 18:24:35 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 09:24:35 -0800 Subject: [ python-Bugs-1528074 ] difflib.SequenceMatcher.find_longest_match() wrong result Message-ID: Bugs item #1528074, was opened at 2006-07-25 03:59 Message generated for change (Comment added) made by rtvd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528074&group_id=5470 Please note that this 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 Private: No Submitted By: John Machin (sjmachin) Assigned to: Tim Peters (tim_one) Summary: difflib.SequenceMatcher.find_longest_match() wrong result Initial Comment: A short example script is attached. Two strings, each 500 bytes long. Longest match is the first 32 bytes of each string. Result produced is a 10-byte match later in the string. If one byte is chopped off the end of each string (len now 499 each), the correct result is produced. Other observations, none of which may be relevant: 1. Problem may be in the heuristic for "popular" elements in the __chain_b method. In this particular example, the character '0' (which has frequency of 6 in the "b" string) is not "popular" with a len of 500 but is "popular" with a len of 499. 2. '0' is the last byte of the correct longest match. 3. The correct longest match is at the start of the each of the strings. 4. Disabling the "popular" heuristic (like below) appears to make the problem go away: if 0: # if n >= 200 and len(indices) * 100 > n: populardict[elt] = 1 del indices[:] else: indices.append(i) 5. The callable self.isbpopular is created but appears to be unused. 6. The determination of "popular" doesn't accord with the comments, which say 1%. However with len==500, takes 6 to be popular. ---------------------------------------------------------------------- Comment By: Denys Rtveliashvili (rtvd) Date: 2007-03-10 20:24 Message: Logged In: YES user_id=1416496 Originator: NO The quick test for this bug is: for i in xrange(190, 200): text1 = "a" + "b"*i text2 = "b"*i + "c" m = difflib.SequenceMatcher(None, text1, text2) (aptr,bptr,l) = m.find_longest_match(0, len(text1), 0, len(text2)) print "i:", i, " l:", l, " aptr:", aptr, " bptr:", bptr assert l == i The assertion will fail when i==199 (the length of the texts will be 200). And yes, the bug is clearly "populardict"-related. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528074&group_id=5470 From noreply at sourceforge.net Sat Mar 10 18:25:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 09:25:02 -0800 Subject: [ python-Bugs-1516995 ] test_logging fails with reference count-checking enabled Message-ID: Bugs item #1516995, was opened at 2006-07-04 14:34 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516995&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Vinay Sajip (vsajip) Summary: test_logging fails with reference count-checking enabled Initial Comment: When running from the following, test_logging fails: ./python Lib/test/regrtest.py -R :: test_logging. Here's the traceback: test test_logging crashed -- : Traceback (most recent call last): File "Lib/test/regrtest.py", line 554, in runtest_inner dash_R(the_module, test, indirect_test, huntrleaks) File "Lib/test/regrtest.py", line 673, in dash_R run_the_test() File "Lib/test/regrtest.py", line 660, in run_the_test indirect_test() File "/home/collin/src/python/Lib/test/test_support.py", line 299, in inner return func(*args, **kwds) File "/home/collin/src/python/Lib/test/test_logging.py", line 677, in test_main test_main_inner() File "/home/collin/src/python/Lib/test/test_logging.py", line 640, in test_main_inner globals()['test%d' % t]() File "/home/collin/src/python/Lib/test/test_logging.py", line 347, in test2 sh.close() File "/home/collin/src/python/Lib/logging/__init__.py", line 687, in close del _handlers[self] KeyError: This problem does not occur when run without reference count-checking. System info: Python SVN r47224 Linux 2.6.13 x86 ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2007-03-10 17:25 Message: Logged In: YES user_id=308438 Originator: NO Hi Collin, I'm sorry to be so slow on this. For various reasons, I don't have a debug build of Python 2.5 :-(, without which the -R option is not available to me. Also, of course, it's not a bug in logging itself, more in the test case. If you have time, I would appreciate some help on this: I would temporarily modify test_logging to print out the StreamHandlers created either explicity in test_logging.py or via the calls to fileConfig(), to see which StreamHandler is not being released. TIA... ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-09 20:42 Message: Logged In: YES user_id=1344176 Originator: YES Still present as of 54248. Vinay, do you have any insights on this? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 04:03 Message: Logged In: YES user_id=1344176 This issue is still present as of r51654. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516995&group_id=5470 From noreply at sourceforge.net Sat Mar 10 19:21:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 10:21:14 -0800 Subject: [ python-Bugs-633930 ] Nested class __name__ Message-ID: Bugs item #633930, was opened at 2002-11-05 12:56 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633930&group_id=5470 Please note that this 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: None Priority: 3 Private: No Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: Nested class __name__ Initial Comment: The __name__ attribute of a nested class should be set to 'outer.inner', both for classic and for new-style classes. E.g. >>> class C: ... class C1: pass ... >>> C.C1.__name__ 'C.C1' >>> ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-10 13:21 Message: Logged In: YES user_id=6380 Originator: YES I don't think so. Closing. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-10 02:22 Message: Logged In: YES user_id=849994 Originator: NO Any interest for Python 3000 on this? Otherwise we can close it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-11 18:01 Message: Logged In: YES user_id=6380 I'm less sure I even want this now, and not at all sure how to do it any more, so lowering priority. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 18:13 Message: Logged In: YES user_id=6380 Hm, but should this also be done for functions inside classes? E.g. class C: def foo(self): pass assert C.foo.__name__ == "C.foo" assert C.__dict__["foo"].__name__ == "C.foo" And what about classes inside functions? def f(): class C: pass return C assert f().__name__ == "f.C" ??? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633930&group_id=5470 From noreply at sourceforge.net Sat Mar 10 19:35:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 10:35:37 -0800 Subject: [ python-Bugs-1675511 ] Python still uses broken -xcode option on Solaris/x86 Message-ID: Bugs item #1675511, was opened at 2007-03-07 15:54 Message generated for change (Comment added) made by jlick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: Python still uses broken -xcode option on Solaris/x86 Initial Comment: Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting a new bug against 2.5 in the hopes that someone will read it... text updated with minor corrections. Python 2.5, Solaris x86 10 Update 3, Sun Studio 11 xcode=pic32 option is not supported on Solaris x86 Sun C . Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when any compiler other than gcc is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates an error that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-11 02:35 Message: Logged In: YES user_id=673069 Originator: NO According the the Studio 11 man page for cc '-KPIC' is an alias for '-Kpic' on x86, though it doesn't explicitly say whether this applies to x86 meaning 32 bit only or x86 meaning both 32 and 64 bit. In any case, since -KPIC is definitely equivalent to -Kpic on 32 bit x86, and -KPIC is known to work on x64, should we just use -KPIC for both? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-11 01:07 Message: Logged In: YES user_id=21627 Originator: NO Looks fine, although you might want to consider AMD64 as well. I think it should be -KPIC (although I'm uncertain whether Python works on that system at all). See http://blogs.sun.com/x86be/category/Sun ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-11 00:14 Message: Logged In: YES user_id=673069 Originator: NO I'm willing to take a stab at a patch. I've reviewed the Sun Studio 11 documentation and it appears that the preferred options are: Sun cc Sparc: -xcode=pic32 Sun cc X86: -Kpic Does that match the way you read it, loewis? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-09 16:56 Message: Logged In: YES user_id=21627 Originator: NO I don't want to make a change now, just to have to deal with a bug report two years from now which then will sit again in this tracker for years again. I'm fine with documenting that older SunPRO compilers are not supported; -xcode has been supported atleast since Sun Forte 6 (released in 2000); earlier products had reached their end-of-life long ago. So either this gets fixed properly now, or not at all. ---------------------------------------------------------------------- Comment By: Carson Gaspar (cgaspar) Date: 2007-03-09 16:06 Message: Logged In: YES user_id=664506 Originator: YES While the doc labels the -KPIC option as "obsolete" for SPARC, it works fine. Perhaps Studio 12 will break it, but all current compilers understand it fine. If you want to be pedantically correct and use -xcode=pic32, you don't need an architecture test, you need to actually _try_ the option, as older SPARC compilers won't accept it either. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-09 15:08 Message: Logged In: YES user_id=21627 Originator: NO One problem is that the proposed change is incorrect. According to the C User's Guide of Sun Studio 11 (document 819-3688-10), -KPIC is an obsolete option on SPARC, and should be replaced with -xcode=pic32 (section A.1.15). So I think a patch should be architecture-specific. Can somebody come up with a patch that does that? ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-07 16:34 Message: Logged In: YES user_id=673069 Originator: NO Perhaps I was unclear in bug #1561333 that this resulted in only a warning. Actually the build will fail because of the incorrect flag. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 From noreply at sourceforge.net Sat Mar 10 20:06:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 11:06:54 -0800 Subject: [ python-Bugs-1675511 ] Python still uses broken -xcode option on Solaris/x86 Message-ID: Bugs item #1675511, was opened at 2007-03-07 08:54 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: Python still uses broken -xcode option on Solaris/x86 Initial Comment: Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting a new bug against 2.5 in the hopes that someone will read it... text updated with minor corrections. Python 2.5, Solaris x86 10 Update 3, Sun Studio 11 xcode=pic32 option is not supported on Solaris x86 Sun C . Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when any compiler other than gcc is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates an error that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-10 20:06 Message: Logged In: YES user_id=21627 Originator: NO The manual claims (in "Supported Platforms") that "x86" refers to both 32-bit and 64-bit systems, and promises to use "32-bit x86" for 32-bit specific information, so I guess -Kpic works on AMD64 as well. ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-10 19:35 Message: Logged In: YES user_id=673069 Originator: NO According the the Studio 11 man page for cc '-KPIC' is an alias for '-Kpic' on x86, though it doesn't explicitly say whether this applies to x86 meaning 32 bit only or x86 meaning both 32 and 64 bit. In any case, since -KPIC is definitely equivalent to -Kpic on 32 bit x86, and -KPIC is known to work on x64, should we just use -KPIC for both? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-10 18:07 Message: Logged In: YES user_id=21627 Originator: NO Looks fine, although you might want to consider AMD64 as well. I think it should be -KPIC (although I'm uncertain whether Python works on that system at all). See http://blogs.sun.com/x86be/category/Sun ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-10 17:14 Message: Logged In: YES user_id=673069 Originator: NO I'm willing to take a stab at a patch. I've reviewed the Sun Studio 11 documentation and it appears that the preferred options are: Sun cc Sparc: -xcode=pic32 Sun cc X86: -Kpic Does that match the way you read it, loewis? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-09 09:56 Message: Logged In: YES user_id=21627 Originator: NO I don't want to make a change now, just to have to deal with a bug report two years from now which then will sit again in this tracker for years again. I'm fine with documenting that older SunPRO compilers are not supported; -xcode has been supported atleast since Sun Forte 6 (released in 2000); earlier products had reached their end-of-life long ago. So either this gets fixed properly now, or not at all. ---------------------------------------------------------------------- Comment By: Carson Gaspar (cgaspar) Date: 2007-03-09 09:06 Message: Logged In: YES user_id=664506 Originator: YES While the doc labels the -KPIC option as "obsolete" for SPARC, it works fine. Perhaps Studio 12 will break it, but all current compilers understand it fine. If you want to be pedantically correct and use -xcode=pic32, you don't need an architecture test, you need to actually _try_ the option, as older SPARC compilers won't accept it either. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-09 08:08 Message: Logged In: YES user_id=21627 Originator: NO One problem is that the proposed change is incorrect. According to the C User's Guide of Sun Studio 11 (document 819-3688-10), -KPIC is an obsolete option on SPARC, and should be replaced with -xcode=pic32 (section A.1.15). So I think a patch should be architecture-specific. Can somebody come up with a patch that does that? ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-07 09:34 Message: Logged In: YES user_id=673069 Originator: NO Perhaps I was unclear in bug #1561333 that this resulted in only a warning. Actually the build will fail because of the incorrect flag. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 From noreply at sourceforge.net Sat Mar 10 21:36:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 12:36:30 -0800 Subject: [ python-Bugs-1516995 ] test_logging fails with reference count-checking enabled Message-ID: Bugs item #1516995, was opened at 2006-07-04 10:34 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516995&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Vinay Sajip (vsajip) Summary: test_logging fails with reference count-checking enabled Initial Comment: When running from the following, test_logging fails: ./python Lib/test/regrtest.py -R :: test_logging. Here's the traceback: test test_logging crashed -- : Traceback (most recent call last): File "Lib/test/regrtest.py", line 554, in runtest_inner dash_R(the_module, test, indirect_test, huntrleaks) File "Lib/test/regrtest.py", line 673, in dash_R run_the_test() File "Lib/test/regrtest.py", line 660, in run_the_test indirect_test() File "/home/collin/src/python/Lib/test/test_support.py", line 299, in inner return func(*args, **kwds) File "/home/collin/src/python/Lib/test/test_logging.py", line 677, in test_main test_main_inner() File "/home/collin/src/python/Lib/test/test_logging.py", line 640, in test_main_inner globals()['test%d' % t]() File "/home/collin/src/python/Lib/test/test_logging.py", line 347, in test2 sh.close() File "/home/collin/src/python/Lib/logging/__init__.py", line 687, in close del _handlers[self] KeyError: This problem does not occur when run without reference count-checking. System info: Python SVN r47224 Linux 2.6.13 x86 ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-10 15:36 Message: Logged In: YES user_id=1344176 Originator: YES Vinay: I've been able to gather a little more information. The problem occurs during the second run-through of the test suite; that is, it runs once, then "-R ::" kicks in and starts to run the test again, which is when the exception occurs. From what I can tell from poking around test2(), something is removing the "sh" handler from logging._handlers prematurely (its id() matches that displayed in the KeyError traceback). More poking around: "-R ::" doesn't really enter into it. Modifying test_main_inner() to run test2() more than once (in isolation or after other tests) will trigger this, too. On the second run, sh.close() raises a KeyError. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2007-03-10 12:25 Message: Logged In: YES user_id=308438 Originator: NO Hi Collin, I'm sorry to be so slow on this. For various reasons, I don't have a debug build of Python 2.5 :-(, without which the -R option is not available to me. Also, of course, it's not a bug in logging itself, more in the test case. If you have time, I would appreciate some help on this: I would temporarily modify test_logging to print out the StreamHandlers created either explicity in test_logging.py or via the calls to fileConfig(), to see which StreamHandler is not being released. TIA... ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-09 15:42 Message: Logged In: YES user_id=1344176 Originator: YES Still present as of 54248. Vinay, do you have any insights on this? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 00:03 Message: Logged In: YES user_id=1344176 This issue is still present as of r51654. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516995&group_id=5470 From noreply at sourceforge.net Sun Mar 11 00:07:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 15:07:43 -0800 Subject: [ python-Bugs-1678102 ] zlib.crc32() not cross-platform Message-ID: Bugs item #1678102, was opened at 2007-03-10 15:07 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=1678102&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ben Collver (bencollver) Assigned to: Nobody/Anonymous (nobody) Summary: zlib.crc32() not cross-platform Initial Comment: The zlib.crc32() function sometimes produces different results for the same input on big and little-endian processors. Same for zlib.adler32(). sparc64: >>> import zlib >>> print zlib.adler32("--------------------------------------------------", 1) > 3763407051 >>> print zlib.crc32("--------------------------------------------------", 1) 3044228349 i386: >>> import zlib >>> print zlib.adler32("--------------------------------------------------", 1) > -531560245 >>> print zlib.crc32("--------------------------------------------------", 1) -1250738947 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678102&group_id=5470 From noreply at sourceforge.net Sun Mar 11 00:13:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 15:13:00 -0800 Subject: [ python-Bugs-1678102 ] zlib.crc32() not cross-platform Message-ID: Bugs item #1678102, was opened at 2007-03-10 15:07 Message generated for change (Comment added) made by bencollver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678102&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ben Collver (bencollver) Assigned to: Nobody/Anonymous (nobody) Summary: zlib.crc32() not cross-platform Initial Comment: The zlib.crc32() function sometimes produces different results for the same input on big and little-endian processors. Same for zlib.adler32(). sparc64: >>> import zlib >>> print zlib.adler32("--------------------------------------------------", 1) > 3763407051 >>> print zlib.crc32("--------------------------------------------------", 1) 3044228349 i386: >>> import zlib >>> print zlib.adler32("--------------------------------------------------", 1) > -531560245 >>> print zlib.crc32("--------------------------------------------------", 1) -1250738947 ---------------------------------------------------------------------- >Comment By: Ben Collver (bencollver) Date: 2007-03-10 15:13 Message: Logged In: YES user_id=778667 Originator: YES The extra > characters before the first results come from me pasting the results to my irc client, then copying from there and pasting here. Sorry for any confusion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678102&group_id=5470 From noreply at sourceforge.net Sun Mar 11 01:58:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 16:58:37 -0800 Subject: [ python-Bugs-1516995 ] test_logging fails with reference count-checking enabled Message-ID: Bugs item #1516995, was opened at 2006-07-04 14:34 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516995&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Vinay Sajip (vsajip) Summary: test_logging fails with reference count-checking enabled Initial Comment: When running from the following, test_logging fails: ./python Lib/test/regrtest.py -R :: test_logging. Here's the traceback: test test_logging crashed -- : Traceback (most recent call last): File "Lib/test/regrtest.py", line 554, in runtest_inner dash_R(the_module, test, indirect_test, huntrleaks) File "Lib/test/regrtest.py", line 673, in dash_R run_the_test() File "Lib/test/regrtest.py", line 660, in run_the_test indirect_test() File "/home/collin/src/python/Lib/test/test_support.py", line 299, in inner return func(*args, **kwds) File "/home/collin/src/python/Lib/test/test_logging.py", line 677, in test_main test_main_inner() File "/home/collin/src/python/Lib/test/test_logging.py", line 640, in test_main_inner globals()['test%d' % t]() File "/home/collin/src/python/Lib/test/test_logging.py", line 347, in test2 sh.close() File "/home/collin/src/python/Lib/logging/__init__.py", line 687, in close del _handlers[self] KeyError: This problem does not occur when run without reference count-checking. System info: Python SVN r47224 Linux 2.6.13 x86 ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2007-03-11 00:58 Message: Logged In: YES user_id=308438 Originator: NO Thanks for the info. test2() is a little sensitive because it makes assumptions about the state of handlers attached to the root logger. test4() and test5() do some slightly dodgy manipulation of the internal handler list maintained by the module. I played around with the assumption that test5() is the culprit (as it's the last test run), and found that adding the lines hdlr = logging.getLogger().handlers[0] logging.getLogger().handlers.remove(hdlr) in test5(), just after the line os.remove(fn) causes the error not to occur, and the test passes successfully. Please try this on your system and re-run the tests, and if you can confirm that this change works for you, I can check it in. (I propose to only check it into trunk, and not into release25-maint or other branches - what do you think?) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-10 20:36 Message: Logged In: YES user_id=1344176 Originator: YES Vinay: I've been able to gather a little more information. The problem occurs during the second run-through of the test suite; that is, it runs once, then "-R ::" kicks in and starts to run the test again, which is when the exception occurs. From what I can tell from poking around test2(), something is removing the "sh" handler from logging._handlers prematurely (its id() matches that displayed in the KeyError traceback). More poking around: "-R ::" doesn't really enter into it. Modifying test_main_inner() to run test2() more than once (in isolation or after other tests) will trigger this, too. On the second run, sh.close() raises a KeyError. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2007-03-10 17:25 Message: Logged In: YES user_id=308438 Originator: NO Hi Collin, I'm sorry to be so slow on this. For various reasons, I don't have a debug build of Python 2.5 :-(, without which the -R option is not available to me. Also, of course, it's not a bug in logging itself, more in the test case. If you have time, I would appreciate some help on this: I would temporarily modify test_logging to print out the StreamHandlers created either explicity in test_logging.py or via the calls to fileConfig(), to see which StreamHandler is not being released. TIA... ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-09 20:42 Message: Logged In: YES user_id=1344176 Originator: YES Still present as of 54248. Vinay, do you have any insights on this? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 04:03 Message: Logged In: YES user_id=1344176 This issue is still present as of r51654. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516995&group_id=5470 From noreply at sourceforge.net Sun Mar 11 02:28:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 17:28:04 -0800 Subject: [ python-Bugs-902172 ] Timezone miscalculation (time.mktime) Message-ID: Bugs item #902172, was opened at 2004-02-22 17:09 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902172&group_id=5470 Please note that this 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 Private: No Submitted By: Marti (sipsick) Assigned to: Brett Cannon (bcannon) Summary: Timezone miscalculation (time.mktime) Initial Comment: The problem: time.mktime(time.gmtime(0)) - time.timezone == -3600. 0 (Should be 0.0 if I understood it right) Python seems to miscalculate the local time when using mktime. The problem appeared when one of the runtests in MoinMoin failed (spefically MoinMoin._tests. test_parser_wiki.WikiMacroTestCase) I used two machines for testing: 1. NetBSD 1.6.1 (GENERIC), Python version 2.3.3 (#1, Feb 20 2004, 00:53:29) [GCC 2.95.3 20010315 (release) (NetBSD nb3)] 2. Linux 2.4.20-3-686 (Debian GNU/Linux), Python version 2.3.3 (#2, Jan 13 2004, 00:47:05) [GCC 3.3.3 20040110 (prerelease) (Debian)] Both machine generate the identical error: AssertionError: Expected '1#1970-01-06 00:00:00#1' in: 1#1970-01-05 23:00:00#1 [...] A few simple tests in the python shell (both machines) >>> import time >>> time.daylight 1 >>> time.timezone -7200 >>> time.tzname ('EET', 'EEST') >>> time.mktime(time.localtime(0)) 0.0 >>> time.mktime(time.gmtime(0)) - time.timezone -3600.0 >>> time.gmtime(0) (1970, 1, 1, 0, 0, 0, 3, 1, 0) >>> time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 0)) - time. timezone -3600.0 >>> time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, -1)) - time. timezone -3600.0 However, the only difference between the Linux and BSD machine is: 1. NetBSD >>> time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 1)) - time. timezone -7200.0 2. Linux >>> time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 1)) - time. timezone -3600.0 I also attached the results of the moin test just in case. -- Marti ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 02:28 Message: Logged In: YES user_id=226443 Originator: NO Belated comment for posterity: this looks like a DST "inversion" problem - the system zone information may have been incorrect causing the system to believe that the Epoch occurred in a DST period. ---------------------------------------------------------------------- Comment By: Marti (sipsick) Date: 2004-02-24 23:52 Message: Logged In: YES user_id=345221 Summary: This doesn't look like Python's fault. case closed. bcannon wrote: > In other words, EET is two hours ahead of UTC normally and only > one hour ahead during daylight savings). That is not exactly correct. EET (Eastern European Time, in winter) is UTC+2h, and EEST (Eastern European Summer Time) is UTC+3h (This is DST) Reference: http://www.timeanddate. com/library/abbreviations/timezones/eu/eet.html The way I understand it, daylight should be 0 not 1. (DST hasn't begun yet. Reference: http://www.timeanddate.com/worldclock/city.html? n=242 Otherwise you're right: it's not even Python's fault! I got exactly the same results on my Linux machine when I tested it in C. So I suppose this case is closed. struct tm format: {sec, min, hour, mday, mon, year, wday, yday, isdst} daylight = 1 timezone = -7200 tzname = {"EET", "EEST"} mktime(localtime(0)) = 0 mktime(gmtime(0)) - timezone = -3600 gmtime(0) = {0, 0, 0, 1, 0, 70, 4, 0, 0} mktime({0, 0, 0, 1, 0, 70, 4, 0, 0}) - timezone = -3600 mktime({0, 0, 0, 1, 0, 70, 4, 0,-1}) - timezone = -3600 mktime({0, 0, 0, 1, 0, 70, 4, 0, 1}) - timezone = -3600 I attached the code of mktime.c just in case anybody would want to review it. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-02-24 09:36 Message: Logged In: YES user_id=357491 OK, what I need is the result for ``time.localtime(0)`` (according to the calculations above should be three hours ahead of UTC, but in actuality, as long as the DST field is 0, should only be two hours ahead for EET) and ``time.mktime(time.gmtime(0))`` (should be -10800 according to the calculations above, but I want to double-check). And the value of ``time.altzone`` wouldn't hurt for trying to deal with the slight difference between the two OSs (should be -3600, or 1 hour ahead of UTC, for DST in EET, right? In other words, EET is two hours ahead of UTC normally and only one hour ahead during daylight savings). It looks like time.localtime(0) is off by an hour for some odd reason. And as for the discrepency between platforms, it should be only an hour difference since you should be subtracting time.altzone with the DST flag set to 1 and not time.timezone . So it looks like Linux is behaving correctly and NetBSD is being really screwy if that is the only difference between the platforms. But, to be honest, from a quick glance and the code, the wrappers are so thin that I don't think it is going to be on our side. But with the info above I should be able to figure out where the discrepency is coming from and be able to make sure whose fault it is. ---------------------------------------------------------------------- Comment By: Marti (sipsick) Date: 2004-02-22 17:11 Message: Logged In: YES user_id=345221 Oops, forgot to check the upload box :) ---------------------------------------------------------------------- Comment By: Marti (sipsick) Date: 2004-02-22 17:11 Message: Logged In: YES user_id=345221 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902172&group_id=5470 From noreply at sourceforge.net Sun Mar 11 04:33:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 19:33:22 -0800 Subject: [ python-Bugs-1635217 ] Little mistake in docs Message-ID: Bugs item #1635217, was opened at 2007-01-14 07:09 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1635217&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: anatoly techtonik (techtonik) Assigned to: Nobody/Anonymous (nobody) Summary: Little mistake in docs Initial Comment: It would be nice to see example of setup() call on the page with "requires" keywords argument description http://docs.python.org/dist/node10.html Like: setup(..., requires=["somepackage (>1.0, !=1.5)"], provides=["mypkg (1.1)"] ) There seems to be mistake in table with examples for "provides" keyword on the same page - it looks like: mypkg (1.1 shouldn't this be mypkg (1.1)? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-10 19:33 Message: Logged In: YES user_id=33168 Originator: NO Anatoly, if you could create the doc in plain text, we could add it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-01-18 21:54 Message: Logged In: YES user_id=33168 Originator: NO Thanks for the report. I fixed the unbalanced paren. I'll leave this open in case someone is ambitious to add more doc. Committed revision 53487. (2.5) Committed revision 53488. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1635217&group_id=5470 From noreply at sourceforge.net Sun Mar 11 06:53:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 21:53:28 -0800 Subject: [ python-Bugs-1516995 ] test_logging fails with reference count-checking enabled Message-ID: Bugs item #1516995, was opened at 2006-07-04 10:34 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516995&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Vinay Sajip (vsajip) Summary: test_logging fails with reference count-checking enabled Initial Comment: When running from the following, test_logging fails: ./python Lib/test/regrtest.py -R :: test_logging. Here's the traceback: test test_logging crashed -- : Traceback (most recent call last): File "Lib/test/regrtest.py", line 554, in runtest_inner dash_R(the_module, test, indirect_test, huntrleaks) File "Lib/test/regrtest.py", line 673, in dash_R run_the_test() File "Lib/test/regrtest.py", line 660, in run_the_test indirect_test() File "/home/collin/src/python/Lib/test/test_support.py", line 299, in inner return func(*args, **kwds) File "/home/collin/src/python/Lib/test/test_logging.py", line 677, in test_main test_main_inner() File "/home/collin/src/python/Lib/test/test_logging.py", line 640, in test_main_inner globals()['test%d' % t]() File "/home/collin/src/python/Lib/test/test_logging.py", line 347, in test2 sh.close() File "/home/collin/src/python/Lib/logging/__init__.py", line 687, in close del _handlers[self] KeyError: This problem does not occur when run without reference count-checking. System info: Python SVN r47224 Linux 2.6.13 x86 ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-11 00:53 Message: Logged In: YES user_id=1344176 Originator: YES Adding those lines does indeed suppress the exception. I'm not convinced it eliminates the problem, though, since adding "t = 2" after "for t in range(1,6):" in test_main_inner() will still cause test2() to raise KeyError() (with the same traceback as before), even with your patch. I've tried this same approach for all tests (0-5) and test2() is the only one to exhibit this behaviour. That said, I'm very happy to have test_logging not fail under "regrtest -R" anymore : ) I would apply your solution to both trunk/ and release25-maint/, if only to keep the number of buildbot false alarms to a minimum. Thanks, Vinay! ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2007-03-10 19:58 Message: Logged In: YES user_id=308438 Originator: NO Thanks for the info. test2() is a little sensitive because it makes assumptions about the state of handlers attached to the root logger. test4() and test5() do some slightly dodgy manipulation of the internal handler list maintained by the module. I played around with the assumption that test5() is the culprit (as it's the last test run), and found that adding the lines hdlr = logging.getLogger().handlers[0] logging.getLogger().handlers.remove(hdlr) in test5(), just after the line os.remove(fn) causes the error not to occur, and the test passes successfully. Please try this on your system and re-run the tests, and if you can confirm that this change works for you, I can check it in. (I propose to only check it into trunk, and not into release25-maint or other branches - what do you think?) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-10 15:36 Message: Logged In: YES user_id=1344176 Originator: YES Vinay: I've been able to gather a little more information. The problem occurs during the second run-through of the test suite; that is, it runs once, then "-R ::" kicks in and starts to run the test again, which is when the exception occurs. From what I can tell from poking around test2(), something is removing the "sh" handler from logging._handlers prematurely (its id() matches that displayed in the KeyError traceback). More poking around: "-R ::" doesn't really enter into it. Modifying test_main_inner() to run test2() more than once (in isolation or after other tests) will trigger this, too. On the second run, sh.close() raises a KeyError. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2007-03-10 12:25 Message: Logged In: YES user_id=308438 Originator: NO Hi Collin, I'm sorry to be so slow on this. For various reasons, I don't have a debug build of Python 2.5 :-(, without which the -R option is not available to me. Also, of course, it's not a bug in logging itself, more in the test case. If you have time, I would appreciate some help on this: I would temporarily modify test_logging to print out the StreamHandlers created either explicity in test_logging.py or via the calls to fileConfig(), to see which StreamHandler is not being released. TIA... ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-09 15:42 Message: Logged In: YES user_id=1344176 Originator: YES Still present as of 54248. Vinay, do you have any insights on this? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 00:03 Message: Logged In: YES user_id=1344176 This issue is still present as of r51654. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516995&group_id=5470 From noreply at sourceforge.net Sun Mar 11 16:29:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 08:29:15 -0700 Subject: [ python-Bugs-1528074 ] difflib.SequenceMatcher.find_longest_match() wrong result Message-ID: Bugs item #1528074, was opened at 2006-07-25 03:59 Message generated for change (Comment added) made by rtvd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528074&group_id=5470 Please note that this 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 Private: No Submitted By: John Machin (sjmachin) Assigned to: Tim Peters (tim_one) Summary: difflib.SequenceMatcher.find_longest_match() wrong result Initial Comment: A short example script is attached. Two strings, each 500 bytes long. Longest match is the first 32 bytes of each string. Result produced is a 10-byte match later in the string. If one byte is chopped off the end of each string (len now 499 each), the correct result is produced. Other observations, none of which may be relevant: 1. Problem may be in the heuristic for "popular" elements in the __chain_b method. In this particular example, the character '0' (which has frequency of 6 in the "b" string) is not "popular" with a len of 500 but is "popular" with a len of 499. 2. '0' is the last byte of the correct longest match. 3. The correct longest match is at the start of the each of the strings. 4. Disabling the "popular" heuristic (like below) appears to make the problem go away: if 0: # if n >= 200 and len(indices) * 100 > n: populardict[elt] = 1 del indices[:] else: indices.append(i) 5. The callable self.isbpopular is created but appears to be unused. 6. The determination of "popular" doesn't accord with the comments, which say 1%. However with len==500, takes 6 to be popular. ---------------------------------------------------------------------- Comment By: Denys Rtveliashvili (rtvd) Date: 2007-03-11 18:29 Message: Logged In: YES user_id=1416496 Originator: NO I have sent a testcase for this bug into the SourceForge. The ID is #1678339. Also I have submitted a fix for this bug (ID #1678345), but the fix reduces the performance significantly. ---------------------------------------------------------------------- Comment By: Denys Rtveliashvili (rtvd) Date: 2007-03-10 20:24 Message: Logged In: YES user_id=1416496 Originator: NO The quick test for this bug is: for i in xrange(190, 200): text1 = "a" + "b"*i text2 = "b"*i + "c" m = difflib.SequenceMatcher(None, text1, text2) (aptr,bptr,l) = m.find_longest_match(0, len(text1), 0, len(text2)) print "i:", i, " l:", l, " aptr:", aptr, " bptr:", bptr assert l == i The assertion will fail when i==199 (the length of the texts will be 200). And yes, the bug is clearly "populardict"-related. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528074&group_id=5470 From noreply at sourceforge.net Sun Mar 11 16:40:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 08:40:13 -0700 Subject: [ python-Bugs-1675967 ] Python2.5 can't read a (complex) pickle build by python2.4 Message-ID: Bugs item #1675967, was opened at 2007-03-07 19:16 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675967&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michael Vogt (mvo) Assigned to: Nobody/Anonymous (nobody) Summary: Python2.5 can't read a (complex) pickle build by python2.4 Initial Comment: Part of gnome-app-install in ubuntu is a pickle data structure cache. If I create this pickle with python 2.4 and read it later with 2.5. I get the following error: $ python2.5 -c 'import pickle; pickle.load(open("/var/cache/app-install/menu.p"))' /usr/lib/python2.5/pickle.py:1124: DeprecationWarning: The sre module is deprecated, please import re. __import__(module) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/pickle.py", line 1370, in load return Unpickler(file).load() File "/usr/lib/python2.5/pickle.py", line 858, in load dispatch[key](self) File "/usr/lib/python2.5/pickle.py", line 1090, in load_global klass = self.find_class(module, name) File "/usr/lib/python2.5/pickle.py", line 1126, in find_class klass = getattr(mod, name) AttributeError: 'module' object has no attribute '_compile' With: $ python2.4 -c 'import pickle; pickle.load(open("/var/cache/app-install/menu.p"))' egon at top ~ $ It loads just fine. The test pickle can be found here: http://people.ubuntu.com/~mvo/gnome-app-install/menu.p.gz Cheers, Michael ---------------------------------------------------------------------- >Comment By: ?iga Seilnacht (zseil) Date: 2007-03-11 16:40 Message: Logged In: YES user_id=1326842 Originator: NO Attaching the patch with a test here. Unpickling old patterns with this patch works, but it still issues a DeprecationWarning. The test itself is a bit obscure, but the other option is to add a binary file to the test suite. File Added: sre_pickle_compatibility.diff ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-07 20:43 Message: Logged In: YES user_id=1326842 Originator: NO This happens because of SRE_Pattern objects in jour pickle. The sre module was renamed to re in Python 2.5, but the old pickles still expect the _compile function in sre module. I posted the patch here: http://freeweb.siol.net/chollus/ Could you try if it fixes the problem for you and in that case, attach it to this report? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675967&group_id=5470 From noreply at sourceforge.net Sun Mar 11 18:16:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 10:16:18 -0700 Subject: [ python-Bugs-1678380 ] 0.0 and -0.0 identified, with surprising results Message-ID: Bugs item #1678380, was opened at 2007-03-11 17:16 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=1678380&group_id=5470 Please note that this 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 Private: No Submitted By: Mark Dickinson (marketdickinson) Assigned to: Nobody/Anonymous (nobody) Summary: 0.0 and -0.0 identified, with surprising results Initial Comment: The identification of -0.0 and 0.0 in scripts leads to some surprising results. In particular, code that behaves one way in the interpreter can behave differently in a script. For example: Python 2.6a0 (trunk:54183M, Mar 6 2007, 20:16:00) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from math import atan2; >>> x = -0. >>> y = 0. >>> print atan2(y, -1.) 3.14159265359 But: >>> exec("from math import atan2; x = -0.; y = 0.; print atan2(y, -1.)") -3.14159265359 A simpler example: >>> x, y = -0., 0. >>> x, y (-0.0, -0.0) >>> id(x) == id(y) True But: >>> x = -0. >>> y = 0. >>> x, y (-0.0, 0.0) This occurs both on SuSE Linux 9.3/i686 and on OS X 10.4.8/PowerPC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678380&group_id=5470 From noreply at sourceforge.net Sun Mar 11 19:07:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 11:07:01 -0700 Subject: [ python-Bugs-1678411 ] StringIO / cStringIO inconsistency with unicode Message-ID: Bugs item #1678411, was opened at 2007-03-11 18:07 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=1678411&group_id=5470 Please note that this 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 Private: No Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: StringIO / cStringIO inconsistency with unicode Initial Comment: When trying to write unicode strings into a StringIO.StringIO() or a cStringIO.StringIO() file, different things occur. (This causes a failing test in the "mako" project if cStringIO is not available.) Compare the following with StringIO or with cStringIO: f = StringIO() f.write("\xC0") f.write(u"hello") print f.getvalue() With cStringIO, unicode strings are immediately encoded as ascii and the getvalue() returns '\xC0hello'. With StringIO, on the other hand, the getvalue() crashes in a ''.join() trying to convert 'xC0' to unicode. Normal file() objects follow the same behavior as cStringIO, so my guess is that StringIO.py is wrong here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678411&group_id=5470 From noreply at sourceforge.net Sun Mar 11 19:31:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 11:31:13 -0700 Subject: [ python-Bugs-1678411 ] StringIO / cStringIO inconsistency with unicode Message-ID: Bugs item #1678411, was opened at 2007-03-11 19:07 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678411&group_id=5470 Please note that this 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 Private: No Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: StringIO / cStringIO inconsistency with unicode Initial Comment: When trying to write unicode strings into a StringIO.StringIO() or a cStringIO.StringIO() file, different things occur. (This causes a failing test in the "mako" project if cStringIO is not available.) Compare the following with StringIO or with cStringIO: f = StringIO() f.write("\xC0") f.write(u"hello") print f.getvalue() With cStringIO, unicode strings are immediately encoded as ascii and the getvalue() returns '\xC0hello'. With StringIO, on the other hand, the getvalue() crashes in a ''.join() trying to convert 'xC0' to unicode. Normal file() objects follow the same behavior as cStringIO, so my guess is that StringIO.py is wrong here. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-11 19:31 Message: Logged In: YES user_id=21627 Originator: NO It's intentional that they behave differently. StringIO supports Unicode strings, cStringIO doesn't. This means that you can build up a large Unicode string with StringIO, but not with cStringIO. What should happen when you mix them is debatable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678411&group_id=5470 From noreply at sourceforge.net Sun Mar 11 19:35:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 11:35:33 -0700 Subject: [ python-Bugs-1678380 ] 0.0 and -0.0 identified, with surprising results Message-ID: Bugs item #1678380, was opened at 2007-03-11 18:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678380&group_id=5470 Please note that this 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: Pending >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Mark Dickinson (marketdickinson) Assigned to: Nobody/Anonymous (nobody) Summary: 0.0 and -0.0 identified, with surprising results Initial Comment: The identification of -0.0 and 0.0 in scripts leads to some surprising results. In particular, code that behaves one way in the interpreter can behave differently in a script. For example: Python 2.6a0 (trunk:54183M, Mar 6 2007, 20:16:00) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from math import atan2; >>> x = -0. >>> y = 0. >>> print atan2(y, -1.) 3.14159265359 But: >>> exec("from math import atan2; x = -0.; y = 0.; print atan2(y, -1.)") -3.14159265359 A simpler example: >>> x, y = -0., 0. >>> x, y (-0.0, -0.0) >>> id(x) == id(y) True But: >>> x = -0. >>> y = 0. >>> x, y (-0.0, 0.0) This occurs both on SuSE Linux 9.3/i686 and on OS X 10.4.8/PowerPC. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-11 19:35 Message: Logged In: YES user_id=21627 Originator: NO This is not a bug, at least not one that will be fixed. Details of the floating-point can vary across platforms, and they may behave in suprising ways in various contexts. Users shouldn't rely on Python differentiating between -0 and +0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678380&group_id=5470 From noreply at sourceforge.net Sun Mar 11 19:39:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 11:39:25 -0700 Subject: [ python-Bugs-1516995 ] test_logging fails with reference count-checking enabled Message-ID: Bugs item #1516995, was opened at 2006-07-04 14:34 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516995&group_id=5470 Please note that this 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.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Vinay Sajip (vsajip) Summary: test_logging fails with reference count-checking enabled Initial Comment: When running from the following, test_logging fails: ./python Lib/test/regrtest.py -R :: test_logging. Here's the traceback: test test_logging crashed -- : Traceback (most recent call last): File "Lib/test/regrtest.py", line 554, in runtest_inner dash_R(the_module, test, indirect_test, huntrleaks) File "Lib/test/regrtest.py", line 673, in dash_R run_the_test() File "Lib/test/regrtest.py", line 660, in run_the_test indirect_test() File "/home/collin/src/python/Lib/test/test_support.py", line 299, in inner return func(*args, **kwds) File "/home/collin/src/python/Lib/test/test_logging.py", line 677, in test_main test_main_inner() File "/home/collin/src/python/Lib/test/test_logging.py", line 640, in test_main_inner globals()['test%d' % t]() File "/home/collin/src/python/Lib/test/test_logging.py", line 347, in test2 sh.close() File "/home/collin/src/python/Lib/logging/__init__.py", line 687, in close del _handlers[self] KeyError: This problem does not occur when run without reference count-checking. System info: Python SVN r47224 Linux 2.6.13 x86 ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2007-03-11 18:39 Message: Logged In: YES user_id=308438 Originator: NO Fix checked into trunk and release25-maint, so closing this item. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-11 05:53 Message: Logged In: YES user_id=1344176 Originator: YES Adding those lines does indeed suppress the exception. I'm not convinced it eliminates the problem, though, since adding "t = 2" after "for t in range(1,6):" in test_main_inner() will still cause test2() to raise KeyError() (with the same traceback as before), even with your patch. I've tried this same approach for all tests (0-5) and test2() is the only one to exhibit this behaviour. That said, I'm very happy to have test_logging not fail under "regrtest -R" anymore : ) I would apply your solution to both trunk/ and release25-maint/, if only to keep the number of buildbot false alarms to a minimum. Thanks, Vinay! ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2007-03-11 00:58 Message: Logged In: YES user_id=308438 Originator: NO Thanks for the info. test2() is a little sensitive because it makes assumptions about the state of handlers attached to the root logger. test4() and test5() do some slightly dodgy manipulation of the internal handler list maintained by the module. I played around with the assumption that test5() is the culprit (as it's the last test run), and found that adding the lines hdlr = logging.getLogger().handlers[0] logging.getLogger().handlers.remove(hdlr) in test5(), just after the line os.remove(fn) causes the error not to occur, and the test passes successfully. Please try this on your system and re-run the tests, and if you can confirm that this change works for you, I can check it in. (I propose to only check it into trunk, and not into release25-maint or other branches - what do you think?) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-10 20:36 Message: Logged In: YES user_id=1344176 Originator: YES Vinay: I've been able to gather a little more information. The problem occurs during the second run-through of the test suite; that is, it runs once, then "-R ::" kicks in and starts to run the test again, which is when the exception occurs. From what I can tell from poking around test2(), something is removing the "sh" handler from logging._handlers prematurely (its id() matches that displayed in the KeyError traceback). More poking around: "-R ::" doesn't really enter into it. Modifying test_main_inner() to run test2() more than once (in isolation or after other tests) will trigger this, too. On the second run, sh.close() raises a KeyError. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2007-03-10 17:25 Message: Logged In: YES user_id=308438 Originator: NO Hi Collin, I'm sorry to be so slow on this. For various reasons, I don't have a debug build of Python 2.5 :-(, without which the -R option is not available to me. Also, of course, it's not a bug in logging itself, more in the test case. If you have time, I would appreciate some help on this: I would temporarily modify test_logging to print out the StreamHandlers created either explicity in test_logging.py or via the calls to fileConfig(), to see which StreamHandler is not being released. TIA... ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-09 20:42 Message: Logged In: YES user_id=1344176 Originator: YES Still present as of 54248. Vinay, do you have any insights on this? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 04:03 Message: Logged In: YES user_id=1344176 This issue is still present as of r51654. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516995&group_id=5470 From noreply at sourceforge.net Sun Mar 11 19:45:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 11:45:04 -0700 Subject: [ python-Bugs-780354 ] socket.makefile() isn't compatible with marshal/cPickle/etc Message-ID: Bugs item #780354, was opened at 2003-07-30 12:02 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780354&group_id=5470 Please note that this 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 Private: No Submitted By: David M. Grimes (dmgrime) >Assigned to: Facundo Batista (facundobatista) Summary: socket.makefile() isn't compatible with marshal/cPickle/etc Initial Comment: Even on platforms where the underlying C libraries and associated code in socketmodule.c support it, socket object's .makefile() method no longer return "real" file objects. This breaks support for cPickle, marshal, and any other C modules which expect a file object as an argument. The change initially appears in socket.py v1.36 - the changelog entry states: """ The socket module now always uses the _socketobject wrapper class, even on platforms which have dup(2). The makefile() method is built directly on top of the socket without duplicating the file descriptor, allowing timeouts to work properly. Includes a new test case (urllibnet) which requires the network resource. Closes bug 707074. """ I'm not sure of the implication WRT timeouts, but the patch is very small - quite obviously removing the platform check which prevented the redefinition of the symbol socket in the exports of socket.py. It now is always the _socketobject class, and not the underlying _socket.socket type (when it is known the platform supports all functionality in _socket). For now, I can workaround (since I don't need the timeout semantics) by using _socket.socket() directly (I'm on a Linux platform), but I wondered if this is something which can/should be addressed differently? ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2007-03-11 13:45 Message: Logged In: YES user_id=44345 Originator: NO I'm not going to get to this. It may well be obsolete now anyway. Facundo, I'm assigning to you simply because you are diving into the timeout code right now. Maybe you can make a more informed decision. --Skip ---------------------------------------------------------------------- Comment By: David M. Grimes (dmgrime) Date: 2003-08-04 09:34 Message: Logged In: YES user_id=699265 Thanks Skip. I see that the ripple effect here is enormous (not surprising, given that socket is used by many standard modules). As for #3 - I understand you can use marshal.dumps() and then sock.sendall() to achieve the write side of a socket-based marshalling transaction, but for a long- lived connection, marshal.load() on the .makefile()'d file of the read-side provided a very nice message-boundary mechanism, i.e. - marshal was the "protocol" on the wire... Obviously (I've already done this in my application) I can just use a thin length header on the wire, but it was just very nice that marshal accomplished this by itself. I can also (since my platform scope is known, controlled, and limited) create a socket.py local to my application which is simply (I don't use getfqdn()): from _socket import * And leave everything else as-is. Again, I appreciate the attention and effort - I think the ramifications of eliminating the "native C" implementation which previously backed .makefile() (where supported) are more than just the impact on marshal - I see potential performance loss for things which rely on it. In any event, generic object support for marshal.load() and .dump() would be great! Thanks again, Dave. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-04 08:53 Message: Logged In: YES user_id=44345 The original socket.makefile dup()s the socket to create a new file descriptor. If you have a timeout set on the original socket the new file descriptor loses this property. This was a big problem for the various modules which sit atop socket (httplib, etc) because they generally all just call s.makefile() and then treat the connected socket as a file. These are precisely the modules/classes which benefit most from socket timeouts. Note also that the current Unix implementation is what Windows (and any other platforms without a dup() system call) use to emulate makefile(). In the long run, I see a few other possibilities. Note that I haven't considered the first two in any detail. I'm in the midst of working on the third. 1. Add timeout functionality to the various higher-level modules such as httplib. Once they call s.makefile() they could propagate their current timeout to the new file object. Of course, this means file objects need to be able to timeout (not obvious that this is generally possible). 2. Store timeout information in the socket, so that if it's dup()'d it propagates the timeout to the new descriptor. Again, it's not obvious that this is possible. 3. Extend more general object support to marshal. I am working on this and hope to have something available for review later this week. As Martin indicated, it's not unreasonable to expect people wanting to marshal data to non-file objects to first pass them through marshal.dumps(). You can't, for example, marshal data to StringIO objects directly. ---------------------------------------------------------------------- Comment By: David M. Grimes (dmgrime) Date: 2003-08-04 07:37 Message: Logged In: YES user_id=699265 I know the wrapper has been there for a long time - some platforms don't support the "native" underlying FILE implementation, but many (most) platforms did. What was the problem that necessitated the change? I'd be more than willing to spend some time looking into alternative solutions which keep the optimized implementation where possible. Can you provide me with some history of the motivations for the current solution? Thanks! ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-01 15:52 Message: Logged In: YES user_id=21627 I don't know of any other approach to solve the problem. Also notice that the wrapper object has existed for a long time already, on some systems. ---------------------------------------------------------------------- Comment By: David M. Grimes (dmgrime) Date: 2003-08-01 14:31 Message: Logged In: YES user_id=699265 It is clear that something which used to work no longer works, and I'm just wondering if the breakage is necessary. I'm not sure what all was involved with respect to timeouts and why the makefile() implementation had to change. I guess I see 3 problems: 1) Previously functional code breaks. While marshal is not "general purpose" in the sense it can't deal with instances, etc. it is still very useful and for data which doesn't contain many redundant references (where cPickle reduces them) it is the most efficient way to serialize and unserialize "native" python types. 2) The performance of everything which uses the results of socket.makefile() now suffers the cost of a pure-python implementation where it had perviously been optimized as a C implementation on platforms which supported it (most). 3) Any other 3rd party C extensions which use the PyFile_Check (and would previously have worked) break. Is there another way to solve the timeout problem? Breaking something which has worked since 1.5 somehow feels wrong to me. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-01 14:09 Message: Logged In: YES user_id=21627 I don't think anymore that marshal has a problem. There is nothing wrong with it breaking when operating on a socket; marshal is not for general application use, anyway. Anybody who wants to transmit marshalled data over a socket can still dump them into a string first. So I propose to fix this aspect by documenting this intended limitation. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 09:52 Message: Logged In: YES user_id=44345 Agreed, marshal has problems. It's problems are a bit deeper than the technique in cPickle can solve, however. It seems to me that the WFILE struct is a bad hack. It should contain a union with three elements, one is the regular FILE * stuff, one is the current write-to-string stuff, and a third is a "generic object which has a write method". I'll see if I can whip something up and pass along to Martin for review. ---------------------------------------------------------------------- Comment By: David M. Grimes (dmgrime) Date: 2003-08-01 09:27 Message: Logged In: YES user_id=699265 Skip -- I stand corrected (for cPickle, anyway) - but I imagine there is a performance degredation over the "old" way of doing things - if I get a chance, I'll test that. The problem does still exist at least in marshal (.load and .dump only accept a "real" file object). I did a grep for PyFile_Check in the source tree prior to posting the bug report, and was a little over zealous to include cPickle in the subject. There are other places in the source ( and possibly in 3rd party extensions) which use PyFile_Check, and I haven't had a change to analyze those yet. In any case, marshal doesn't work - in your test, if you change the cPickle to marshal, you'll get: Traceback (most recent call last): File "x.py", line 10, in ? marshal.dump("Hello, world", f) TypeError: marshal.dump() 2nd arg must be file Again, I'm not sure of the impact other places where PyFile_Check is used, and I don't know the performance loss in cPickle (as compared to the "real" file implementation in pre-2.3 socket.makefile()) Let me know if there is anything I can do to help debug/fix! ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 09:18 Message: Logged In: YES user_id=44345 I modified the Demo/sockets/unixclient.py script to the following: # Echo client demo using Unix sockets # Piet van Oostrum from socket import * FILE = 'blabla' s = socket(AF_UNIX, SOCK_STREAM) s.connect(FILE) import cPickle f = s.makefile("wb") cPickle.dump("Hello, world", f) f.close() #s.send('Hello, world') data = s.recv(1024) s.close() print 'Received', `data` It seemed to work fine when connected to the corresponding unixserver.py script. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 09:11 Message: Logged In: YES user_id=44345 Looking at the code in cPickle.c it appears that as long as the object being written to has a 'write' method it should do the right thing. Can you provide a simple test case which fails? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-01 02:14 Message: Logged In: YES user_id=21627 See the bug that this patch closes; I doubt there is an alternative approach. Instead, I think the C modules that expect file objects need to be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780354&group_id=5470 From noreply at sourceforge.net Sun Mar 11 19:45:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 11:45:53 -0700 Subject: [ python-Bugs-780354 ] socket.makefile() isn't compatible with marshal/cPickle/etc Message-ID: Bugs item #780354, was opened at 2003-07-30 12:02 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780354&group_id=5470 Please note that this 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 Private: No Submitted By: David M. Grimes (dmgrime) >Assigned to: Nobody/Anonymous (nobody) Summary: socket.makefile() isn't compatible with marshal/cPickle/etc Initial Comment: Even on platforms where the underlying C libraries and associated code in socketmodule.c support it, socket object's .makefile() method no longer return "real" file objects. This breaks support for cPickle, marshal, and any other C modules which expect a file object as an argument. The change initially appears in socket.py v1.36 - the changelog entry states: """ The socket module now always uses the _socketobject wrapper class, even on platforms which have dup(2). The makefile() method is built directly on top of the socket without duplicating the file descriptor, allowing timeouts to work properly. Includes a new test case (urllibnet) which requires the network resource. Closes bug 707074. """ I'm not sure of the implication WRT timeouts, but the patch is very small - quite obviously removing the platform check which prevented the redefinition of the symbol socket in the exports of socket.py. It now is always the _socketobject class, and not the underlying _socket.socket type (when it is known the platform supports all functionality in _socket). For now, I can workaround (since I don't need the timeout semantics) by using _socket.socket() directly (I'm on a Linux platform), but I wondered if this is something which can/should be addressed differently? ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2007-03-11 13:45 Message: Logged In: YES user_id=44345 Originator: NO Crap. Wrong socket.makefile bug report. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-03-11 13:45 Message: Logged In: YES user_id=44345 Originator: NO I'm not going to get to this. It may well be obsolete now anyway. Facundo, I'm assigning to you simply because you are diving into the timeout code right now. Maybe you can make a more informed decision. --Skip ---------------------------------------------------------------------- Comment By: David M. Grimes (dmgrime) Date: 2003-08-04 09:34 Message: Logged In: YES user_id=699265 Thanks Skip. I see that the ripple effect here is enormous (not surprising, given that socket is used by many standard modules). As for #3 - I understand you can use marshal.dumps() and then sock.sendall() to achieve the write side of a socket-based marshalling transaction, but for a long- lived connection, marshal.load() on the .makefile()'d file of the read-side provided a very nice message-boundary mechanism, i.e. - marshal was the "protocol" on the wire... Obviously (I've already done this in my application) I can just use a thin length header on the wire, but it was just very nice that marshal accomplished this by itself. I can also (since my platform scope is known, controlled, and limited) create a socket.py local to my application which is simply (I don't use getfqdn()): from _socket import * And leave everything else as-is. Again, I appreciate the attention and effort - I think the ramifications of eliminating the "native C" implementation which previously backed .makefile() (where supported) are more than just the impact on marshal - I see potential performance loss for things which rely on it. In any event, generic object support for marshal.load() and .dump() would be great! Thanks again, Dave. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-04 08:53 Message: Logged In: YES user_id=44345 The original socket.makefile dup()s the socket to create a new file descriptor. If you have a timeout set on the original socket the new file descriptor loses this property. This was a big problem for the various modules which sit atop socket (httplib, etc) because they generally all just call s.makefile() and then treat the connected socket as a file. These are precisely the modules/classes which benefit most from socket timeouts. Note also that the current Unix implementation is what Windows (and any other platforms without a dup() system call) use to emulate makefile(). In the long run, I see a few other possibilities. Note that I haven't considered the first two in any detail. I'm in the midst of working on the third. 1. Add timeout functionality to the various higher-level modules such as httplib. Once they call s.makefile() they could propagate their current timeout to the new file object. Of course, this means file objects need to be able to timeout (not obvious that this is generally possible). 2. Store timeout information in the socket, so that if it's dup()'d it propagates the timeout to the new descriptor. Again, it's not obvious that this is possible. 3. Extend more general object support to marshal. I am working on this and hope to have something available for review later this week. As Martin indicated, it's not unreasonable to expect people wanting to marshal data to non-file objects to first pass them through marshal.dumps(). You can't, for example, marshal data to StringIO objects directly. ---------------------------------------------------------------------- Comment By: David M. Grimes (dmgrime) Date: 2003-08-04 07:37 Message: Logged In: YES user_id=699265 I know the wrapper has been there for a long time - some platforms don't support the "native" underlying FILE implementation, but many (most) platforms did. What was the problem that necessitated the change? I'd be more than willing to spend some time looking into alternative solutions which keep the optimized implementation where possible. Can you provide me with some history of the motivations for the current solution? Thanks! ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-01 15:52 Message: Logged In: YES user_id=21627 I don't know of any other approach to solve the problem. Also notice that the wrapper object has existed for a long time already, on some systems. ---------------------------------------------------------------------- Comment By: David M. Grimes (dmgrime) Date: 2003-08-01 14:31 Message: Logged In: YES user_id=699265 It is clear that something which used to work no longer works, and I'm just wondering if the breakage is necessary. I'm not sure what all was involved with respect to timeouts and why the makefile() implementation had to change. I guess I see 3 problems: 1) Previously functional code breaks. While marshal is not "general purpose" in the sense it can't deal with instances, etc. it is still very useful and for data which doesn't contain many redundant references (where cPickle reduces them) it is the most efficient way to serialize and unserialize "native" python types. 2) The performance of everything which uses the results of socket.makefile() now suffers the cost of a pure-python implementation where it had perviously been optimized as a C implementation on platforms which supported it (most). 3) Any other 3rd party C extensions which use the PyFile_Check (and would previously have worked) break. Is there another way to solve the timeout problem? Breaking something which has worked since 1.5 somehow feels wrong to me. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-01 14:09 Message: Logged In: YES user_id=21627 I don't think anymore that marshal has a problem. There is nothing wrong with it breaking when operating on a socket; marshal is not for general application use, anyway. Anybody who wants to transmit marshalled data over a socket can still dump them into a string first. So I propose to fix this aspect by documenting this intended limitation. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 09:52 Message: Logged In: YES user_id=44345 Agreed, marshal has problems. It's problems are a bit deeper than the technique in cPickle can solve, however. It seems to me that the WFILE struct is a bad hack. It should contain a union with three elements, one is the regular FILE * stuff, one is the current write-to-string stuff, and a third is a "generic object which has a write method". I'll see if I can whip something up and pass along to Martin for review. ---------------------------------------------------------------------- Comment By: David M. Grimes (dmgrime) Date: 2003-08-01 09:27 Message: Logged In: YES user_id=699265 Skip -- I stand corrected (for cPickle, anyway) - but I imagine there is a performance degredation over the "old" way of doing things - if I get a chance, I'll test that. The problem does still exist at least in marshal (.load and .dump only accept a "real" file object). I did a grep for PyFile_Check in the source tree prior to posting the bug report, and was a little over zealous to include cPickle in the subject. There are other places in the source ( and possibly in 3rd party extensions) which use PyFile_Check, and I haven't had a change to analyze those yet. In any case, marshal doesn't work - in your test, if you change the cPickle to marshal, you'll get: Traceback (most recent call last): File "x.py", line 10, in ? marshal.dump("Hello, world", f) TypeError: marshal.dump() 2nd arg must be file Again, I'm not sure of the impact other places where PyFile_Check is used, and I don't know the performance loss in cPickle (as compared to the "real" file implementation in pre-2.3 socket.makefile()) Let me know if there is anything I can do to help debug/fix! ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 09:18 Message: Logged In: YES user_id=44345 I modified the Demo/sockets/unixclient.py script to the following: # Echo client demo using Unix sockets # Piet van Oostrum from socket import * FILE = 'blabla' s = socket(AF_UNIX, SOCK_STREAM) s.connect(FILE) import cPickle f = s.makefile("wb") cPickle.dump("Hello, world", f) f.close() #s.send('Hello, world') data = s.recv(1024) s.close() print 'Received', `data` It seemed to work fine when connected to the corresponding unixserver.py script. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 09:11 Message: Logged In: YES user_id=44345 Looking at the code in cPickle.c it appears that as long as the object being written to has a 'write' method it should do the right thing. Can you provide a simple test case which fails? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-01 02:14 Message: Logged In: YES user_id=21627 See the bug that this patch closes; I doubt there is an alternative approach. Instead, I think the C modules that expect file objects need to be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780354&group_id=5470 From noreply at sourceforge.net Sun Mar 11 19:46:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 11:46:43 -0700 Subject: [ python-Bugs-882297 ] socket's makefile file object doesn't work with timeouts. Message-ID: Bugs item #882297, was opened at 2004-01-22 12:36 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=882297&group_id=5470 Please note that this 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 Private: No Submitted By: Jeremy Fincher (jemfinch) >Assigned to: Facundo Batista (facundobatista) Summary: socket's makefile file object doesn't work with timeouts. Initial Comment: Ok, here's what I did: >>> import socket >>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) >>> s.bind(('', 9009)) >>> s.listen(5) >>> s.accept() Now, I opened a second Python interpreter in which I typed this: >>> import socket >>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) >>> s.connect(('localhost', 9009)) In the first interpreter I did this: >>> s.accept() (, ('127.0.0.1', 33059)) >>> s1 = _[0] >>> s1.settimeout(3) >>> fd = s1.makefile() Then I tested that the timeout worked correctly. Still in the first interpreter: >>> fd.readline() Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/socket.py", line 338, in readline data = self._sock.recv(self._rbufsize) socket.timeout: timed out >>> fd.readline() Now, while that was blocking, I did this in the second interpreter: >>> s.send('foo') 3 Which caused this in the first interpreter (as expected, since I didn't send a newline): Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/socket.py", line 338, in readline data = self._sock.recv(self._rbufsize) socket.timeout: timed out >>> fd.readline() While that was blocking, I did this in the second interpreter: >>> s.send('bar\n') 4 Finally sending a newline. But lo and behold! In the first interpreter I got this: >>> fd.readline() 'bar\n' Alas, my 'foo' has been lost! Anyway, the documentation does explicitly state that the socket should be in blocking mode, *implying* that it does no buffering, but it doesn't say anything about timeouts. Ideally, the file object would buffer enough data until the readline could return meaningfully, but failing that, the documentation should probably be updated to mention that timeouts shouldn't be used with readline on the returned file object. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2007-03-11 13:46 Message: Logged In: YES user_id=44345 Originator: NO Okay, this is the socket.makefile/timeout bug report. Sorry about the previous blip. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-17 06:10 Message: Logged In: YES user_id=1188172 If this is a bug, it hasn't been fixed. I reproduced it here. Assigning to Skip since he worked on "makefile" as it seems. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-02-01 13:38 Message: Logged In: YES user_id=261020 I believe this was fixed in socket.py in rev 32056, closing bug 707074. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=882297&group_id=5470 From noreply at sourceforge.net Sun Mar 11 20:21:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 12:21:11 -0700 Subject: [ python-Bugs-1678380 ] 0.0 and -0.0 identified, with surprising results Message-ID: Bugs item #1678380, was opened at 2007-03-11 17:16 Message generated for change (Comment added) made by marketdickinson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678380&group_id=5470 Please note that this 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: Wont Fix Priority: 5 Private: No Submitted By: Mark Dickinson (marketdickinson) Assigned to: Nobody/Anonymous (nobody) Summary: 0.0 and -0.0 identified, with surprising results Initial Comment: The identification of -0.0 and 0.0 in scripts leads to some surprising results. In particular, code that behaves one way in the interpreter can behave differently in a script. For example: Python 2.6a0 (trunk:54183M, Mar 6 2007, 20:16:00) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from math import atan2; >>> x = -0. >>> y = 0. >>> print atan2(y, -1.) 3.14159265359 But: >>> exec("from math import atan2; x = -0.; y = 0.; print atan2(y, -1.)") -3.14159265359 A simpler example: >>> x, y = -0., 0. >>> x, y (-0.0, -0.0) >>> id(x) == id(y) True But: >>> x = -0. >>> y = 0. >>> x, y (-0.0, 0.0) This occurs both on SuSE Linux 9.3/i686 and on OS X 10.4.8/PowerPC. ---------------------------------------------------------------------- >Comment By: Mark Dickinson (marketdickinson) Date: 2007-03-11 19:21 Message: Logged In: YES user_id=703403 Originator: YES May I beg for reconsideration. Is the following really considered acceptable? >>> x = -0.; atan2(0., -1) -3.1415926535897931 >>> x = -(0.); atan2(0., -1) 3.1415926535897931 >>> atan2(0., -1) 3.1415926535897931 A single x = -0. at the start of a script can have side effects several hundred lines later, even when the variable x is never referred to again. I guess the advice should be: "To avoid surprises, -0. should never appear in any script." ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-11 18:35 Message: Logged In: YES user_id=21627 Originator: NO This is not a bug, at least not one that will be fixed. Details of the floating-point can vary across platforms, and they may behave in suprising ways in various contexts. Users shouldn't rely on Python differentiating between -0 and +0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678380&group_id=5470 From noreply at sourceforge.net Sun Mar 11 21:10:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 13:10:17 -0700 Subject: [ python-Bugs-1678380 ] 0.0 and -0.0 identified, with surprising results Message-ID: Bugs item #1678380, was opened at 2007-03-11 14:16 Message generated for change (Comment added) made by gagenellina You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678380&group_id=5470 Please note that this 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: Wont Fix Priority: 5 Private: No Submitted By: Mark Dickinson (marketdickinson) Assigned to: Nobody/Anonymous (nobody) Summary: 0.0 and -0.0 identified, with surprising results Initial Comment: The identification of -0.0 and 0.0 in scripts leads to some surprising results. In particular, code that behaves one way in the interpreter can behave differently in a script. For example: Python 2.6a0 (trunk:54183M, Mar 6 2007, 20:16:00) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from math import atan2; >>> x = -0. >>> y = 0. >>> print atan2(y, -1.) 3.14159265359 But: >>> exec("from math import atan2; x = -0.; y = 0.; print atan2(y, -1.)") -3.14159265359 A simpler example: >>> x, y = -0., 0. >>> x, y (-0.0, -0.0) >>> id(x) == id(y) True But: >>> x = -0. >>> y = 0. >>> x, y (-0.0, 0.0) This occurs both on SuSE Linux 9.3/i686 and on OS X 10.4.8/PowerPC. ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-03-11 17:10 Message: Logged In: YES user_id=479790 Originator: NO It appears to be a problem in the way compile.c handles literals. See http://mail.python.org/pipermail/python-list/2007-March/430302.html ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-03-11 16:21 Message: Logged In: YES user_id=703403 Originator: YES May I beg for reconsideration. Is the following really considered acceptable? >>> x = -0.; atan2(0., -1) -3.1415926535897931 >>> x = -(0.); atan2(0., -1) 3.1415926535897931 >>> atan2(0., -1) 3.1415926535897931 A single x = -0. at the start of a script can have side effects several hundred lines later, even when the variable x is never referred to again. I guess the advice should be: "To avoid surprises, -0. should never appear in any script." ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-11 15:35 Message: Logged In: YES user_id=21627 Originator: NO This is not a bug, at least not one that will be fixed. Details of the floating-point can vary across platforms, and they may behave in suprising ways in various contexts. Users shouldn't rely on Python differentiating between -0 and +0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678380&group_id=5470 From noreply at sourceforge.net Sun Mar 11 22:13:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 14:13:19 -0700 Subject: [ python-Bugs-1245224 ] Time module is missing inverse of gmtime() Message-ID: Bugs item #1245224, was opened at 2005-07-26 15:04 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1245224&group_id=5470 Please note that this 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 Private: No Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: Time module is missing inverse of gmtime() Initial Comment: The time module has the inverse function of localtime() in its mktime () function, but is missing the inverse of gmtime(). After a bit of searching, I found the calendar module function timegm (), which claims to be the inverse of gmtime(). Is there any reason the time module shouldn't provide the inverse of gmtime()? It's obviously needed, as the calendar module has a version for its own use since the time module doesn't provide one. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 22:13 Message: Logged In: YES user_id=226443 Originator: NO See patch #1667546 for an implementation of timegm. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1245224&group_id=5470 From noreply at sourceforge.net Sun Mar 11 22:16:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 14:16:26 -0700 Subject: [ python-Bugs-1645148 ] MIME renderer: wrong header line break with long subject? Message-ID: Bugs item #1645148, was opened at 2007-01-26 05:04 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1645148&group_id=5470 Please note that this 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 Private: No Submitted By: kxroberto (kxroberto) Assigned to: Barry A. Warsaw (bwarsaw) Summary: MIME renderer: wrong header line break with long subject? Initial Comment: >>> from email.MIMEText import MIMEText >>> o=MIMEText('hello') >>> o['Subject']='1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 ' >>> o.as_string() 'Content-Type: text/plain; charset="us-ascii"\nMIME-Version: 1.0\nContent-Transf er-Encoding: 7bit\nSubject: 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8\n\t9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 \n\ nhello' >>> The '6 7 8\n\t9 1 2 3' clashes together to 6 7 89 1 2 3 without space between 89 in usual mail readers. Is this an error and should be : '6 7 8 \n\t9 1 2 3' ? as there is also the space preserved in '6 7 8 9 \n\nhello' ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2007-03-11 17:16 Message: Logged In: YES user_id=12800 Originator: NO Tokio, I'm not so sure about adding that extra space. I tested all the mail readers at my disposal on Linux and OSX. I don't have any Windows machines available so I couldn't test Outlook or OE. (If you have them, please indicate what they do in a comment here!) Here's what I found: OSX: Mail.app 2.1.1 -- the extra space produces an extra space between the 8 and 9 both in the message summary and in the Subject header in the preview pane. The no extra space message looks fine. Thunderbird 1.5.0.10 -- The extra space message produces an extra space in the message summary, while the no extra space message looks fine here. But the weird thing is that in both the extra space and non-extra space cases, the Subject header in the preview pane both have extra spaces. It looks to me like the leading tab is being inserted into the Subject header view. Entourage 11.3.3 -- The extra space shows up in both the summary and preview panes but only in the message with the extra space Linux Thunderbird 1.5.0.10 -- both messages get a tab between the 8 and 9 in both the summary and preview pane. This is for both the extra space message and the no-extra space message; afaict, there's no difference between the two and this is definitely a difference between the Linux version and the OSX version of the same mail reader. Evolution 2.9.92 -- the extra space message produces an extra space between the 8 and 9 in both the summary and preview panes. The no-extra space message looks fine. Sylpheed Claws 2.6.0 -- the extra space message produces an extra space between the 8 and 9 in both the summary and preview panes. The no-extra space message looks file. So anyway, afaict, the extra space is not appropriate for any of the non-Windows mail readers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1645148&group_id=5470 From noreply at sourceforge.net Sun Mar 11 22:17:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 14:17:19 -0700 Subject: [ python-Bugs-1645148 ] MIME renderer: wrong header line break with long subject? Message-ID: Bugs item #1645148, was opened at 2007-01-26 05:04 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1645148&group_id=5470 Please note that this 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 Private: No Submitted By: kxroberto (kxroberto) Assigned to: Barry A. Warsaw (bwarsaw) Summary: MIME renderer: wrong header line break with long subject? Initial Comment: >>> from email.MIMEText import MIMEText >>> o=MIMEText('hello') >>> o['Subject']='1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 ' >>> o.as_string() 'Content-Type: text/plain; charset="us-ascii"\nMIME-Version: 1.0\nContent-Transf er-Encoding: 7bit\nSubject: 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8\n\t9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 \n\ nhello' >>> The '6 7 8\n\t9 1 2 3' clashes together to 6 7 89 1 2 3 without space between 89 in usual mail readers. Is this an error and should be : '6 7 8 \n\t9 1 2 3' ? as there is also the space preserved in '6 7 8 9 \n\nhello' ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2007-03-11 17:17 Message: Logged In: YES user_id=12800 Originator: NO Whoops, this wasn't supposed to be a response to Tokio, but instead the OP. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2007-03-11 17:16 Message: Logged In: YES user_id=12800 Originator: NO Tokio, I'm not so sure about adding that extra space. I tested all the mail readers at my disposal on Linux and OSX. I don't have any Windows machines available so I couldn't test Outlook or OE. (If you have them, please indicate what they do in a comment here!) Here's what I found: OSX: Mail.app 2.1.1 -- the extra space produces an extra space between the 8 and 9 both in the message summary and in the Subject header in the preview pane. The no extra space message looks fine. Thunderbird 1.5.0.10 -- The extra space message produces an extra space in the message summary, while the no extra space message looks fine here. But the weird thing is that in both the extra space and non-extra space cases, the Subject header in the preview pane both have extra spaces. It looks to me like the leading tab is being inserted into the Subject header view. Entourage 11.3.3 -- The extra space shows up in both the summary and preview panes but only in the message with the extra space Linux Thunderbird 1.5.0.10 -- both messages get a tab between the 8 and 9 in both the summary and preview pane. This is for both the extra space message and the no-extra space message; afaict, there's no difference between the two and this is definitely a difference between the Linux version and the OSX version of the same mail reader. Evolution 2.9.92 -- the extra space message produces an extra space between the 8 and 9 in both the summary and preview panes. The no-extra space message looks fine. Sylpheed Claws 2.6.0 -- the extra space message produces an extra space between the 8 and 9 in both the summary and preview panes. The no-extra space message looks file. So anyway, afaict, the extra space is not appropriate for any of the non-Windows mail readers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1645148&group_id=5470 From noreply at sourceforge.net Sun Mar 11 22:23:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 14:23:36 -0700 Subject: [ python-Bugs-971965 ] urllib2 raises exception with non-200 success codes. Message-ID: Bugs item #971965, was opened at 2004-06-13 13:00 Message generated for change (Comment added) made by jbelmonte 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 Private: No 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 Belmonte (jbelmonte) Date: 2007-03-12 06:23 Message: Logged In: YES user_id=282299 Originator: NO Fixing this issue is not "maybe OK", it's the correct thing to do. Having an HTTP success response raise an exception is faulty behavior, and urllib2 users should not have to do silly things to work around it. It really seems like the authors of urllib2 only understood about 10% of the HTTP protocol. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-05-20 05: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 Sun Mar 11 23:27:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 15:27:07 -0700 Subject: [ python-Bugs-1678380 ] 0.0 and -0.0 identified, with surprising results Message-ID: Bugs item #1678380, was opened at 2007-03-11 18:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678380&group_id=5470 Please note that this 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: Wont Fix Priority: 5 Private: No Submitted By: Mark Dickinson (marketdickinson) Assigned to: Nobody/Anonymous (nobody) Summary: 0.0 and -0.0 identified, with surprising results Initial Comment: The identification of -0.0 and 0.0 in scripts leads to some surprising results. In particular, code that behaves one way in the interpreter can behave differently in a script. For example: Python 2.6a0 (trunk:54183M, Mar 6 2007, 20:16:00) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from math import atan2; >>> x = -0. >>> y = 0. >>> print atan2(y, -1.) 3.14159265359 But: >>> exec("from math import atan2; x = -0.; y = 0.; print atan2(y, -1.)") -3.14159265359 A simpler example: >>> x, y = -0., 0. >>> x, y (-0.0, -0.0) >>> id(x) == id(y) True But: >>> x = -0. >>> y = 0. >>> x, y (-0.0, 0.0) This occurs both on SuSE Linux 9.3/i686 and on OS X 10.4.8/PowerPC. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-11 23:27 Message: Logged In: YES user_id=21627 Originator: NO marketdickinson, you should ask this question (is this really acceptable) on python-dev. I find it perfectly acceptable. No program should rely on -0 and +0 being two different things (and thus also not relying on atan2 giving two different results). ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-03-11 21:10 Message: Logged In: YES user_id=479790 Originator: NO It appears to be a problem in the way compile.c handles literals. See http://mail.python.org/pipermail/python-list/2007-March/430302.html ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-03-11 20:21 Message: Logged In: YES user_id=703403 Originator: YES May I beg for reconsideration. Is the following really considered acceptable? >>> x = -0.; atan2(0., -1) -3.1415926535897931 >>> x = -(0.); atan2(0., -1) 3.1415926535897931 >>> atan2(0., -1) 3.1415926535897931 A single x = -0. at the start of a script can have side effects several hundred lines later, even when the variable x is never referred to again. I guess the advice should be: "To avoid surprises, -0. should never appear in any script." ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-11 19:35 Message: Logged In: YES user_id=21627 Originator: NO This is not a bug, at least not one that will be fixed. Details of the floating-point can vary across platforms, and they may behave in suprising ways in various contexts. Users shouldn't rely on Python differentiating between -0 and +0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678380&group_id=5470 From noreply at sourceforge.net Mon Mar 12 01:04:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 17:04:16 -0700 Subject: [ python-Bugs-1678411 ] StringIO / cStringIO inconsistency with unicode Message-ID: Bugs item #1678411, was opened at 2007-03-11 18:07 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678411&group_id=5470 Please note that this 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: Invalid Priority: 5 Private: No Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: StringIO / cStringIO inconsistency with unicode Initial Comment: When trying to write unicode strings into a StringIO.StringIO() or a cStringIO.StringIO() file, different things occur. (This causes a failing test in the "mako" project if cStringIO is not available.) Compare the following with StringIO or with cStringIO: f = StringIO() f.write("\xC0") f.write(u"hello") print f.getvalue() With cStringIO, unicode strings are immediately encoded as ascii and the getvalue() returns '\xC0hello'. With StringIO, on the other hand, the getvalue() crashes in a ''.join() trying to convert 'xC0' to unicode. Normal file() objects follow the same behavior as cStringIO, so my guess is that StringIO.py is wrong here. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2007-03-12 00:04 Message: Logged In: YES user_id=4771 Originator: YES I missed the documentation, which already desribes this difference. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-11 18:31 Message: Logged In: YES user_id=21627 Originator: NO It's intentional that they behave differently. StringIO supports Unicode strings, cStringIO doesn't. This means that you can build up a large Unicode string with StringIO, but not with cStringIO. What should happen when you mix them is debatable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678411&group_id=5470 From noreply at sourceforge.net Mon Mar 12 01:11:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 17:11:08 -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 Private: No 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: 2007-03-12 00:11 Message: Logged In: YES user_id=261020 Originator: NO Whether 206 and 201 are HTTP success responses is not the question at hand. Given that the 206 behaviour was changed, I agree that other success responses should also be considered (certainly seems a mistake that e.g. 203 was not added at the same time as 206), and indeed nobody has done that. But I think backwards compatibility, the semantics of the various response codes and of urllib2, and ease of understanding, are more important than you seem to assume. I don't see a patch. In what way exactly do you propose urllib2 should be changed? Note that it's not completely obvious: e.g. a 201 received by a plain-urllib2 client would be an erroneous server response, because urllib2 is designed only for retrieving URLs, and is not intended to be a generic HTTP client. Also note that clients based on urllib2 that do support PUT, such as the Atom client you refer to, can easily implement the modified 201 handling themselves. So on the face of it, the particular issue you raise is a bug in that code, and not in urllib2. Of course, your derogatory remarks about authors / bug-fixers won't persuade anybody of anything, or get any work done. ---------------------------------------------------------------------- Comment By: John Belmonte (jbelmonte) Date: 2007-03-11 21:23 Message: Logged In: YES user_id=282299 Originator: NO Fixing this issue is not "maybe OK", it's the correct thing to do. Having an HTTP success response raise an exception is faulty behavior, and urllib2 users should not have to do silly things to work around it. It really seems like the authors of urllib2 only understood about 10% of the HTTP protocol. ---------------------------------------------------------------------- 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 Mon Mar 12 01:20:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 17:20:55 -0700 Subject: [ python-Bugs-1678647 ] Weird behavior Exception with unicode string Message-ID: Bugs item #1678647, was opened at 2007-03-11 21: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=1678647&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Leandro Lucarella (llucax) Assigned to: M.-A. Lemburg (lemburg) Summary: Weird behavior Exception with unicode string Initial Comment: This simple python program: ------------------------------- raise Exception(u'Muri\u00f3') ------------------------------- prints: ----------------------------------- Traceback (most recent call last): File "pylog.py", line 1, in ? raise Exception(u'Muri\u00f3') Exception ----------------------------------- While not using an unicode character, seems to work fine (even if using an unicode parameter): -------------------------- raise Exception(u'Murio') -------------------------- prints: ----------------------------------- Traceback (most recent call last): File "pylog.py", line 1, in ? raise Exception(u'Murio') Exception: Murio ----------------------------------- This seems to break the logging module when calling logging.exception(u'Muri\u00f3'), for example. Tested in Python 2.4.4 and 2.5 (debian). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678647&group_id=5470 From noreply at sourceforge.net Mon Mar 12 02:10:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 18:10:34 -0700 Subject: [ python-Bugs-798274 ] absolute import patch breaks external users of test.regrtest Message-ID: Bugs item #798274, was opened at 2003-08-31 17:39 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=798274&group_id=5470 Please note that this 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: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Nicholas Riley (nriley) Assigned to: Nobody/Anonymous (nobody) Summary: absolute import patch breaks external users of test.regrtest Initial Comment: I've built a test system using Python's test.regrtest mechanism, and it worked very well under Python 2.2. In Python 2.3, the output looks like this: test_inttypes test_inttypes skipped -- No module named test_inttypes test_string test_unittest test_unittest skipped -- No module named test_unittest [...] I've tracked the problem down to a change made about a year ago. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ python/dist/src/Lib/test/regrtest.py.diff?r1=1.91&r2=1.92 test.regrtest is finding the modules, but is failing to import them because it is prepending 'test.' to the module names, in a mistaken assumption that all tests will be in a package named test. As it happened, I had my test modules inside a directory named 'test', and I tried making the directory a module and futzing with sys.path to get it to work, but now test.regrtest can't find the system implementation of test.test_support. I've also now got the problem of namespace pollution - the "test_string" above is Python's version, not my version with the same name. So, it appears non-Python users of test.regrtest are broken by this change in Python 2.3. I was pretty careful to make sure that I was doing something supported - the docstring for test.regrtest.main explicitly refers to non-Python test suite users - and ran into some weird cases like test.* not being installed on Mac OS X by default, but it worked very well otherwise. One potential solution would be that if 'testdir' is specified, test.regrtest.main() does not attempt to prepend 'test.' to the module names. This seems to match pretty well with the spirit of the documentation for that method. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-11 21:10 Message: Logged In: YES user_id=1344176 Originator: NO regrtest's purpose is to test Python; third-party projects wishing to use regrtest in their own test suites would do well to customize it for their particular needs. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-21 15:47 Message: Logged In: YES user_id=12800 I'm relinquishing assignment of this issue and moving it to Python 2.4. ---------------------------------------------------------------------- Comment By: Nicholas Riley (nriley) Date: 2003-09-17 18:53 Message: Logged In: YES user_id=34933 Thanks for the helpful response. Sorry I didn't get around to writing any documentation, but a patch is here: http://sourceforge.net/tracker/index.php? func=detail&aid=808210&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-09-01 23:54 Message: Logged In: YES user_id=12800 IIRC, this patch was necessary because some tests required absolute imports and we cannot mix relative and absolute imports in the test suite. IMO, regrtest's primary mission in life is to support Python's test suite and any other use is secondary (for example, it isn't documented in the standard library manual). OTOH, you might think about contributing a patch that allows regrtest to be used outside the Python test suite, but doesn't break the absolute import requirement while in the test suite. (You might also consider adding some standard lib documentation to your patch <wink>). The other problems you mention are inherent in Python's import machinery. If you have two packages named "test" on your sys.path, Python will not by default search them both for submodules. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 12:51 Message: Logged In: YES user_id=80475 Barry, this was your change. Would you take a look at this bug report? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=798274&group_id=5470 From noreply at sourceforge.net Mon Mar 12 02:15:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 18:15:26 -0700 Subject: [ python-Bugs-1678380 ] 0.0 and -0.0 identified, with surprising results Message-ID: Bugs item #1678380, was opened at 2007-03-11 17:16 Message generated for change (Comment added) made by marketdickinson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678380&group_id=5470 Please note that this 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: Wont Fix Priority: 5 Private: No Submitted By: Mark Dickinson (marketdickinson) Assigned to: Nobody/Anonymous (nobody) Summary: 0.0 and -0.0 identified, with surprising results Initial Comment: The identification of -0.0 and 0.0 in scripts leads to some surprising results. In particular, code that behaves one way in the interpreter can behave differently in a script. For example: Python 2.6a0 (trunk:54183M, Mar 6 2007, 20:16:00) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from math import atan2; >>> x = -0. >>> y = 0. >>> print atan2(y, -1.) 3.14159265359 But: >>> exec("from math import atan2; x = -0.; y = 0.; print atan2(y, -1.)") -3.14159265359 A simpler example: >>> x, y = -0., 0. >>> x, y (-0.0, -0.0) >>> id(x) == id(y) True But: >>> x = -0. >>> y = 0. >>> x, y (-0.0, 0.0) This occurs both on SuSE Linux 9.3/i686 and on OS X 10.4.8/PowerPC. ---------------------------------------------------------------------- >Comment By: Mark Dickinson (marketdickinson) Date: 2007-03-12 01:15 Message: Logged In: YES user_id=703403 Originator: YES I expressed myself badly. I apologise. This really isn't about +0. and -0. being different, or not. I'm perfectly comfortable with the idea that +0. and -0. may or may not be distinguishable on any given platform. The surprise is the other way around: two *identical* calls to atan(0., -1.) (or to repr(0.) for that matter) give *different* results, depending solely on whether a -0. literal has appeared earlier on in the code unit being compiled. So if the first float zero literal encountered in a source file just happens to be a -0. rather than a 0., the meaning of str(0.) later on suddenly becomes "-0.0" rather than "0.0". I'd like to be able to rely on str(0.) meaning "0.0" without having to worry about whether there might be a -0. literal appearing in some faraway and otherwise completely irrelevant portion of the file. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-11 22:27 Message: Logged In: YES user_id=21627 Originator: NO marketdickinson, you should ask this question (is this really acceptable) on python-dev. I find it perfectly acceptable. No program should rely on -0 and +0 being two different things (and thus also not relying on atan2 giving two different results). ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-03-11 20:10 Message: Logged In: YES user_id=479790 Originator: NO It appears to be a problem in the way compile.c handles literals. See http://mail.python.org/pipermail/python-list/2007-March/430302.html ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-03-11 19:21 Message: Logged In: YES user_id=703403 Originator: YES May I beg for reconsideration. Is the following really considered acceptable? >>> x = -0.; atan2(0., -1) -3.1415926535897931 >>> x = -(0.); atan2(0., -1) 3.1415926535897931 >>> atan2(0., -1) 3.1415926535897931 A single x = -0. at the start of a script can have side effects several hundred lines later, even when the variable x is never referred to again. I guess the advice should be: "To avoid surprises, -0. should never appear in any script." ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-11 18:35 Message: Logged In: YES user_id=21627 Originator: NO This is not a bug, at least not one that will be fixed. Details of the floating-point can vary across platforms, and they may behave in suprising ways in various contexts. Users shouldn't rely on Python differentiating between -0 and +0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678380&group_id=5470 From noreply at sourceforge.net Mon Mar 12 02:51:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 18:51:05 -0700 Subject: [ python-Bugs-1678380 ] 0.0 and -0.0 identified, with surprising results Message-ID: Bugs item #1678380, was opened at 2007-03-11 10:16 Message generated for change (Comment added) made by aleax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678380&group_id=5470 Please note that this 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: Wont Fix Priority: 5 Private: No Submitted By: Mark Dickinson (marketdickinson) Assigned to: Nobody/Anonymous (nobody) Summary: 0.0 and -0.0 identified, with surprising results Initial Comment: The identification of -0.0 and 0.0 in scripts leads to some surprising results. In particular, code that behaves one way in the interpreter can behave differently in a script. For example: Python 2.6a0 (trunk:54183M, Mar 6 2007, 20:16:00) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from math import atan2; >>> x = -0. >>> y = 0. >>> print atan2(y, -1.) 3.14159265359 But: >>> exec("from math import atan2; x = -0.; y = 0.; print atan2(y, -1.)") -3.14159265359 A simpler example: >>> x, y = -0., 0. >>> x, y (-0.0, -0.0) >>> id(x) == id(y) True But: >>> x = -0. >>> y = 0. >>> x, y (-0.0, 0.0) This occurs both on SuSE Linux 9.3/i686 and on OS X 10.4.8/PowerPC. ---------------------------------------------------------------------- >Comment By: Alex Martelli (aleax) Date: 2007-03-11 18:51 Message: Logged In: YES user_id=60314 Originator: NO Also see my patch 1678380 which fixes this bug (and checks for it in a new unittest). ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-03-11 18:15 Message: Logged In: YES user_id=703403 Originator: YES I expressed myself badly. I apologise. This really isn't about +0. and -0. being different, or not. I'm perfectly comfortable with the idea that +0. and -0. may or may not be distinguishable on any given platform. The surprise is the other way around: two *identical* calls to atan(0., -1.) (or to repr(0.) for that matter) give *different* results, depending solely on whether a -0. literal has appeared earlier on in the code unit being compiled. So if the first float zero literal encountered in a source file just happens to be a -0. rather than a 0., the meaning of str(0.) later on suddenly becomes "-0.0" rather than "0.0". I'd like to be able to rely on str(0.) meaning "0.0" without having to worry about whether there might be a -0. literal appearing in some faraway and otherwise completely irrelevant portion of the file. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-11 15:27 Message: Logged In: YES user_id=21627 Originator: NO marketdickinson, you should ask this question (is this really acceptable) on python-dev. I find it perfectly acceptable. No program should rely on -0 and +0 being two different things (and thus also not relying on atan2 giving two different results). ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-03-11 13:10 Message: Logged In: YES user_id=479790 Originator: NO It appears to be a problem in the way compile.c handles literals. See http://mail.python.org/pipermail/python-list/2007-March/430302.html ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-03-11 12:21 Message: Logged In: YES user_id=703403 Originator: YES May I beg for reconsideration. Is the following really considered acceptable? >>> x = -0.; atan2(0., -1) -3.1415926535897931 >>> x = -(0.); atan2(0., -1) 3.1415926535897931 >>> atan2(0., -1) 3.1415926535897931 A single x = -0. at the start of a script can have side effects several hundred lines later, even when the variable x is never referred to again. I guess the advice should be: "To avoid surprises, -0. should never appear in any script." ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-11 11:35 Message: Logged In: YES user_id=21627 Originator: NO This is not a bug, at least not one that will be fixed. Details of the floating-point can vary across platforms, and they may behave in suprising ways in various contexts. Users shouldn't rely on Python differentiating between -0 and +0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678380&group_id=5470 From noreply at sourceforge.net Mon Mar 12 02:54:21 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 18:54:21 -0700 Subject: [ python-Bugs-1678380 ] 0.0 and -0.0 identified, with surprising results Message-ID: Bugs item #1678380, was opened at 2007-03-11 10:16 Message generated for change (Comment added) made by aleax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678380&group_id=5470 Please note that this 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: Wont Fix Priority: 5 Private: No Submitted By: Mark Dickinson (marketdickinson) Assigned to: Nobody/Anonymous (nobody) Summary: 0.0 and -0.0 identified, with surprising results Initial Comment: The identification of -0.0 and 0.0 in scripts leads to some surprising results. In particular, code that behaves one way in the interpreter can behave differently in a script. For example: Python 2.6a0 (trunk:54183M, Mar 6 2007, 20:16:00) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from math import atan2; >>> x = -0. >>> y = 0. >>> print atan2(y, -1.) 3.14159265359 But: >>> exec("from math import atan2; x = -0.; y = 0.; print atan2(y, -1.)") -3.14159265359 A simpler example: >>> x, y = -0., 0. >>> x, y (-0.0, -0.0) >>> id(x) == id(y) True But: >>> x = -0. >>> y = 0. >>> x, y (-0.0, 0.0) This occurs both on SuSE Linux 9.3/i686 and on OS X 10.4.8/PowerPC. ---------------------------------------------------------------------- >Comment By: Alex Martelli (aleax) Date: 2007-03-11 18:54 Message: Logged In: YES user_id=60314 Originator: NO Oops,sorry, I meant patch 1678668 (copy-and-pasted the wrong ID:-). Alex ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2007-03-11 18:51 Message: Logged In: YES user_id=60314 Originator: NO Also see my patch 1678380 which fixes this bug (and checks for it in a new unittest). ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-03-11 18:15 Message: Logged In: YES user_id=703403 Originator: YES I expressed myself badly. I apologise. This really isn't about +0. and -0. being different, or not. I'm perfectly comfortable with the idea that +0. and -0. may or may not be distinguishable on any given platform. The surprise is the other way around: two *identical* calls to atan(0., -1.) (or to repr(0.) for that matter) give *different* results, depending solely on whether a -0. literal has appeared earlier on in the code unit being compiled. So if the first float zero literal encountered in a source file just happens to be a -0. rather than a 0., the meaning of str(0.) later on suddenly becomes "-0.0" rather than "0.0". I'd like to be able to rely on str(0.) meaning "0.0" without having to worry about whether there might be a -0. literal appearing in some faraway and otherwise completely irrelevant portion of the file. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-11 15:27 Message: Logged In: YES user_id=21627 Originator: NO marketdickinson, you should ask this question (is this really acceptable) on python-dev. I find it perfectly acceptable. No program should rely on -0 and +0 being two different things (and thus also not relying on atan2 giving two different results). ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-03-11 13:10 Message: Logged In: YES user_id=479790 Originator: NO It appears to be a problem in the way compile.c handles literals. See http://mail.python.org/pipermail/python-list/2007-March/430302.html ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-03-11 12:21 Message: Logged In: YES user_id=703403 Originator: YES May I beg for reconsideration. Is the following really considered acceptable? >>> x = -0.; atan2(0., -1) -3.1415926535897931 >>> x = -(0.); atan2(0., -1) 3.1415926535897931 >>> atan2(0., -1) 3.1415926535897931 A single x = -0. at the start of a script can have side effects several hundred lines later, even when the variable x is never referred to again. I guess the advice should be: "To avoid surprises, -0. should never appear in any script." ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-11 11:35 Message: Logged In: YES user_id=21627 Originator: NO This is not a bug, at least not one that will be fixed. Details of the floating-point can vary across platforms, and they may behave in suprising ways in various contexts. Users shouldn't rely on Python differentiating between -0 and +0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678380&group_id=5470 From noreply at sourceforge.net Mon Mar 12 04:21:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 20:21:43 -0700 Subject: [ python-Bugs-1629369 ] email._parseaddr AddrlistClass bug Message-ID: Bugs item #1629369, was opened at 2007-01-06 07:31 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1629369&group_id=5470 Please note that this 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.5 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email._parseaddr AddrlistClass bug Initial Comment: email._parseaddr AddrlistClass incorrectly parse multilined comment (display name). According to RFC2822, folding white space is allowed in display name. Thus following header should be parsed as a single address "foo at example.com" having multilined display name. To: Foo Bar On the other hand, following program results in: from email.Utils import getaddresses s = """Foo Bar """ print getaddresses([s]) [('', 'Foo'), ('Bar', 'foo at example.com')] Note that the first address is not valid one. Looks like the bug is in _parseaddr.py. Please check the patch. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2007-03-11 23:21 Message: Logged In: YES user_id=12800 Originator: NO r54280 in Python 2.6 svn trunk r54281 in Python 2.5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1629369&group_id=5470 From noreply at sourceforge.net Mon Mar 12 04:34:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 20:34:49 -0700 Subject: [ python-Bugs-1678710 ] dead link in tkinter documentation Message-ID: Bugs item #1678710, was opened at 2007-03-11 20: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=1678710&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ben Collver (bencollver) Assigned to: Nobody/Anonymous (nobody) Summary: dead link in tkinter documentation Initial Comment: On the following page, there is a dead link. http://www.python.org/doc/2.3.5/lib/node642.html The dead link is to the following URL. http://www.python.org/doc/2.3.5/lib/classes/ClassPacker.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678710&group_id=5470 From noreply at sourceforge.net Mon Mar 12 05:43:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 21:43:56 -0700 Subject: [ python-Bugs-1678647 ] Weird behavior Exception with unicode string Message-ID: Bugs item #1678647, was opened at 2007-03-12 09:20 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678647&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Leandro Lucarella (llucax) Assigned to: M.-A. Lemburg (lemburg) Summary: Weird behavior Exception with unicode string Initial Comment: This simple python program: ------------------------------- raise Exception(u'Muri\u00f3') ------------------------------- prints: ----------------------------------- Traceback (most recent call last): File "pylog.py", line 1, in ? raise Exception(u'Muri\u00f3') Exception ----------------------------------- While not using an unicode character, seems to work fine (even if using an unicode parameter): -------------------------- raise Exception(u'Murio') -------------------------- prints: ----------------------------------- Traceback (most recent call last): File "pylog.py", line 1, in ? raise Exception(u'Murio') Exception: Murio ----------------------------------- This seems to break the logging module when calling logging.exception(u'Muri\u00f3'), for example. Tested in Python 2.4.4 and 2.5 (debian). ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2007-03-12 13:43 Message: Logged In: YES user_id=55188 Originator: NO That's from line 1216-1230 of Python/pythonrun.c as in trunk. It tries PyObject_Str(exception) and skips printing line terminator when it failed. And the behavior came from r8084 (http://svn.python.org/view/python/trunk/Python/pythonrun.c?rev=8084&r1=8070&r2=8084). Hmm. I think it should put a LF even if the conversion failed. (encoding the unicode with "ignore" or "replace" would make some confusion and putting it in PyObject_Repr() makes inconsistency.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678647&group_id=5470 From noreply at sourceforge.net Mon Mar 12 08:37:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 00:37:13 -0700 Subject: [ python-Bugs-1675511 ] Python still uses broken -xcode option on Solaris/x86 Message-ID: Bugs item #1675511, was opened at 2007-03-07 15:54 Message generated for change (Comment added) made by jlick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: Python still uses broken -xcode option on Solaris/x86 Initial Comment: Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting a new bug against 2.5 in the hopes that someone will read it... text updated with minor corrections. Python 2.5, Solaris x86 10 Update 3, Sun Studio 11 xcode=pic32 option is not supported on Solaris x86 Sun C . Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when any compiler other than gcc is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates an error that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-12 15:37 Message: Logged In: YES user_id=673069 Originator: NO I've made a patch for configure.in to fix this bug. There are two notes to explain why it was written the way it is: The first problem is to determine which processor type we are using. 'uname -p' was chosen because it returns the most generic response on both SPARC (sparc) and x86/x64 (i386) systems. There is some controversy about why it returns 'i386' even on Pentium or AMD64 systems, but Sun points to the isainfo, isalist, or psrinfo commands to get more specific processor information, so it appears they don't intend to change the behavior. The second choice is how to handle the default case if the result of the above is neither sparc or i386. I chose to use '-xcode=pic32' for sparc only, and '-Kpic' for all other responses. My reasoning is that since -Kpic existed before -xcode=pic32 was implemented that it is the more generic option, even though it and -KPIC are deprecated on sparc. I am therefore making the assumption that any possible new platforms supported by Studio 11 would in some fashion support -Kpic. This patch is a diff against Python 2.5's configure.in file. I've tested it against a Solaris 10 32-bit x86 system and a Solaris 10 64-bit sparc system both with Studio 11 installed. I don't have a 64-bit x86 system to test against. The build is mostly successful on both though there is a problem with the _ctypes module which causes test_ctypes to fail. This is a known problem covered by other bug reports which I believe is unrelated to this patch. I couldn't find the option to upload a file, so here is the patch inline: ---snip--- *** configure.in.old 2007-03-11 23:01:16.879612000 -0700 --- configure.in 2007-03-11 23:31:48.098734000 -0700 *************** *** 1543,1551 **** then case $ac_sys_system/$ac_sys_release in SunOS*) if test "$GCC" = yes; ! then CCSHARED="-fPIC"; ! else CCSHARED="-xcode=pic32"; ! fi;; hp*|HP*) if test "$GCC" = yes; then CCSHARED="-fPIC"; else CCSHARED="+z"; --- 1543,1553 ---- then case $ac_sys_system/$ac_sys_release in SunOS*) if test "$GCC" = yes; ! then CCSHARED="-fPIC"; ! elif test `uname -p` = sparc; ! then CCSHARED="-xcode=pic32"; ! else CCSHARED="-Kpic"; ! fi;; hp*|HP*) if test "$GCC" = yes; then CCSHARED="-fPIC"; else CCSHARED="+z"; ---snip--- ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-11 03:06 Message: Logged In: YES user_id=21627 Originator: NO The manual claims (in "Supported Platforms") that "x86" refers to both 32-bit and 64-bit systems, and promises to use "32-bit x86" for 32-bit specific information, so I guess -Kpic works on AMD64 as well. ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-11 02:35 Message: Logged In: YES user_id=673069 Originator: NO According the the Studio 11 man page for cc '-KPIC' is an alias for '-Kpic' on x86, though it doesn't explicitly say whether this applies to x86 meaning 32 bit only or x86 meaning both 32 and 64 bit. In any case, since -KPIC is definitely equivalent to -Kpic on 32 bit x86, and -KPIC is known to work on x64, should we just use -KPIC for both? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-11 01:07 Message: Logged In: YES user_id=21627 Originator: NO Looks fine, although you might want to consider AMD64 as well. I think it should be -KPIC (although I'm uncertain whether Python works on that system at all). See http://blogs.sun.com/x86be/category/Sun ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-11 00:14 Message: Logged In: YES user_id=673069 Originator: NO I'm willing to take a stab at a patch. I've reviewed the Sun Studio 11 documentation and it appears that the preferred options are: Sun cc Sparc: -xcode=pic32 Sun cc X86: -Kpic Does that match the way you read it, loewis? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-09 16:56 Message: Logged In: YES user_id=21627 Originator: NO I don't want to make a change now, just to have to deal with a bug report two years from now which then will sit again in this tracker for years again. I'm fine with documenting that older SunPRO compilers are not supported; -xcode has been supported atleast since Sun Forte 6 (released in 2000); earlier products had reached their end-of-life long ago. So either this gets fixed properly now, or not at all. ---------------------------------------------------------------------- Comment By: Carson Gaspar (cgaspar) Date: 2007-03-09 16:06 Message: Logged In: YES user_id=664506 Originator: YES While the doc labels the -KPIC option as "obsolete" for SPARC, it works fine. Perhaps Studio 12 will break it, but all current compilers understand it fine. If you want to be pedantically correct and use -xcode=pic32, you don't need an architecture test, you need to actually _try_ the option, as older SPARC compilers won't accept it either. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-09 15:08 Message: Logged In: YES user_id=21627 Originator: NO One problem is that the proposed change is incorrect. According to the C User's Guide of Sun Studio 11 (document 819-3688-10), -KPIC is an obsolete option on SPARC, and should be replaced with -xcode=pic32 (section A.1.15). So I think a patch should be architecture-specific. Can somebody come up with a patch that does that? ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-07 16:34 Message: Logged In: YES user_id=673069 Originator: NO Perhaps I was unclear in bug #1561333 that this resulted in only a warning. Actually the build will fail because of the incorrect flag. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 From noreply at sourceforge.net Mon Mar 12 10:04:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 02:04:52 -0700 Subject: [ python-Bugs-1678380 ] 0.0 and -0.0 identified, with surprising results Message-ID: Bugs item #1678380, was opened at 2007-03-11 18:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678380&group_id=5470 Please note that this 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: Wont Fix Priority: 5 Private: No Submitted By: Mark Dickinson (marketdickinson) Assigned to: Nobody/Anonymous (nobody) Summary: 0.0 and -0.0 identified, with surprising results Initial Comment: The identification of -0.0 and 0.0 in scripts leads to some surprising results. In particular, code that behaves one way in the interpreter can behave differently in a script. For example: Python 2.6a0 (trunk:54183M, Mar 6 2007, 20:16:00) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from math import atan2; >>> x = -0. >>> y = 0. >>> print atan2(y, -1.) 3.14159265359 But: >>> exec("from math import atan2; x = -0.; y = 0.; print atan2(y, -1.)") -3.14159265359 A simpler example: >>> x, y = -0., 0. >>> x, y (-0.0, -0.0) >>> id(x) == id(y) True But: >>> x = -0. >>> y = 0. >>> x, y (-0.0, 0.0) This occurs both on SuSE Linux 9.3/i686 and on OS X 10.4.8/PowerPC. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-12 10:04 Message: Logged In: YES user_id=21627 Originator: NO I also expressed myself badly. I not only meant that programs should not rely on +0 and -0 being different things across platforms, but that they should also not rely on them being either always different or always the same in a single program. If Python would randomly chose to interpret +0 as -0, or would do so for every third occurence, I still couldn't see a problem. ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2007-03-12 02:54 Message: Logged In: YES user_id=60314 Originator: NO Oops,sorry, I meant patch 1678668 (copy-and-pasted the wrong ID:-). Alex ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2007-03-12 02:51 Message: Logged In: YES user_id=60314 Originator: NO Also see my patch 1678380 which fixes this bug (and checks for it in a new unittest). ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-03-12 02:15 Message: Logged In: YES user_id=703403 Originator: YES I expressed myself badly. I apologise. This really isn't about +0. and -0. being different, or not. I'm perfectly comfortable with the idea that +0. and -0. may or may not be distinguishable on any given platform. The surprise is the other way around: two *identical* calls to atan(0., -1.) (or to repr(0.) for that matter) give *different* results, depending solely on whether a -0. literal has appeared earlier on in the code unit being compiled. So if the first float zero literal encountered in a source file just happens to be a -0. rather than a 0., the meaning of str(0.) later on suddenly becomes "-0.0" rather than "0.0". I'd like to be able to rely on str(0.) meaning "0.0" without having to worry about whether there might be a -0. literal appearing in some faraway and otherwise completely irrelevant portion of the file. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-11 23:27 Message: Logged In: YES user_id=21627 Originator: NO marketdickinson, you should ask this question (is this really acceptable) on python-dev. I find it perfectly acceptable. No program should rely on -0 and +0 being two different things (and thus also not relying on atan2 giving two different results). ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-03-11 21:10 Message: Logged In: YES user_id=479790 Originator: NO It appears to be a problem in the way compile.c handles literals. See http://mail.python.org/pipermail/python-list/2007-March/430302.html ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-03-11 20:21 Message: Logged In: YES user_id=703403 Originator: YES May I beg for reconsideration. Is the following really considered acceptable? >>> x = -0.; atan2(0., -1) -3.1415926535897931 >>> x = -(0.); atan2(0., -1) 3.1415926535897931 >>> atan2(0., -1) 3.1415926535897931 A single x = -0. at the start of a script can have side effects several hundred lines later, even when the variable x is never referred to again. I guess the advice should be: "To avoid surprises, -0. should never appear in any script." ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-11 19:35 Message: Logged In: YES user_id=21627 Originator: NO This is not a bug, at least not one that will be fixed. Details of the floating-point can vary across platforms, and they may behave in suprising ways in various contexts. Users shouldn't rely on Python differentiating between -0 and +0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678380&group_id=5470 From noreply at sourceforge.net Mon Mar 12 10:52:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 02:52:36 -0700 Subject: [ python-Bugs-1675511 ] Python still uses broken -xcode option on Solaris/x86 Message-ID: Bugs item #1675511, was opened at 2007-03-07 15:54 Message generated for change (Comment added) made by jlick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: Python still uses broken -xcode option on Solaris/x86 Initial Comment: Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting a new bug against 2.5 in the hopes that someone will read it... text updated with minor corrections. Python 2.5, Solaris x86 10 Update 3, Sun Studio 11 xcode=pic32 option is not supported on Solaris x86 Sun C . Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when any compiler other than gcc is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates an error that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-12 17:52 Message: Logged In: YES user_id=673069 Originator: NO The patch I posted in the last comment also will apply (with warning) to Python 2.4.4 and builds OK. ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-12 15:37 Message: Logged In: YES user_id=673069 Originator: NO I've made a patch for configure.in to fix this bug. There are two notes to explain why it was written the way it is: The first problem is to determine which processor type we are using. 'uname -p' was chosen because it returns the most generic response on both SPARC (sparc) and x86/x64 (i386) systems. There is some controversy about why it returns 'i386' even on Pentium or AMD64 systems, but Sun points to the isainfo, isalist, or psrinfo commands to get more specific processor information, so it appears they don't intend to change the behavior. The second choice is how to handle the default case if the result of the above is neither sparc or i386. I chose to use '-xcode=pic32' for sparc only, and '-Kpic' for all other responses. My reasoning is that since -Kpic existed before -xcode=pic32 was implemented that it is the more generic option, even though it and -KPIC are deprecated on sparc. I am therefore making the assumption that any possible new platforms supported by Studio 11 would in some fashion support -Kpic. This patch is a diff against Python 2.5's configure.in file. I've tested it against a Solaris 10 32-bit x86 system and a Solaris 10 64-bit sparc system both with Studio 11 installed. I don't have a 64-bit x86 system to test against. The build is mostly successful on both though there is a problem with the _ctypes module which causes test_ctypes to fail. This is a known problem covered by other bug reports which I believe is unrelated to this patch. I couldn't find the option to upload a file, so here is the patch inline: ---snip--- *** configure.in.old 2007-03-11 23:01:16.879612000 -0700 --- configure.in 2007-03-11 23:31:48.098734000 -0700 *************** *** 1543,1551 **** then case $ac_sys_system/$ac_sys_release in SunOS*) if test "$GCC" = yes; ! then CCSHARED="-fPIC"; ! else CCSHARED="-xcode=pic32"; ! fi;; hp*|HP*) if test "$GCC" = yes; then CCSHARED="-fPIC"; else CCSHARED="+z"; --- 1543,1553 ---- then case $ac_sys_system/$ac_sys_release in SunOS*) if test "$GCC" = yes; ! then CCSHARED="-fPIC"; ! elif test `uname -p` = sparc; ! then CCSHARED="-xcode=pic32"; ! else CCSHARED="-Kpic"; ! fi;; hp*|HP*) if test "$GCC" = yes; then CCSHARED="-fPIC"; else CCSHARED="+z"; ---snip--- ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-11 03:06 Message: Logged In: YES user_id=21627 Originator: NO The manual claims (in "Supported Platforms") that "x86" refers to both 32-bit and 64-bit systems, and promises to use "32-bit x86" for 32-bit specific information, so I guess -Kpic works on AMD64 as well. ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-11 02:35 Message: Logged In: YES user_id=673069 Originator: NO According the the Studio 11 man page for cc '-KPIC' is an alias for '-Kpic' on x86, though it doesn't explicitly say whether this applies to x86 meaning 32 bit only or x86 meaning both 32 and 64 bit. In any case, since -KPIC is definitely equivalent to -Kpic on 32 bit x86, and -KPIC is known to work on x64, should we just use -KPIC for both? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-11 01:07 Message: Logged In: YES user_id=21627 Originator: NO Looks fine, although you might want to consider AMD64 as well. I think it should be -KPIC (although I'm uncertain whether Python works on that system at all). See http://blogs.sun.com/x86be/category/Sun ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-11 00:14 Message: Logged In: YES user_id=673069 Originator: NO I'm willing to take a stab at a patch. I've reviewed the Sun Studio 11 documentation and it appears that the preferred options are: Sun cc Sparc: -xcode=pic32 Sun cc X86: -Kpic Does that match the way you read it, loewis? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-09 16:56 Message: Logged In: YES user_id=21627 Originator: NO I don't want to make a change now, just to have to deal with a bug report two years from now which then will sit again in this tracker for years again. I'm fine with documenting that older SunPRO compilers are not supported; -xcode has been supported atleast since Sun Forte 6 (released in 2000); earlier products had reached their end-of-life long ago. So either this gets fixed properly now, or not at all. ---------------------------------------------------------------------- Comment By: Carson Gaspar (cgaspar) Date: 2007-03-09 16:06 Message: Logged In: YES user_id=664506 Originator: YES While the doc labels the -KPIC option as "obsolete" for SPARC, it works fine. Perhaps Studio 12 will break it, but all current compilers understand it fine. If you want to be pedantically correct and use -xcode=pic32, you don't need an architecture test, you need to actually _try_ the option, as older SPARC compilers won't accept it either. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-09 15:08 Message: Logged In: YES user_id=21627 Originator: NO One problem is that the proposed change is incorrect. According to the C User's Guide of Sun Studio 11 (document 819-3688-10), -KPIC is an obsolete option on SPARC, and should be replaced with -xcode=pic32 (section A.1.15). So I think a patch should be architecture-specific. Can somebody come up with a patch that does that? ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-07 16:34 Message: Logged In: YES user_id=673069 Originator: NO Perhaps I was unclear in bug #1561333 that this resulted in only a warning. Actually the build will fail because of the incorrect flag. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 From noreply at sourceforge.net Mon Mar 12 11:52:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 03:52:19 -0700 Subject: [ python-Bugs-1675511 ] Python still uses broken -xcode option on Solaris/x86 Message-ID: Bugs item #1675511, was opened at 2007-03-07 08:54 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: Python still uses broken -xcode option on Solaris/x86 Initial Comment: Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting a new bug against 2.5 in the hopes that someone will read it... text updated with minor corrections. Python 2.5, Solaris x86 10 Update 3, Sun Studio 11 xcode=pic32 option is not supported on Solaris x86 Sun C . Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when any compiler other than gcc is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates an error that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-12 11:52 Message: Logged In: YES user_id=21627 Originator: NO Thanks for the patch. Committed as r54283 and r54284. ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-12 10:52 Message: Logged In: YES user_id=673069 Originator: NO The patch I posted in the last comment also will apply (with warning) to Python 2.4.4 and builds OK. ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-12 08:37 Message: Logged In: YES user_id=673069 Originator: NO I've made a patch for configure.in to fix this bug. There are two notes to explain why it was written the way it is: The first problem is to determine which processor type we are using. 'uname -p' was chosen because it returns the most generic response on both SPARC (sparc) and x86/x64 (i386) systems. There is some controversy about why it returns 'i386' even on Pentium or AMD64 systems, but Sun points to the isainfo, isalist, or psrinfo commands to get more specific processor information, so it appears they don't intend to change the behavior. The second choice is how to handle the default case if the result of the above is neither sparc or i386. I chose to use '-xcode=pic32' for sparc only, and '-Kpic' for all other responses. My reasoning is that since -Kpic existed before -xcode=pic32 was implemented that it is the more generic option, even though it and -KPIC are deprecated on sparc. I am therefore making the assumption that any possible new platforms supported by Studio 11 would in some fashion support -Kpic. This patch is a diff against Python 2.5's configure.in file. I've tested it against a Solaris 10 32-bit x86 system and a Solaris 10 64-bit sparc system both with Studio 11 installed. I don't have a 64-bit x86 system to test against. The build is mostly successful on both though there is a problem with the _ctypes module which causes test_ctypes to fail. This is a known problem covered by other bug reports which I believe is unrelated to this patch. I couldn't find the option to upload a file, so here is the patch inline: ---snip--- *** configure.in.old 2007-03-11 23:01:16.879612000 -0700 --- configure.in 2007-03-11 23:31:48.098734000 -0700 *************** *** 1543,1551 **** then case $ac_sys_system/$ac_sys_release in SunOS*) if test "$GCC" = yes; ! then CCSHARED="-fPIC"; ! else CCSHARED="-xcode=pic32"; ! fi;; hp*|HP*) if test "$GCC" = yes; then CCSHARED="-fPIC"; else CCSHARED="+z"; --- 1543,1553 ---- then case $ac_sys_system/$ac_sys_release in SunOS*) if test "$GCC" = yes; ! then CCSHARED="-fPIC"; ! elif test `uname -p` = sparc; ! then CCSHARED="-xcode=pic32"; ! else CCSHARED="-Kpic"; ! fi;; hp*|HP*) if test "$GCC" = yes; then CCSHARED="-fPIC"; else CCSHARED="+z"; ---snip--- ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-10 20:06 Message: Logged In: YES user_id=21627 Originator: NO The manual claims (in "Supported Platforms") that "x86" refers to both 32-bit and 64-bit systems, and promises to use "32-bit x86" for 32-bit specific information, so I guess -Kpic works on AMD64 as well. ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-10 19:35 Message: Logged In: YES user_id=673069 Originator: NO According the the Studio 11 man page for cc '-KPIC' is an alias for '-Kpic' on x86, though it doesn't explicitly say whether this applies to x86 meaning 32 bit only or x86 meaning both 32 and 64 bit. In any case, since -KPIC is definitely equivalent to -Kpic on 32 bit x86, and -KPIC is known to work on x64, should we just use -KPIC for both? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-10 18:07 Message: Logged In: YES user_id=21627 Originator: NO Looks fine, although you might want to consider AMD64 as well. I think it should be -KPIC (although I'm uncertain whether Python works on that system at all). See http://blogs.sun.com/x86be/category/Sun ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-10 17:14 Message: Logged In: YES user_id=673069 Originator: NO I'm willing to take a stab at a patch. I've reviewed the Sun Studio 11 documentation and it appears that the preferred options are: Sun cc Sparc: -xcode=pic32 Sun cc X86: -Kpic Does that match the way you read it, loewis? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-09 09:56 Message: Logged In: YES user_id=21627 Originator: NO I don't want to make a change now, just to have to deal with a bug report two years from now which then will sit again in this tracker for years again. I'm fine with documenting that older SunPRO compilers are not supported; -xcode has been supported atleast since Sun Forte 6 (released in 2000); earlier products had reached their end-of-life long ago. So either this gets fixed properly now, or not at all. ---------------------------------------------------------------------- Comment By: Carson Gaspar (cgaspar) Date: 2007-03-09 09:06 Message: Logged In: YES user_id=664506 Originator: YES While the doc labels the -KPIC option as "obsolete" for SPARC, it works fine. Perhaps Studio 12 will break it, but all current compilers understand it fine. If you want to be pedantically correct and use -xcode=pic32, you don't need an architecture test, you need to actually _try_ the option, as older SPARC compilers won't accept it either. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-09 08:08 Message: Logged In: YES user_id=21627 Originator: NO One problem is that the proposed change is incorrect. According to the C User's Guide of Sun Studio 11 (document 819-3688-10), -KPIC is an obsolete option on SPARC, and should be replaced with -xcode=pic32 (section A.1.15). So I think a patch should be architecture-specific. Can somebody come up with a patch that does that? ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-07 09:34 Message: Logged In: YES user_id=673069 Originator: NO Perhaps I was unclear in bug #1561333 that this resulted in only a warning. Actually the build will fail because of the incorrect flag. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 From noreply at sourceforge.net Mon Mar 12 12:30:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 04:30:41 -0700 Subject: [ python-Bugs-1659171 ] Calling tparm from extension lib fails in Python 2.5 Message-ID: Bugs item #1659171, was opened at 2007-02-13 18:27 Message generated for change (Comment added) made by richyk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659171&group_id=5470 Please note that this 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 Private: No Submitted By: Richard B. Kreckel (richyk) Assigned to: Nobody/Anonymous (nobody) Summary: Calling tparm from extension lib fails in Python 2.5 Initial Comment: Attached is a little C++ module that fetches the terminal capability string for turning off all attributes and runs it through tparm(). (All this is done in a static Ctor of a class without init function, but never mind.) Compile with: g++ -c testlib.cc g++ testlib.o -o testlib.so -shared -Wl,-soname,testlib.so -lncurses On SuSE Linux 10.1 (and older), I get the expected behavior: Python 2.4.2 (#1, Oct 13 2006, 17:11:24) [GCC 4.1.0 (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import testlib Terminal is "xterm" Dump of sgr0: 1b 5b 30 6d Dump of instance: 1b 5b 30 6d Traceback (most recent call last): File "", line 1, in ? ImportError: dynamic module does not define init function (inittestlib) >>> However, on SuSE Linux 10.2, tparm creates a NULL pointer: Python 2.5 (r25:51908, Jan 9 2007, 16:59:32) [GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import testlib Terminal is "xterm" Dump of sgr0: 1b 5b 30 6d Rats! tparm made a NULL pointer! Traceback (most recent call last): File "", line 1, in ImportError: dynamic module does not define init function (inittestlib) >>> Why, oh why? ---------------------------------------------------------------------- >Comment By: Richard B. Kreckel (richyk) Date: 2007-03-12 12:30 Message: Logged In: YES user_id=1718463 Originator: YES Sorry, I cannot do that test anytime soon. (I've not enough time and my company doesn't let me access your SVN.) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-02-25 23:16 Message: Logged In: YES user_id=33168 Originator: NO Can you test with 2.5 from SVN and confirm your program works in the complete context? ---------------------------------------------------------------------- Comment By: Richard B. Kreckel (richyk) Date: 2007-02-22 13:25 Message: Logged In: YES user_id=1718463 Originator: YES The error message about the undefined init function is a red herring. The example is actually a stripped-down testcase from a much larger Boost.Python module, which of course does have an init function. The point here is the NULL pointer returned by tparm. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-02-14 22:24 Message: Logged In: YES user_id=21627 Originator: NO I fail to see the bug. The exception precisely describes the error in your code ImportError: dynamic module does not define init function (inittestlib) Why do you expect any meaningful behavior in the presence of this error? Your shared library isn't an extension module. If you think it is related to #1548092, please try out the subversion trunk, which has fixed this bug. ---------------------------------------------------------------------- Comment By: Richard B. Kreckel (richyk) Date: 2007-02-14 09:52 Message: Logged In: YES user_id=1718463 Originator: YES I suspect that this is a duplicate of Bug [1548092]. Note that, there it is asserted that tparm returns NULL on certain invalid strings. That does not seem to be true. It returns NULL for valid trivial strings, too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659171&group_id=5470 From noreply at sourceforge.net Mon Mar 12 14:51:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 06:51:44 -0700 Subject: [ python-Bugs-1590744 ] mail message parsing glitch Message-ID: Bugs item #1590744, was opened at 2006-11-05 04:21 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590744&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mike (mcspang) Assigned to: Barry A. Warsaw (bwarsaw) Summary: mail message parsing glitch Initial Comment: There's something wrong with the handling of line continuation in headers. In the attached mbox the 'Message-id' header is read and stored with a leading space. So message_id = ' <9B09D75DF5B3494BA06E6FE478CE9CC10526CFAF at mgtserver3.ontario.int.ec.gc.ca>' when it's first read. If you write this message out to a new mbox, it is written with the leading space and without the newline. THEN, if you read it in AGAIN, the parser ignores the leading space. One of these steps is buggy, I'm not sure which. It seems to me that the value returned by msg['Message_id'] should not change when the file is written then re-read. In the initial read and final reads above the value differs by a space. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2007-03-12 09:51 Message: Logged In: YES user_id=12800 Originator: NO This makes some sense, although it may not be ideal. The "leading space" is really an RFC 2822 continuation line, so that whitespace at the start of the second line is folding whitespace. Technically those two lines should (and do) get collapsed. The question is whether this message should be printed idempotently. In general the email package tries hard to maintain this principle, so I think it's probably a valid bug. However, it doesn't affect the semantics of the message so it's not a high priority fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590744&group_id=5470 From noreply at sourceforge.net Mon Mar 12 15:03:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 07:03:14 -0700 Subject: [ python-Bugs-1678647 ] Weird behavior Exception with unicode string Message-ID: Bugs item #1678647, was opened at 2007-03-11 21:20 Message generated for change (Comment added) made by llucax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678647&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Leandro Lucarella (llucax) Assigned to: M.-A. Lemburg (lemburg) Summary: Weird behavior Exception with unicode string Initial Comment: This simple python program: ------------------------------- raise Exception(u'Muri\u00f3') ------------------------------- prints: ----------------------------------- Traceback (most recent call last): File "pylog.py", line 1, in ? raise Exception(u'Muri\u00f3') Exception ----------------------------------- While not using an unicode character, seems to work fine (even if using an unicode parameter): -------------------------- raise Exception(u'Murio') -------------------------- prints: ----------------------------------- Traceback (most recent call last): File "pylog.py", line 1, in ? raise Exception(u'Murio') Exception: Murio ----------------------------------- This seems to break the logging module when calling logging.exception(u'Muri\u00f3'), for example. Tested in Python 2.4.4 and 2.5 (debian). ---------------------------------------------------------------------- >Comment By: Leandro Lucarella (llucax) Date: 2007-03-12 11:03 Message: Logged In: YES user_id=240225 Originator: YES But why the conversion is failing in the first place? Because just plain 7 bits ASCII is expected? ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2007-03-12 01:43 Message: Logged In: YES user_id=55188 Originator: NO That's from line 1216-1230 of Python/pythonrun.c as in trunk. It tries PyObject_Str(exception) and skips printing line terminator when it failed. And the behavior came from r8084 (http://svn.python.org/view/python/trunk/Python/pythonrun.c?rev=8084&r1=8070&r2=8084). Hmm. I think it should put a LF even if the conversion failed. (encoding the unicode with "ignore" or "replace" would make some confusion and putting it in PyObject_Repr() makes inconsistency.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678647&group_id=5470 From noreply at sourceforge.net Mon Mar 12 15:14:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 07:14:52 -0700 Subject: [ python-Bugs-1678647 ] Weird behavior Exception with unicode string Message-ID: Bugs item #1678647, was opened at 2007-03-12 00:20 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678647&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Leandro Lucarella (llucax) Assigned to: M.-A. Lemburg (lemburg) Summary: Weird behavior Exception with unicode string Initial Comment: This simple python program: ------------------------------- raise Exception(u'Muri\u00f3') ------------------------------- prints: ----------------------------------- Traceback (most recent call last): File "pylog.py", line 1, in ? raise Exception(u'Muri\u00f3') Exception ----------------------------------- While not using an unicode character, seems to work fine (even if using an unicode parameter): -------------------------- raise Exception(u'Murio') -------------------------- prints: ----------------------------------- Traceback (most recent call last): File "pylog.py", line 1, in ? raise Exception(u'Murio') Exception: Murio ----------------------------------- This seems to break the logging module when calling logging.exception(u'Muri\u00f3'), for example. Tested in Python 2.4.4 and 2.5 (debian). ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 14:14 Message: Logged In: YES user_id=849994 Originator: NO Yes, or more precisely, the unicode string is converted to a byte string using Python's default encoding, which is ASCII per default. ---------------------------------------------------------------------- Comment By: Leandro Lucarella (llucax) Date: 2007-03-12 14:03 Message: Logged In: YES user_id=240225 Originator: YES But why the conversion is failing in the first place? Because just plain 7 bits ASCII is expected? ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2007-03-12 04:43 Message: Logged In: YES user_id=55188 Originator: NO That's from line 1216-1230 of Python/pythonrun.c as in trunk. It tries PyObject_Str(exception) and skips printing line terminator when it failed. And the behavior came from r8084 (http://svn.python.org/view/python/trunk/Python/pythonrun.c?rev=8084&r1=8070&r2=8084). Hmm. I think it should put a LF even if the conversion failed. (encoding the unicode with "ignore" or "replace" would make some confusion and putting it in PyObject_Repr() makes inconsistency.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678647&group_id=5470 From noreply at sourceforge.net Mon Mar 12 15:57:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 07:57:45 -0700 Subject: [ python-Bugs-1678380 ] 0.0 and -0.0 identified, with surprising results Message-ID: Bugs item #1678380, was opened at 2007-03-11 10:16 Message generated for change (Comment added) made by aleax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678380&group_id=5470 Please note that this 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: Wont Fix Priority: 5 Private: No Submitted By: Mark Dickinson (marketdickinson) Assigned to: Nobody/Anonymous (nobody) Summary: 0.0 and -0.0 identified, with surprising results Initial Comment: The identification of -0.0 and 0.0 in scripts leads to some surprising results. In particular, code that behaves one way in the interpreter can behave differently in a script. For example: Python 2.6a0 (trunk:54183M, Mar 6 2007, 20:16:00) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from math import atan2; >>> x = -0. >>> y = 0. >>> print atan2(y, -1.) 3.14159265359 But: >>> exec("from math import atan2; x = -0.; y = 0.; print atan2(y, -1.)") -3.14159265359 A simpler example: >>> x, y = -0., 0. >>> x, y (-0.0, -0.0) >>> id(x) == id(y) True But: >>> x = -0. >>> y = 0. >>> x, y (-0.0, 0.0) This occurs both on SuSE Linux 9.3/i686 and on OS X 10.4.8/PowerPC. ---------------------------------------------------------------------- >Comment By: Alex Martelli (aleax) Date: 2007-03-12 07:57 Message: Logged In: YES user_id=60314 Originator: NO and yet, peephole.c does specialcase -0 (with a comment and all!-) avoiding constant-folding optimization for it -- making things work fine in Python 2.4.x for high enough x -- it's just that peephole.c's efforts are defeated by a similar optimization applied without specialcase checking in ast.c in Python 2.5. This is inconsistent: it makes no sense to take SOME of the precautions needed to avoid an issue but not ALL of them, since this makes the issue appear anyway, so those precautions that ARE taken are there for no purpose (except a miniscule slowdown and enlargement of the interpreter:-). Either we save those few lines of code in peephole.c or add the few lines to ast.c that I suggest in my patch 1678668 -- the current situation makes no sense. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-12 02:04 Message: Logged In: YES user_id=21627 Originator: NO I also expressed myself badly. I not only meant that programs should not rely on +0 and -0 being different things across platforms, but that they should also not rely on them being either always different or always the same in a single program. If Python would randomly chose to interpret +0 as -0, or would do so for every third occurence, I still couldn't see a problem. ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2007-03-11 18:54 Message: Logged In: YES user_id=60314 Originator: NO Oops,sorry, I meant patch 1678668 (copy-and-pasted the wrong ID:-). Alex ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2007-03-11 18:51 Message: Logged In: YES user_id=60314 Originator: NO Also see my patch 1678380 which fixes this bug (and checks for it in a new unittest). ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-03-11 18:15 Message: Logged In: YES user_id=703403 Originator: YES I expressed myself badly. I apologise. This really isn't about +0. and -0. being different, or not. I'm perfectly comfortable with the idea that +0. and -0. may or may not be distinguishable on any given platform. The surprise is the other way around: two *identical* calls to atan(0., -1.) (or to repr(0.) for that matter) give *different* results, depending solely on whether a -0. literal has appeared earlier on in the code unit being compiled. So if the first float zero literal encountered in a source file just happens to be a -0. rather than a 0., the meaning of str(0.) later on suddenly becomes "-0.0" rather than "0.0". I'd like to be able to rely on str(0.) meaning "0.0" without having to worry about whether there might be a -0. literal appearing in some faraway and otherwise completely irrelevant portion of the file. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-11 15:27 Message: Logged In: YES user_id=21627 Originator: NO marketdickinson, you should ask this question (is this really acceptable) on python-dev. I find it perfectly acceptable. No program should rely on -0 and +0 being two different things (and thus also not relying on atan2 giving two different results). ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-03-11 13:10 Message: Logged In: YES user_id=479790 Originator: NO It appears to be a problem in the way compile.c handles literals. See http://mail.python.org/pipermail/python-list/2007-March/430302.html ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-03-11 12:21 Message: Logged In: YES user_id=703403 Originator: YES May I beg for reconsideration. Is the following really considered acceptable? >>> x = -0.; atan2(0., -1) -3.1415926535897931 >>> x = -(0.); atan2(0., -1) 3.1415926535897931 >>> atan2(0., -1) 3.1415926535897931 A single x = -0. at the start of a script can have side effects several hundred lines later, even when the variable x is never referred to again. I guess the advice should be: "To avoid surprises, -0. should never appear in any script." ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-11 11:35 Message: Logged In: YES user_id=21627 Originator: NO This is not a bug, at least not one that will be fixed. Details of the floating-point can vary across platforms, and they may behave in suprising ways in various contexts. Users shouldn't rely on Python differentiating between -0 and +0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678380&group_id=5470 From noreply at sourceforge.net Mon Mar 12 16:18:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 08:18:12 -0700 Subject: [ python-Bugs-1678647 ] Weird behavior Exception with unicode string Message-ID: Bugs item #1678647, was opened at 2007-03-12 00:20 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678647&group_id=5470 Please note that this 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: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Leandro Lucarella (llucax) Assigned to: M.-A. Lemburg (lemburg) Summary: Weird behavior Exception with unicode string Initial Comment: This simple python program: ------------------------------- raise Exception(u'Muri\u00f3') ------------------------------- prints: ----------------------------------- Traceback (most recent call last): File "pylog.py", line 1, in ? raise Exception(u'Muri\u00f3') Exception ----------------------------------- While not using an unicode character, seems to work fine (even if using an unicode parameter): -------------------------- raise Exception(u'Murio') -------------------------- prints: ----------------------------------- Traceback (most recent call last): File "pylog.py", line 1, in ? raise Exception(u'Murio') Exception: Murio ----------------------------------- This seems to break the logging module when calling logging.exception(u'Muri\u00f3'), for example. Tested in Python 2.4.4 and 2.5 (debian). ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 15:18 Message: Logged In: YES user_id=849994 Originator: NO I fixed the "prints no newline" problem in rev. 54288. There's nothing sensible we can do about the unicode conversion, so closing as "won't fix". You should always encode or repr() unicode exception arguments. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 14:14 Message: Logged In: YES user_id=849994 Originator: NO Yes, or more precisely, the unicode string is converted to a byte string using Python's default encoding, which is ASCII per default. ---------------------------------------------------------------------- Comment By: Leandro Lucarella (llucax) Date: 2007-03-12 14:03 Message: Logged In: YES user_id=240225 Originator: YES But why the conversion is failing in the first place? Because just plain 7 bits ASCII is expected? ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2007-03-12 04:43 Message: Logged In: YES user_id=55188 Originator: NO That's from line 1216-1230 of Python/pythonrun.c as in trunk. It tries PyObject_Str(exception) and skips printing line terminator when it failed. And the behavior came from r8084 (http://svn.python.org/view/python/trunk/Python/pythonrun.c?rev=8084&r1=8070&r2=8084). Hmm. I think it should put a LF even if the conversion failed. (encoding the unicode with "ignore" or "replace" would make some confusion and putting it in PyObject_Repr() makes inconsistency.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678647&group_id=5470 From noreply at sourceforge.net Mon Mar 12 16:39:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 08:39:31 -0700 Subject: [ python-Bugs-1678647 ] Weird behavior Exception with unicode string Message-ID: Bugs item #1678647, was opened at 2007-03-11 21:20 Message generated for change (Comment added) made by llucax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678647&group_id=5470 Please note that this 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: None Status: Closed Resolution: Wont Fix Priority: 5 Private: No Submitted By: Leandro Lucarella (llucax) Assigned to: M.-A. Lemburg (lemburg) Summary: Weird behavior Exception with unicode string Initial Comment: This simple python program: ------------------------------- raise Exception(u'Muri\u00f3') ------------------------------- prints: ----------------------------------- Traceback (most recent call last): File "pylog.py", line 1, in ? raise Exception(u'Muri\u00f3') Exception ----------------------------------- While not using an unicode character, seems to work fine (even if using an unicode parameter): -------------------------- raise Exception(u'Murio') -------------------------- prints: ----------------------------------- Traceback (most recent call last): File "pylog.py", line 1, in ? raise Exception(u'Murio') Exception: Murio ----------------------------------- This seems to break the logging module when calling logging.exception(u'Muri\u00f3'), for example. Tested in Python 2.4.4 and 2.5 (debian). ---------------------------------------------------------------------- >Comment By: Leandro Lucarella (llucax) Date: 2007-03-12 12:39 Message: Logged In: YES user_id=240225 Originator: YES > You should always encode or repr() unicode exception arguments. That's odd... :S At least it's any way to change the default Python encoding? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 12:18 Message: Logged In: YES user_id=849994 Originator: NO I fixed the "prints no newline" problem in rev. 54288. There's nothing sensible we can do about the unicode conversion, so closing as "won't fix". You should always encode or repr() unicode exception arguments. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 11:14 Message: Logged In: YES user_id=849994 Originator: NO Yes, or more precisely, the unicode string is converted to a byte string using Python's default encoding, which is ASCII per default. ---------------------------------------------------------------------- Comment By: Leandro Lucarella (llucax) Date: 2007-03-12 11:03 Message: Logged In: YES user_id=240225 Originator: YES But why the conversion is failing in the first place? Because just plain 7 bits ASCII is expected? ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2007-03-12 01:43 Message: Logged In: YES user_id=55188 Originator: NO That's from line 1216-1230 of Python/pythonrun.c as in trunk. It tries PyObject_Str(exception) and skips printing line terminator when it failed. And the behavior came from r8084 (http://svn.python.org/view/python/trunk/Python/pythonrun.c?rev=8084&r1=8070&r2=8084). Hmm. I think it should put a LF even if the conversion failed. (encoding the unicode with "ignore" or "replace" would make some confusion and putting it in PyObject_Repr() makes inconsistency.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678647&group_id=5470 From noreply at sourceforge.net Mon Mar 12 17:51:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 09:51:30 -0700 Subject: [ python-Bugs-742342 ] Python crashes if recursively reloading modules Message-ID: Bugs item #742342, was opened at 2003-05-23 10:03 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742342&group_id=5470 Please note that this 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.6 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Christian Eder (chris_ce) Assigned to: Nobody/Anonymous (nobody) Summary: Python crashes if recursively reloading modules Initial Comment: If one tries to recursively reload modules, python crashes with a segfault. e.g. if the file "foo.py" looks something like: import foo reload (foo) .... the python interpreter crashes when reading this file. I have been able to reproduce the problem both with python2.2 and python2.3 under linux. Although recursive reloads are faulty code, this should lead to an exception but not to a segfault of the interpreter. In our case, this bug allows a faulty user script to crash our program. Sorry if this is already a known bug, but I searched in Sorceforge (and also in Google) and did not find something similar. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-12 12:51 Message: Logged In: YES user_id=1344176 Originator: NO Fixed in r54291 (trunk), r54294 (release25-maint). Thanks for the bug report, Christian! ---------------------------------------------------------------------- Comment By: Christian Eder (chris_ce) Date: 2003-05-24 05:10 Message: Logged In: YES user_id=785436 You're right, there's nothing wrong with recursive imports (we also use them in our sources), but with recursive reloads. As far as I know the import statement reads the module only if it is not registered in sys.modules. If modules are added to sys.modules before they are parsed (as I suppose they are) a recursive import does no harm because the module is read only once. But I think the reload statement re-reads the file unconditionally (is it so ?) and may therefore cause an endless recursion. If the interpreter keeps a graph of files and the relations which file causes a reading of another file (either by importing a file which is not yet in sys.modules or by reloading), situations like recursive reloads could be easily detected as they would introduce cycles to the graph. However this is just an idea, maybe an implementation would cost too much permance. I will research the problem further and notice you if I find some kind of workaround. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-23 14:56 Message: Logged In: YES user_id=31435 The default recursion limit is unconditionally defined -- it doesn't vary across platforms. If you can submit a patch, that would help. Note that there's nothing wrong with (indirectly) recursive imports in Python (they're delicate but frequently used anyway), so we can't raise an exception on that. ---------------------------------------------------------------------- Comment By: Christian Eder (chris_ce) Date: 2003-05-23 14:30 Message: Logged In: YES user_id=785436 I tried it on 2 of our development PC's and got the following results on both of them: sys.getrecursionlimit () ===> 1000 python find_recursionlimit.py ===> 2800 Seems a bit strange, doesn't it ? I had expected the sys.recursionlimit to be higher than the actual limit. Anyway, recursive reloads are quite easy to detect, so shouldn't the interpreter detect such statements and raise an appropriate error exception (not resulting in a maximum recursion depth exceeded error) ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-05-23 12:01 Message: Logged In: YES user_id=31392 I expect this is a platform-specific problem with the Python recursion limit. Can you report two things? The value returned by sys.getrecursionlimit(), and the last limit reported by Misc/find_recursionlimit.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=742342&group_id=5470 From noreply at sourceforge.net Mon Mar 12 17:55:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 09:55:42 -0700 Subject: [ python-Bugs-1628987 ] inspect trouble when source file changes Message-ID: Bugs item #1628987, was opened at 2007-01-05 13:43 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1628987&group_id=5470 Please note that this 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 Private: No Submitted By: phil (philipdumont) Assigned to: Nobody/Anonymous (nobody) Summary: inspect trouble when source file changes Initial Comment: backtrace (relevant outer frames only): File "/path/to/myfile", line 1198, in get_hook_name for frame_record in inspect.stack(): File "/usr/mbench2.2/lib/python2.4/inspect.py", line 819, in stack return getouterframes(sys._getframe(1), context) File "/usr/mbench2.2/lib/python2.4/inspect.py", line 800, in getouterframes framelist.append((frame,) + getframeinfo(frame, context)) File "/usr/mbench2.2/lib/python2.4/inspect.py", line 775, in getframeinfo lines, lnum = findsource(frame) File "/usr/mbench2.2/lib/python2.4/inspect.py", line 437, in findsource if pat.match(lines[lnum]): break IndexError: list index out of range Based on a quick look at the inspect code, I think this happens when you: - Start python and load a module - While it's running, edit the source file for the module (before inspect tries to look into it). - Call a routine in the edited module that will lead to a call to inspect.stack(). During an inspect.stack() call, inspect will open source files to get the source code for the routines on the stack. If the source file that is opened doesn't match the byte compiled code that's being run, there are problems. Inspect caches the files it reads (using the linecache module), so if the file gets cached before it is edited, nothing should go wrong. But if the source file is edited after the module is loaded and before inspect has a chance to cache the source, you're out of luck. Of course, this shouldn't be a problem in production code, but it has bit us more than once in a development environment. Seems like it would be easy to avoid by just comparing the timestamps on the source/object files. If the source file is newer, just behave the same as if it wasn't there. Attached is a stupid little python script that reproduces the problem. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-09 18:18 Message: Logged In: YES user_id=1344176 Originator: NO """ To be able to fix this right, you'd have to know what the timestamp was on whatever file was loaded at the time that import loaded it. I guess import itself would have to stash this away somewhere. """ While I don't see this change being made, you might talk to Brett Cannon about it. He's working on a rewrite of the import machinery in Python and probably knows that system better than most by this point. Unless he/you can come up with something, though, I'm inclined to close the bug because of its provocation difficulty. ---------------------------------------------------------------------- Comment By: phil (philipdumont) Date: 2007-03-09 13:25 Message: Logged In: YES user_id=1364034 Originator: YES What I had in mind was something like changing: def getsourcefile(object): """Return the Python source file an object was defined in, if it exists.""" filename = getfile(object) if string.lower(filename[-4:]) in ['.pyc', '.pyo']: filename = filename[:-4] + '.py' # ...the rest of the function... to def getsourcefile(object): """Return the Python source file an object was defined in, if it exists.""" filename = getfile(object) if string.lower(filename[-4:]) in ['.pyc', '.pyo']: src_filename = filename[:-4] + '.py' try: # if src file has been edited since we loaded the obj file, ignore it if os.stat(filename).st_mtime > os.stat(src_filename).st_mtime: filename = src_filename except OSError: pass # ...the rest of the function... But now that I've tried to implement it, and thought about it a bit more, I see some of the issues with what I thought would be a simple fix: - I originally thought that, if a module is loaded from source (either because the objfile did not exist, or because objfile was older), and the compiled src was successfully written to a new objfile, that inspect.getfile() would return the path to the objfile. I see now that that is not the case; it returns the srcfile. That makes my fix a bit more difficult -- now you have to find out if there is an obj file, and if so, what it's called. And even if you had a handle on both the srcfile and the objfile: - Even if the srcfile's timestamp is newer than the objfile's, it doesn't necessarily mean that the srcfile has been edited since it was loaded. It could be that the srcfile was already newer than the objfile before the module was loaded, so the module was loaded from the srcfile, and the objfile was not updated because it was not writable by the user. - Even if the srcfile's timestamp is older than the objfile's, it doesn't necessarily mean that the srcfile represents what you have loaded in memory. It could be that after you loaded the module, your colleague down the hall edited the source, loaded the module, and in the process was successful in updating the objfile. (Not a likely scenario, but...) - If the module was loaded from source, there was no objfile, and an objfile could not be created because the directory was not writable, the fix doesn't help at all. To be able to fix this right, you'd have to know what the timestamp was on whatever file was loaded at the time that import loaded it. I guess import itself would have to stash this away somewhere. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-08 16:19 Message: Logged In: YES user_id=1344176 Originator: NO Could you possibly work up a patch demonstrating exactly what you're proposing with the "comparing the timestamps" solution? That seems like a lot of complication for such a rare issue, but I'd be interested in seeing a patch all the same. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1628987&group_id=5470 From noreply at sourceforge.net Mon Mar 12 21:06:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 13:06:41 -0700 Subject: [ python-Feature Requests-1673203 ] add identity function Message-ID: Feature Requests item #1673203, was opened at 2007-03-03 16:21 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 Please note that this 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 Private: No Submitted By: paul rubin (phr) Assigned to: Raymond Hettinger (rhettinger) Summary: add identity function Initial Comment: Requested and assigned to Raymond at his suggestion: http://groups.google.com/group/comp.lang.python/msg/603870361743c85c There should be an identify function identity(x)=x. I suggest it also take and ignore an optional second arg: identity(x1,x2)=x1. The second arg can be useful in some generator expressions: foo = (x for x in bar if condition(x) and identity(True, memoize(x)) That allows calling memoize (or some other function) on the selected elements in the genexp, and disposing of the returned value. It's sort of like the const function (K combinator) to go along with the identity function's I combinator. OK, the above is not really in the functional spirit, but it's been useful. There could conceivably be also an actual const function const(k)=partial(identity,k) but I can't remember needing that in Python code. The two-arg identity function (uncurried version of const) is probably enough. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-12 13:06 Message: Logged In: YES user_id=341410 Originator: NO Not all x line functions should be built into Python. Further, Python's standard syntax offers an infix operator that does the same thing (though in slightly different order as described below, you can reorder with minimal effort). identity(X, Y) -> (Y and False) or X Also, the only use-case that you are provided and that I can imagine, are examples like you provide where one is changing state within a statement (if, elif, while, etc.) or expression (generator, list comprehension, conditional, etc.). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 06:21 Message: Logged In: YES user_id=835142 Originator: NO 1. If this proposal is accepted, it will make sense to deprecate the use of None as an identity function in map: >>> map(None, range(10)) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] 2. Some other languages have an dyadic identity function that returns the *second* argument. For example, K has : primitive: identity:(:) identity[1;2] 2 The rationale in K is that it is useful in an ammed function that replaces entries of an an array with a result of a dyadic function applied to the old and the supplied value and it is natural to have old value first: @[1 2 3;1;-;20] 1 -18 3 @[1 2 3;1;:;20] 1 20 3 This rationale does not apply to Python, but in the absence of other reasons to choose the order of arguments, Python may as well follow the precedent. Does anyone know a less exotic language that has a dyadic identity? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 From noreply at sourceforge.net Mon Mar 12 23:46:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 15:46:59 -0700 Subject: [ python-Bugs-1630844 ] fnmatch.translate undocumented Message-ID: Bugs item #1630844, was opened at 2007-01-08 20:29 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630844&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gabriel Genellina (gagenellina) Assigned to: Nobody/Anonymous (nobody) Summary: fnmatch.translate undocumented Initial Comment: fnmatch.translate is not documented, but it is menctioned on the module docstring and in __all__, so it appears to be public. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-12 23:46 Message: Logged In: YES user_id=51702 Originator: NO Patch #1679379 should fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630844&group_id=5470 From noreply at sourceforge.net Tue Mar 13 03:20:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 19:20:03 -0700 Subject: [ python-Bugs-1667877 ] Install fails with no error Message-ID: <200703130220.l2D2K3Mv024423@sc8-sf-db2-new-b.sourceforge.net> Bugs item #1667877, was opened at 2007-02-24 08:10 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1667877&group_id=5470 Please note that this 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: Closed Resolution: Wont Fix Priority: 5 Private: No Submitted By: larry (widgeteye) Assigned to: Nobody/Anonymous (nobody) Summary: Install fails with no error Initial Comment: When I built python 2.5 for linux I did the normal: configure make make install Everything went fine til the "make install" part. It dies with no error. just says "install failed" after this: Compiling /usr/local/lib/python2.5/zipfile.py That part built fine but the next part failed. So what I did being the industrious fellow that I am I did: make -n install > out Took the out file and did: sh out That installed python without failure. Now if I do "make install" everything works fine. Weird eh? ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-03-12 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-02-25 22:21 Message: Logged In: YES user_id=21627 Originator: NO Can you reproduce the problem on your system? Can you give instructions on how to reproduce it on another system? If not, I see little chance to resolve this problem. ---------------------------------------------------------------------- Comment By: larry (widgeteye) Date: 2007-02-25 22:11 Message: Logged In: YES user_id=402539 Originator: YES I think you missed the point I was trying to make. When I say "works fine" I mean that after I installed python using the shell script, then I could run "make install" and it would complete the install using make without failure. ---------------------------------------------------------------------- Comment By: larry (widgeteye) Date: 2007-02-25 22:10 Message: Logged In: YES user_id=402539 Originator: YES I think you missed the point I was trying to make. When I say "works fine" I mean that after I installed python using the shell script, then I could run "make install" and it would complete the install using make without failure. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-02-25 14:01 Message: Logged In: YES user_id=21627 Originator: NO I'm not finding it weird that the shell script completed. I doubt it "works fine", though. Instead, some command in it failed, but the shell doesn't abort in this case - make would abort. Typically, when byte-compilation fails, it is because you have a file byte-compiled that has a syntax error in it. Scroll through the entire compileall output to see what the actual problem is. Tentatively closing this as "won't fix". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1667877&group_id=5470 From noreply at sourceforge.net Tue Mar 13 03:28:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 19:28:05 -0700 Subject: [ python-Bugs-1679498 ] Lib/io.py open uses unset "bs" Message-ID: Bugs item #1679498, was opened at 2007-03-12 22: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=1679498&group_id=5470 Please note that this 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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: Lib/io.py open uses unset "bs" Initial Comment: Within the open function, it says """ try: bs = os.fstat(raw.fileno()).st_blksize except (os.error, AttributeError): if bs > 1: buffering = bs """ Since this is the first use of name "bs", I wouldn't expect it to have any value after an Exception. If this is actually correct, it at least deserves a comment. ----------------- (second issue) _PyFileIO sets self._writable but doesn't use it (even in writable()) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1679498&group_id=5470 From noreply at sourceforge.net Tue Mar 13 04:32:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 20:32:13 -0700 Subject: [ python-Bugs-1675511 ] Python still uses broken -xcode option on Solaris/x86 Message-ID: Bugs item #1675511, was opened at 2007-03-07 15:54 Message generated for change (Comment added) made by jlick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: Python still uses broken -xcode option on Solaris/x86 Initial Comment: Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting a new bug against 2.5 in the hopes that someone will read it... text updated with minor corrections. Python 2.5, Solaris x86 10 Update 3, Sun Studio 11 xcode=pic32 option is not supported on Solaris x86 Sun C . Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when any compiler other than gcc is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates an error that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-13 11:32 Message: Logged In: YES user_id=673069 Originator: NO The patch I posted in the last comment also will apply (with warning) to Python 2.4.4 and builds OK. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-12 18:52 Message: Logged In: YES user_id=21627 Originator: NO Thanks for the patch. Committed as r54283 and r54284. ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-12 17:52 Message: Logged In: YES user_id=673069 Originator: NO The patch I posted in the last comment also will apply (with warning) to Python 2.4.4 and builds OK. ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-12 15:37 Message: Logged In: YES user_id=673069 Originator: NO I've made a patch for configure.in to fix this bug. There are two notes to explain why it was written the way it is: The first problem is to determine which processor type we are using. 'uname -p' was chosen because it returns the most generic response on both SPARC (sparc) and x86/x64 (i386) systems. There is some controversy about why it returns 'i386' even on Pentium or AMD64 systems, but Sun points to the isainfo, isalist, or psrinfo commands to get more specific processor information, so it appears they don't intend to change the behavior. The second choice is how to handle the default case if the result of the above is neither sparc or i386. I chose to use '-xcode=pic32' for sparc only, and '-Kpic' for all other responses. My reasoning is that since -Kpic existed before -xcode=pic32 was implemented that it is the more generic option, even though it and -KPIC are deprecated on sparc. I am therefore making the assumption that any possible new platforms supported by Studio 11 would in some fashion support -Kpic. This patch is a diff against Python 2.5's configure.in file. I've tested it against a Solaris 10 32-bit x86 system and a Solaris 10 64-bit sparc system both with Studio 11 installed. I don't have a 64-bit x86 system to test against. The build is mostly successful on both though there is a problem with the _ctypes module which causes test_ctypes to fail. This is a known problem covered by other bug reports which I believe is unrelated to this patch. I couldn't find the option to upload a file, so here is the patch inline: ---snip--- *** configure.in.old 2007-03-11 23:01:16.879612000 -0700 --- configure.in 2007-03-11 23:31:48.098734000 -0700 *************** *** 1543,1551 **** then case $ac_sys_system/$ac_sys_release in SunOS*) if test "$GCC" = yes; ! then CCSHARED="-fPIC"; ! else CCSHARED="-xcode=pic32"; ! fi;; hp*|HP*) if test "$GCC" = yes; then CCSHARED="-fPIC"; else CCSHARED="+z"; --- 1543,1553 ---- then case $ac_sys_system/$ac_sys_release in SunOS*) if test "$GCC" = yes; ! then CCSHARED="-fPIC"; ! elif test `uname -p` = sparc; ! then CCSHARED="-xcode=pic32"; ! else CCSHARED="-Kpic"; ! fi;; hp*|HP*) if test "$GCC" = yes; then CCSHARED="-fPIC"; else CCSHARED="+z"; ---snip--- ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-11 03:06 Message: Logged In: YES user_id=21627 Originator: NO The manual claims (in "Supported Platforms") that "x86" refers to both 32-bit and 64-bit systems, and promises to use "32-bit x86" for 32-bit specific information, so I guess -Kpic works on AMD64 as well. ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-11 02:35 Message: Logged In: YES user_id=673069 Originator: NO According the the Studio 11 man page for cc '-KPIC' is an alias for '-Kpic' on x86, though it doesn't explicitly say whether this applies to x86 meaning 32 bit only or x86 meaning both 32 and 64 bit. In any case, since -KPIC is definitely equivalent to -Kpic on 32 bit x86, and -KPIC is known to work on x64, should we just use -KPIC for both? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-11 01:07 Message: Logged In: YES user_id=21627 Originator: NO Looks fine, although you might want to consider AMD64 as well. I think it should be -KPIC (although I'm uncertain whether Python works on that system at all). See http://blogs.sun.com/x86be/category/Sun ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-11 00:14 Message: Logged In: YES user_id=673069 Originator: NO I'm willing to take a stab at a patch. I've reviewed the Sun Studio 11 documentation and it appears that the preferred options are: Sun cc Sparc: -xcode=pic32 Sun cc X86: -Kpic Does that match the way you read it, loewis? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-09 16:56 Message: Logged In: YES user_id=21627 Originator: NO I don't want to make a change now, just to have to deal with a bug report two years from now which then will sit again in this tracker for years again. I'm fine with documenting that older SunPRO compilers are not supported; -xcode has been supported atleast since Sun Forte 6 (released in 2000); earlier products had reached their end-of-life long ago. So either this gets fixed properly now, or not at all. ---------------------------------------------------------------------- Comment By: Carson Gaspar (cgaspar) Date: 2007-03-09 16:06 Message: Logged In: YES user_id=664506 Originator: YES While the doc labels the -KPIC option as "obsolete" for SPARC, it works fine. Perhaps Studio 12 will break it, but all current compilers understand it fine. If you want to be pedantically correct and use -xcode=pic32, you don't need an architecture test, you need to actually _try_ the option, as older SPARC compilers won't accept it either. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-09 15:08 Message: Logged In: YES user_id=21627 Originator: NO One problem is that the proposed change is incorrect. According to the C User's Guide of Sun Studio 11 (document 819-3688-10), -KPIC is an obsolete option on SPARC, and should be replaced with -xcode=pic32 (section A.1.15). So I think a patch should be architecture-specific. Can somebody come up with a patch that does that? ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-07 16:34 Message: Logged In: YES user_id=673069 Originator: NO Perhaps I was unclear in bug #1561333 that this resulted in only a warning. Actually the build will fail because of the incorrect flag. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 From noreply at sourceforge.net Tue Mar 13 05:53:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 21:53:52 -0700 Subject: [ python-Bugs-1659171 ] Calling tparm from extension lib fails in Python 2.5 Message-ID: Bugs item #1659171, was opened at 2007-02-13 09:27 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659171&group_id=5470 Please note that this 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 Private: No Submitted By: Richard B. Kreckel (richyk) Assigned to: Nobody/Anonymous (nobody) Summary: Calling tparm from extension lib fails in Python 2.5 Initial Comment: Attached is a little C++ module that fetches the terminal capability string for turning off all attributes and runs it through tparm(). (All this is done in a static Ctor of a class without init function, but never mind.) Compile with: g++ -c testlib.cc g++ testlib.o -o testlib.so -shared -Wl,-soname,testlib.so -lncurses On SuSE Linux 10.1 (and older), I get the expected behavior: Python 2.4.2 (#1, Oct 13 2006, 17:11:24) [GCC 4.1.0 (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import testlib Terminal is "xterm" Dump of sgr0: 1b 5b 30 6d Dump of instance: 1b 5b 30 6d Traceback (most recent call last): File "", line 1, in ? ImportError: dynamic module does not define init function (inittestlib) >>> However, on SuSE Linux 10.2, tparm creates a NULL pointer: Python 2.5 (r25:51908, Jan 9 2007, 16:59:32) [GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import testlib Terminal is "xterm" Dump of sgr0: 1b 5b 30 6d Rats! tparm made a NULL pointer! Traceback (most recent call last): File "", line 1, in ImportError: dynamic module does not define init function (inittestlib) >>> Why, oh why? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-12 21:53 Message: Logged In: YES user_id=33168 Originator: NO I can't help with the time factor, but I can with the access to svn. You can download a snapshot here: http://svn.python.org/snapshots/python25.tar.bz2 There are snapshots for the trunk as well as the active release branch. So if you can get a little free time, it would be great if you could download the tarball and test. Thanks. ---------------------------------------------------------------------- Comment By: Richard B. Kreckel (richyk) Date: 2007-03-12 04:30 Message: Logged In: YES user_id=1718463 Originator: YES Sorry, I cannot do that test anytime soon. (I've not enough time and my company doesn't let me access your SVN.) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-02-25 14:16 Message: Logged In: YES user_id=33168 Originator: NO Can you test with 2.5 from SVN and confirm your program works in the complete context? ---------------------------------------------------------------------- Comment By: Richard B. Kreckel (richyk) Date: 2007-02-22 04:25 Message: Logged In: YES user_id=1718463 Originator: YES The error message about the undefined init function is a red herring. The example is actually a stripped-down testcase from a much larger Boost.Python module, which of course does have an init function. The point here is the NULL pointer returned by tparm. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-02-14 13:24 Message: Logged In: YES user_id=21627 Originator: NO I fail to see the bug. The exception precisely describes the error in your code ImportError: dynamic module does not define init function (inittestlib) Why do you expect any meaningful behavior in the presence of this error? Your shared library isn't an extension module. If you think it is related to #1548092, please try out the subversion trunk, which has fixed this bug. ---------------------------------------------------------------------- Comment By: Richard B. Kreckel (richyk) Date: 2007-02-14 00:52 Message: Logged In: YES user_id=1718463 Originator: YES I suspect that this is a duplicate of Bug [1548092]. Note that, there it is asserted that tparm returns NULL on certain invalid strings. That does not seem to be true. It returns NULL for valid trivial strings, too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1659171&group_id=5470 From noreply at sourceforge.net Tue Mar 13 06:34:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 22:34:52 -0700 Subject: [ python-Bugs-1675511 ] Python still uses broken -xcode option on Solaris/x86 Message-ID: Bugs item #1675511, was opened at 2007-03-07 08:54 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: Python still uses broken -xcode option on Solaris/x86 Initial Comment: Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting a new bug against 2.5 in the hopes that someone will read it... text updated with minor corrections. Python 2.5, Solaris x86 10 Update 3, Sun Studio 11 xcode=pic32 option is not supported on Solaris x86 Sun C . Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when any compiler other than gcc is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates an error that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-13 06:34 Message: Logged In: YES user_id=21627 Originator: NO I won't apply the patch to the 2.4 branch, as that branch is not actively maintained anymore. ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-13 04:32 Message: Logged In: YES user_id=673069 Originator: NO The patch I posted in the last comment also will apply (with warning) to Python 2.4.4 and builds OK. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-12 11:52 Message: Logged In: YES user_id=21627 Originator: NO Thanks for the patch. Committed as r54283 and r54284. ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-12 10:52 Message: Logged In: YES user_id=673069 Originator: NO The patch I posted in the last comment also will apply (with warning) to Python 2.4.4 and builds OK. ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-12 08:37 Message: Logged In: YES user_id=673069 Originator: NO I've made a patch for configure.in to fix this bug. There are two notes to explain why it was written the way it is: The first problem is to determine which processor type we are using. 'uname -p' was chosen because it returns the most generic response on both SPARC (sparc) and x86/x64 (i386) systems. There is some controversy about why it returns 'i386' even on Pentium or AMD64 systems, but Sun points to the isainfo, isalist, or psrinfo commands to get more specific processor information, so it appears they don't intend to change the behavior. The second choice is how to handle the default case if the result of the above is neither sparc or i386. I chose to use '-xcode=pic32' for sparc only, and '-Kpic' for all other responses. My reasoning is that since -Kpic existed before -xcode=pic32 was implemented that it is the more generic option, even though it and -KPIC are deprecated on sparc. I am therefore making the assumption that any possible new platforms supported by Studio 11 would in some fashion support -Kpic. This patch is a diff against Python 2.5's configure.in file. I've tested it against a Solaris 10 32-bit x86 system and a Solaris 10 64-bit sparc system both with Studio 11 installed. I don't have a 64-bit x86 system to test against. The build is mostly successful on both though there is a problem with the _ctypes module which causes test_ctypes to fail. This is a known problem covered by other bug reports which I believe is unrelated to this patch. I couldn't find the option to upload a file, so here is the patch inline: ---snip--- *** configure.in.old 2007-03-11 23:01:16.879612000 -0700 --- configure.in 2007-03-11 23:31:48.098734000 -0700 *************** *** 1543,1551 **** then case $ac_sys_system/$ac_sys_release in SunOS*) if test "$GCC" = yes; ! then CCSHARED="-fPIC"; ! else CCSHARED="-xcode=pic32"; ! fi;; hp*|HP*) if test "$GCC" = yes; then CCSHARED="-fPIC"; else CCSHARED="+z"; --- 1543,1553 ---- then case $ac_sys_system/$ac_sys_release in SunOS*) if test "$GCC" = yes; ! then CCSHARED="-fPIC"; ! elif test `uname -p` = sparc; ! then CCSHARED="-xcode=pic32"; ! else CCSHARED="-Kpic"; ! fi;; hp*|HP*) if test "$GCC" = yes; then CCSHARED="-fPIC"; else CCSHARED="+z"; ---snip--- ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-10 20:06 Message: Logged In: YES user_id=21627 Originator: NO The manual claims (in "Supported Platforms") that "x86" refers to both 32-bit and 64-bit systems, and promises to use "32-bit x86" for 32-bit specific information, so I guess -Kpic works on AMD64 as well. ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-10 19:35 Message: Logged In: YES user_id=673069 Originator: NO According the the Studio 11 man page for cc '-KPIC' is an alias for '-Kpic' on x86, though it doesn't explicitly say whether this applies to x86 meaning 32 bit only or x86 meaning both 32 and 64 bit. In any case, since -KPIC is definitely equivalent to -Kpic on 32 bit x86, and -KPIC is known to work on x64, should we just use -KPIC for both? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-10 18:07 Message: Logged In: YES user_id=21627 Originator: NO Looks fine, although you might want to consider AMD64 as well. I think it should be -KPIC (although I'm uncertain whether Python works on that system at all). See http://blogs.sun.com/x86be/category/Sun ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-10 17:14 Message: Logged In: YES user_id=673069 Originator: NO I'm willing to take a stab at a patch. I've reviewed the Sun Studio 11 documentation and it appears that the preferred options are: Sun cc Sparc: -xcode=pic32 Sun cc X86: -Kpic Does that match the way you read it, loewis? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-09 09:56 Message: Logged In: YES user_id=21627 Originator: NO I don't want to make a change now, just to have to deal with a bug report two years from now which then will sit again in this tracker for years again. I'm fine with documenting that older SunPRO compilers are not supported; -xcode has been supported atleast since Sun Forte 6 (released in 2000); earlier products had reached their end-of-life long ago. So either this gets fixed properly now, or not at all. ---------------------------------------------------------------------- Comment By: Carson Gaspar (cgaspar) Date: 2007-03-09 09:06 Message: Logged In: YES user_id=664506 Originator: YES While the doc labels the -KPIC option as "obsolete" for SPARC, it works fine. Perhaps Studio 12 will break it, but all current compilers understand it fine. If you want to be pedantically correct and use -xcode=pic32, you don't need an architecture test, you need to actually _try_ the option, as older SPARC compilers won't accept it either. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-09 08:08 Message: Logged In: YES user_id=21627 Originator: NO One problem is that the proposed change is incorrect. According to the C User's Guide of Sun Studio 11 (document 819-3688-10), -KPIC is an obsolete option on SPARC, and should be replaced with -xcode=pic32 (section A.1.15). So I think a patch should be architecture-specific. Can somebody come up with a patch that does that? ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-07 09:34 Message: Logged In: YES user_id=673069 Originator: NO Perhaps I was unclear in bug #1561333 that this resulted in only a warning. Actually the build will fail because of the incorrect flag. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 From noreply at sourceforge.net Tue Mar 13 06:55:21 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 22:55:21 -0700 Subject: [ python-Bugs-1675511 ] Python still uses broken -xcode option on Solaris/x86 Message-ID: Bugs item #1675511, was opened at 2007-03-07 15:54 Message generated for change (Comment added) made by jlick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: Python still uses broken -xcode option on Solaris/x86 Initial Comment: Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting a new bug against 2.5 in the hopes that someone will read it... text updated with minor corrections. Python 2.5, Solaris x86 10 Update 3, Sun Studio 11 xcode=pic32 option is not supported on Solaris x86 Sun C . Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when any compiler other than gcc is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates an error that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-13 13:55 Message: Logged In: YES user_id=673069 Originator: NO Sorry, not sure where the duplicate comment came from. That was just an FYI anyways. I'm fine with the fix only coming out in the 2.5 branch. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-13 13:34 Message: Logged In: YES user_id=21627 Originator: NO I won't apply the patch to the 2.4 branch, as that branch is not actively maintained anymore. ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-13 11:32 Message: Logged In: YES user_id=673069 Originator: NO The patch I posted in the last comment also will apply (with warning) to Python 2.4.4 and builds OK. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-12 18:52 Message: Logged In: YES user_id=21627 Originator: NO Thanks for the patch. Committed as r54283 and r54284. ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-12 17:52 Message: Logged In: YES user_id=673069 Originator: NO The patch I posted in the last comment also will apply (with warning) to Python 2.4.4 and builds OK. ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-12 15:37 Message: Logged In: YES user_id=673069 Originator: NO I've made a patch for configure.in to fix this bug. There are two notes to explain why it was written the way it is: The first problem is to determine which processor type we are using. 'uname -p' was chosen because it returns the most generic response on both SPARC (sparc) and x86/x64 (i386) systems. There is some controversy about why it returns 'i386' even on Pentium or AMD64 systems, but Sun points to the isainfo, isalist, or psrinfo commands to get more specific processor information, so it appears they don't intend to change the behavior. The second choice is how to handle the default case if the result of the above is neither sparc or i386. I chose to use '-xcode=pic32' for sparc only, and '-Kpic' for all other responses. My reasoning is that since -Kpic existed before -xcode=pic32 was implemented that it is the more generic option, even though it and -KPIC are deprecated on sparc. I am therefore making the assumption that any possible new platforms supported by Studio 11 would in some fashion support -Kpic. This patch is a diff against Python 2.5's configure.in file. I've tested it against a Solaris 10 32-bit x86 system and a Solaris 10 64-bit sparc system both with Studio 11 installed. I don't have a 64-bit x86 system to test against. The build is mostly successful on both though there is a problem with the _ctypes module which causes test_ctypes to fail. This is a known problem covered by other bug reports which I believe is unrelated to this patch. I couldn't find the option to upload a file, so here is the patch inline: ---snip--- *** configure.in.old 2007-03-11 23:01:16.879612000 -0700 --- configure.in 2007-03-11 23:31:48.098734000 -0700 *************** *** 1543,1551 **** then case $ac_sys_system/$ac_sys_release in SunOS*) if test "$GCC" = yes; ! then CCSHARED="-fPIC"; ! else CCSHARED="-xcode=pic32"; ! fi;; hp*|HP*) if test "$GCC" = yes; then CCSHARED="-fPIC"; else CCSHARED="+z"; --- 1543,1553 ---- then case $ac_sys_system/$ac_sys_release in SunOS*) if test "$GCC" = yes; ! then CCSHARED="-fPIC"; ! elif test `uname -p` = sparc; ! then CCSHARED="-xcode=pic32"; ! else CCSHARED="-Kpic"; ! fi;; hp*|HP*) if test "$GCC" = yes; then CCSHARED="-fPIC"; else CCSHARED="+z"; ---snip--- ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-11 03:06 Message: Logged In: YES user_id=21627 Originator: NO The manual claims (in "Supported Platforms") that "x86" refers to both 32-bit and 64-bit systems, and promises to use "32-bit x86" for 32-bit specific information, so I guess -Kpic works on AMD64 as well. ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-11 02:35 Message: Logged In: YES user_id=673069 Originator: NO According the the Studio 11 man page for cc '-KPIC' is an alias for '-Kpic' on x86, though it doesn't explicitly say whether this applies to x86 meaning 32 bit only or x86 meaning both 32 and 64 bit. In any case, since -KPIC is definitely equivalent to -Kpic on 32 bit x86, and -KPIC is known to work on x64, should we just use -KPIC for both? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-11 01:07 Message: Logged In: YES user_id=21627 Originator: NO Looks fine, although you might want to consider AMD64 as well. I think it should be -KPIC (although I'm uncertain whether Python works on that system at all). See http://blogs.sun.com/x86be/category/Sun ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-11 00:14 Message: Logged In: YES user_id=673069 Originator: NO I'm willing to take a stab at a patch. I've reviewed the Sun Studio 11 documentation and it appears that the preferred options are: Sun cc Sparc: -xcode=pic32 Sun cc X86: -Kpic Does that match the way you read it, loewis? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-09 16:56 Message: Logged In: YES user_id=21627 Originator: NO I don't want to make a change now, just to have to deal with a bug report two years from now which then will sit again in this tracker for years again. I'm fine with documenting that older SunPRO compilers are not supported; -xcode has been supported atleast since Sun Forte 6 (released in 2000); earlier products had reached their end-of-life long ago. So either this gets fixed properly now, or not at all. ---------------------------------------------------------------------- Comment By: Carson Gaspar (cgaspar) Date: 2007-03-09 16:06 Message: Logged In: YES user_id=664506 Originator: YES While the doc labels the -KPIC option as "obsolete" for SPARC, it works fine. Perhaps Studio 12 will break it, but all current compilers understand it fine. If you want to be pedantically correct and use -xcode=pic32, you don't need an architecture test, you need to actually _try_ the option, as older SPARC compilers won't accept it either. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-09 15:08 Message: Logged In: YES user_id=21627 Originator: NO One problem is that the proposed change is incorrect. According to the C User's Guide of Sun Studio 11 (document 819-3688-10), -KPIC is an obsolete option on SPARC, and should be replaced with -xcode=pic32 (section A.1.15). So I think a patch should be architecture-specific. Can somebody come up with a patch that does that? ---------------------------------------------------------------------- Comment By: James Lick (jlick) Date: 2007-03-07 16:34 Message: Logged In: YES user_id=673069 Originator: NO Perhaps I was unclear in bug #1561333 that this resulted in only a warning. Actually the build will fail because of the incorrect flag. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 From noreply at sourceforge.net Tue Mar 13 08:52:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 00:52:04 -0700 Subject: [ python-Bugs-1630844 ] fnmatch.translate undocumented Message-ID: Bugs item #1630844, was opened at 2007-01-08 19:29 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630844&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Gabriel Genellina (gagenellina) Assigned to: Nobody/Anonymous (nobody) Summary: fnmatch.translate undocumented Initial Comment: fnmatch.translate is not documented, but it is menctioned on the module docstring and in __all__, so it appears to be public. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 07:52 Message: Logged In: YES user_id=849994 Originator: NO The patch has been applied, so closing this. Thanks for the report! ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-12 22:46 Message: Logged In: YES user_id=51702 Originator: NO Patch #1679379 should fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630844&group_id=5470 From noreply at sourceforge.net Tue Mar 13 09:15:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 01:15:26 -0700 Subject: [ python-Bugs-1591774 ] Urllib2.urlopen() raises OSError w/bad HTTP Location header Message-ID: Bugs item #1591774, was opened at 2006-11-07 03:08 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591774&group_id=5470 Please note that this 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.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: nikitathespider (nikitathespider) Assigned to: Nobody/Anonymous (nobody) Summary: Urllib2.urlopen() raises OSError w/bad HTTP Location header Initial Comment: The documentation for urllib2.urlopen() says that it "[r]aises URLError on errors". But if urllib2 requests a resource from a (misconfigured) Web server and that server returns 302 response with the Location header set to "file:", urlopen raises "OSError: [Errno 2] No such file or directory: ''". I have seen such a misconfiguration in the wild; I've also created a URL on my server that reproduces the problem in case the real-world URL disappears or is fixed. Both URLs are in the attachment with code to reproduce the problem. I can recreate this under Python 2.3 - 2.5 under Mac OS X, FreeBSD and Win2k. I would be satisfied if the module simply followed the documentation and actually returned URLError. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 08:15 Message: Logged In: YES user_id=849994 Originator: NO Fixed with said patch. Thanks for the report! ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-02-24 23:23 Message: Logged In: YES user_id=1727609 Originator: NO Fix submitted in patch 1668100 - urllib2.urlopen() raises OSError instead of URLError http://sourceforge.net/tracker/index.php?func=detail&aid=1668100&group_id=5470&atid=305470 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591774&group_id=5470 From noreply at sourceforge.net Tue Mar 13 10:32:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 02:32:53 -0700 Subject: [ python-Feature Requests-1634717 ] csv.DictWriter: Include offending name in error message Message-ID: Feature Requests item #1634717, was opened at 2007-01-13 14:53 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1634717&group_id=5470 Please note that this 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: Accepted Priority: 5 Private: No Submitted By: Gabriel Genellina (gagenellina) Assigned to: Nobody/Anonymous (nobody) Summary: csv.DictWriter: Include offending name in error message Initial Comment: In csv.py, class DictWriter, method _dict_to_list, when rowdict contains a key that is not a known field name, a ValueError is raised, but no reference to the offending name is given. As the code iterates along the dict keys, and stops at the first unknown one, its trivial to include such information. Replace lines: if k not in self.fieldnames: raise ValueError, "dict contains fields not in fieldnames" with: if k not in self.fieldnames: raise ValueError, "dict contains field not in fieldnames: %r" % k ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 09:32 Message: Logged In: YES user_id=849994 Originator: NO Patch was applied, closing this as Accepted. ---------------------------------------------------------------------- Comment By: Mark Roberts (mark-roberts) Date: 2007-01-15 00:04 Message: Logged In: YES user_id=1591633 Originator: NO Even better would be a list of all extraneous fields fields. I offered patch 1635454. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1634717&group_id=5470 From noreply at sourceforge.net Tue Mar 13 10:57:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 02:57:53 -0700 Subject: [ python-Bugs-1679652 ] error in the sys module documentation Message-ID: Bugs item #1679652, was opened at 2007-03-13 10: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=1679652&group_id=5470 Please note that this 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 Private: No Submitted By: David Fillinger (daikinoko) Assigned to: Nobody/Anonymous (nobody) Summary: error in the sys module documentation Initial Comment: In this text from the sys module documentation: http://docs.python.org/lib/module-sys.html "argv The list of command line arguments passed to a Python script. argv[0] is the script name (it is operating system dependent whether this is a full pathname or not). If the command was executed using the -c command line option to the interpreter, argv[0] is set to the string '-c'. If no script name was passed to the Python interpreter, argv has zero length." the second argv[0] should be argv[1] because argv[0] is the name of the script. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1679652&group_id=5470 From noreply at sourceforge.net Tue Mar 13 12:25:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 04:25:12 -0700 Subject: [ python-Bugs-1622896 ] Exception when compressing certain data with bz2 Message-ID: Bugs item #1622896, was opened at 2006-12-27 14:26 Message generated for change (Comment added) made by indi4source You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1622896&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alex Gontmakher (gsasha) Assigned to: Nobody/Anonymous (nobody) Summary: Exception when compressing certain data with bz2 Initial Comment: Looks like an out-of-bounds array access... might be a security problem. The attached file includes a script which, when executed, tries to pack the two given directories with a bz2 compressor. On my machine (stock 32 bit Ubuntu Edgy), the program fails with the following exception: -------------------- Traceback (most recent call last): File "test.py", line 13, in ? block = compressor.compress(open("compress-0067/"+file, "rb").read()) ValueError: the bz2 library has received wrong parameters -------------------- The problem occurs under either python2.4 or 2.5 (I don't have other versions to test with). Sorry, the file is large... I tried to reduce the example to smaller number of files etc., but no such luck. The file is too large to be submitted here as an attachment, so I have uploaded it to http://www.cs.technion.ac.il/~gsasha/testcase.tar.bz2 ---------------------------------------------------------------------- Comment By: ralf (indi4source) Date: 2007-03-13 12:25 Message: Logged In: YES user_id=1182990 Originator: NO I had the same problem with the BZ2Compressor. (reproducible under 2.5) It was working fine with BZ2File. Unfortunately I cannot check the proposed fix as I don't have the environment to compile python... ---------------------------------------------------------------------- Comment By: Alex Gontmakher (gsasha) Date: 2006-12-28 10:17 Message: Logged In: YES user_id=47707 Originator: YES I saw that the effect occurs only when one compressor finishes and is destroyed, and then the second one gives the "wrong parameters". Usually, for such an effect to happen, the first compressor must have some permanent effect on the system - and since it was destroyed before the second one was created, it was only natural to assume that the reason was an out of bounds access. My approach is that such a bug should be suspected as an out-of-bounds access until shown othervise, especially in a language like Python where it is natural to assume that such problems shouldn't occur and that it is safe to use security-wise. Of course I'll be happy to learn that it's just a simple bug. On a related note, will the fix be backported to all the relevant Python versions? If you understand why the bug happens (I don't, sorry, have no idea of internals of Python), you might be able to generate a compact test case that would capture the erroneous behavior. Best regards, Alex ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-12-28 09:27 Message: Logged In: YES user_id=33168 Originator: NO I don't understand why you think this is an array out of bounds. I ran your test case under valgrind and it reported no problems. I can reproduce the problem. I have attached a patch that fixes the problem for me. I am not certain it's the correct fix however. The unit tests pass with this modification. File Added: bz2.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1622896&group_id=5470 From noreply at sourceforge.net Tue Mar 13 13:35:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 05:35:08 -0700 Subject: [ python-Bugs-1622896 ] Exception when compressing certain data with bz2 Message-ID: Bugs item #1622896, was opened at 2006-12-27 13:26 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1622896&group_id=5470 Please note that this 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.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Alex Gontmakher (gsasha) Assigned to: Nobody/Anonymous (nobody) Summary: Exception when compressing certain data with bz2 Initial Comment: Looks like an out-of-bounds array access... might be a security problem. The attached file includes a script which, when executed, tries to pack the two given directories with a bz2 compressor. On my machine (stock 32 bit Ubuntu Edgy), the program fails with the following exception: -------------------- Traceback (most recent call last): File "test.py", line 13, in ? block = compressor.compress(open("compress-0067/"+file, "rb").read()) ValueError: the bz2 library has received wrong parameters -------------------- The problem occurs under either python2.4 or 2.5 (I don't have other versions to test with). Sorry, the file is large... I tried to reduce the example to smaller number of files etc., but no such luck. The file is too large to be submitted here as an attachment, so I have uploaded it to http://www.cs.technion.ac.il/~gsasha/testcase.tar.bz2 ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 12:35 Message: Logged In: YES user_id=849994 Originator: NO I think Neal's patch is correct, the equivalent needed to be applied in several other places as well. Committed as rev. 54336, 54337 (2.5). ---------------------------------------------------------------------- Comment By: ralf (indi4source) Date: 2007-03-13 11:25 Message: Logged In: YES user_id=1182990 Originator: NO I had the same problem with the BZ2Compressor. (reproducible under 2.5) It was working fine with BZ2File. Unfortunately I cannot check the proposed fix as I don't have the environment to compile python... ---------------------------------------------------------------------- Comment By: Alex Gontmakher (gsasha) Date: 2006-12-28 09:17 Message: Logged In: YES user_id=47707 Originator: YES I saw that the effect occurs only when one compressor finishes and is destroyed, and then the second one gives the "wrong parameters". Usually, for such an effect to happen, the first compressor must have some permanent effect on the system - and since it was destroyed before the second one was created, it was only natural to assume that the reason was an out of bounds access. My approach is that such a bug should be suspected as an out-of-bounds access until shown othervise, especially in a language like Python where it is natural to assume that such problems shouldn't occur and that it is safe to use security-wise. Of course I'll be happy to learn that it's just a simple bug. On a related note, will the fix be backported to all the relevant Python versions? If you understand why the bug happens (I don't, sorry, have no idea of internals of Python), you might be able to generate a compact test case that would capture the erroneous behavior. Best regards, Alex ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-12-28 08:27 Message: Logged In: YES user_id=33168 Originator: NO I don't understand why you think this is an array out of bounds. I ran your test case under valgrind and it reported no problems. I can reproduce the problem. I have attached a patch that fixes the problem for me. I am not certain it's the correct fix however. The unit tests pass with this modification. File Added: bz2.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1622896&group_id=5470 From noreply at sourceforge.net Tue Mar 13 14:18:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 06:18:50 -0700 Subject: [ python-Bugs-1679784 ] "my" should be "may" Message-ID: Bugs item #1679784, was opened at 2007-03-13 15:18 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=1679784&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: edward (edwarddsp) Assigned to: Nobody/Anonymous (nobody) Summary: "my" should be "may" Initial Comment: In the third last paragraph of section 8.3 of the tutorial, the text "One my also instantiate an exception" should be "One may also instantiate an exception". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1679784&group_id=5470 From noreply at sourceforge.net Tue Mar 13 14:22:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 06:22:14 -0700 Subject: [ python-Bugs-1679784 ] "my" should be "may" Message-ID: Bugs item #1679784, was opened at 2007-03-13 13:18 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1679784&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: edward (edwarddsp) Assigned to: Nobody/Anonymous (nobody) Summary: "my" should be "may" Initial Comment: In the third last paragraph of section 8.3 of the tutorial, the text "One my also instantiate an exception" should be "One may also instantiate an exception". ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 13:22 Message: Logged In: YES user_id=849994 Originator: NO Thanks for the report, this is already fixed in SVN. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1679784&group_id=5470 From noreply at sourceforge.net Tue Mar 13 14:23:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 06:23:09 -0700 Subject: [ python-Bugs-1679652 ] error in the sys module documentation Message-ID: Bugs item #1679652, was opened at 2007-03-13 09:57 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1679652&group_id=5470 Please note that this 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: Invalid Priority: 5 Private: No Submitted By: David Fillinger (daikinoko) Assigned to: Nobody/Anonymous (nobody) Summary: error in the sys module documentation Initial Comment: In this text from the sys module documentation: http://docs.python.org/lib/module-sys.html "argv The list of command line arguments passed to a Python script. argv[0] is the script name (it is operating system dependent whether this is a full pathname or not). If the command was executed using the -c command line option to the interpreter, argv[0] is set to the string '-c'. If no script name was passed to the Python interpreter, argv has zero length." the second argv[0] should be argv[1] because argv[0] is the name of the script. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 13:23 Message: Logged In: YES user_id=849994 Originator: NO No, it's correct as it is. There *is no* scriptname with -c. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1679652&group_id=5470 From noreply at sourceforge.net Tue Mar 13 18:17:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 10:17:50 -0700 Subject: [ python-Bugs-1680034 ] Importing SystemRandom wastes entropy. Message-ID: Bugs item #1680034, was opened at 2007-03-13 17:17 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=1680034&group_id=5470 Please note that this 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 Private: No Submitted By: Steve Tyler (stephent98) Assigned to: Nobody/Anonymous (nobody) Summary: Importing SystemRandom wastes entropy. Initial Comment: Importing SystemRandom wastes entropy. The strace snippet shows a 16 byte read from /dev/urandom, which is presumably done to seed a random number generator. However SystemRandom does not need a seed, so the read is not needed. test case: #!/usr/bin/python from random import SystemRandom strace snippet: open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 4 read(4, "\\\333\277Q\243>K\350 \321\316\26_\271\364~", 16) = 16 close(4) = 0 Python version: python-2.4.4-1.fc6 (Fedora Core 6) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1680034&group_id=5470 From noreply at sourceforge.net Tue Mar 13 18:32:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 10:32:28 -0700 Subject: [ python-Bugs-1680034 ] Importing SystemRandom wastes entropy. Message-ID: Bugs item #1680034, was opened at 2007-03-13 17:17 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1680034&group_id=5470 Please note that this 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 Private: No Submitted By: Steve Tyler (stephent98) Assigned to: Nobody/Anonymous (nobody) Summary: Importing SystemRandom wastes entropy. Initial Comment: Importing SystemRandom wastes entropy. The strace snippet shows a 16 byte read from /dev/urandom, which is presumably done to seed a random number generator. However SystemRandom does not need a seed, so the read is not needed. test case: #!/usr/bin/python from random import SystemRandom strace snippet: open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 4 read(4, "\\\333\277Q\243>K\350 \321\316\26_\271\364~", 16) = 16 close(4) = 0 Python version: python-2.4.4-1.fc6 (Fedora Core 6) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 17:32 Message: Logged In: YES user_id=849994 Originator: NO This is not caused by SystemRandom, but by instantiating (and thereby seeding) the normal (Mersenne Twister) random number generator, which is done automatically when random is imported. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1680034&group_id=5470 From noreply at sourceforge.net Tue Mar 13 19:17:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 11:17:54 -0700 Subject: [ python-Bugs-1556895 ] typo in encoding name in email package Message-ID: Bugs item #1556895, was opened at 2006-09-12 03:33 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1556895&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Guillaume Rousse (guillomovitch) Assigned to: Barry A. Warsaw (bwarsaw) Summary: typo in encoding name in email package Initial Comment: gb2132 should be gb2312... Here is a patch against email-2.5.8 ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2007-03-13 14:17 Message: Logged In: YES user_id=12800 Originator: NO r54342 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1556895&group_id=5470 From noreply at sourceforge.net Tue Mar 13 19:30:35 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 11:30:35 -0700 Subject: [ python-Bugs-1680034 ] Importing SystemRandom wastes entropy. Message-ID: Bugs item #1680034, was opened at 2007-03-13 17:17 Message generated for change (Comment added) made by stephent98 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1680034&group_id=5470 Please note that this 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 Private: No Submitted By: Steve Tyler (stephent98) Assigned to: Nobody/Anonymous (nobody) Summary: Importing SystemRandom wastes entropy. Initial Comment: Importing SystemRandom wastes entropy. The strace snippet shows a 16 byte read from /dev/urandom, which is presumably done to seed a random number generator. However SystemRandom does not need a seed, so the read is not needed. test case: #!/usr/bin/python from random import SystemRandom strace snippet: open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 4 read(4, "\\\333\277Q\243>K\350 \321\316\26_\271\364~", 16) = 16 close(4) = 0 Python version: python-2.4.4-1.fc6 (Fedora Core 6) ---------------------------------------------------------------------- >Comment By: Steve Tyler (stephent98) Date: 2007-03-13 18:30 Message: Logged In: YES user_id=1741843 Originator: YES Entropy is not an unlimited quantity, therefore the existing behavior is undesirable. My app is a random password generator which may need the entropy for itself. https://sourceforge.net/projects/gnome-password/ ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 17:32 Message: Logged In: YES user_id=849994 Originator: NO This is not caused by SystemRandom, but by instantiating (and thereby seeding) the normal (Mersenne Twister) random number generator, which is done automatically when random is imported. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1680034&group_id=5470 From noreply at sourceforge.net Tue Mar 13 20:08:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 12:08:28 -0700 Subject: [ python-Bugs-1680034 ] Importing SystemRandom wastes entropy. Message-ID: Bugs item #1680034, was opened at 2007-03-13 17:17 Message generated for change (Comment added) made by stephent98 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1680034&group_id=5470 Please note that this 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 Private: No Submitted By: Steve Tyler (stephent98) Assigned to: Nobody/Anonymous (nobody) Summary: Importing SystemRandom wastes entropy. Initial Comment: Importing SystemRandom wastes entropy. The strace snippet shows a 16 byte read from /dev/urandom, which is presumably done to seed a random number generator. However SystemRandom does not need a seed, so the read is not needed. test case: #!/usr/bin/python from random import SystemRandom strace snippet: open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 4 read(4, "\\\333\277Q\243>K\350 \321\316\26_\271\364~", 16) = 16 close(4) = 0 Python version: python-2.4.4-1.fc6 (Fedora Core 6) ---------------------------------------------------------------------- >Comment By: Steve Tyler (stephent98) Date: 2007-03-13 19:08 Message: Logged In: YES user_id=1741843 Originator: YES Here is a little more background on why wasting entropy is a problem. "When accessed as /dev/urandom, as many bytes as are requested are returned even when the entropy pool is exhausted." http://www.linux.com/howtos/Secure-Programs-HOWTO/random-numbers.shtml When the entropy pool is exhausted, the Linux RNG (accessed via /dev/urandom) behaves like a pseudo-random number generator, which is not acceptable for cryptographic applications such as password generators. Analysis of the Linux Random Number Generator http://www.pinkas.net/PAPERS/gpr06.pdf Of course one can work around this issue by not using the "random" module and accessing /dev/urandom or /dev/random directly. For some perspective, simply importing the gnome.ui module consumes 4096 bytes of random data in a library I have not been able to completely identify. (I don't think it is Python, though.) ---------------------------------------------------------------------- Comment By: Steve Tyler (stephent98) Date: 2007-03-13 18:30 Message: Logged In: YES user_id=1741843 Originator: YES Entropy is not an unlimited quantity, therefore the existing behavior is undesirable. My app is a random password generator which may need the entropy for itself. https://sourceforge.net/projects/gnome-password/ ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 17:32 Message: Logged In: YES user_id=849994 Originator: NO This is not caused by SystemRandom, but by instantiating (and thereby seeding) the normal (Mersenne Twister) random number generator, which is done automatically when random is imported. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1680034&group_id=5470 From noreply at sourceforge.net Tue Mar 13 21:17:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 13:17:39 -0700 Subject: [ python-Bugs-1680034 ] Importing SystemRandom wastes entropy. Message-ID: Bugs item #1680034, was opened at 2007-03-13 12:17 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1680034&group_id=5470 Please note that this 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 Private: No Submitted By: Steve Tyler (stephent98) Assigned to: Nobody/Anonymous (nobody) Summary: Importing SystemRandom wastes entropy. Initial Comment: Importing SystemRandom wastes entropy. The strace snippet shows a 16 byte read from /dev/urandom, which is presumably done to seed a random number generator. However SystemRandom does not need a seed, so the read is not needed. test case: #!/usr/bin/python from random import SystemRandom strace snippet: open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 4 read(4, "\\\333\277Q\243>K\350 \321\316\26_\271\364~", 16) = 16 close(4) = 0 Python version: python-2.4.4-1.fc6 (Fedora Core 6) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-03-13 15:17 Message: Logged In: YES user_id=80475 Originator: NO Sorry, am closing this as won't fix. The 16 bytes are used to seed the MersenneTwister which is used by tempfile.py upon startup. That is a reasonable use of the resource. FWIW, it is possible for you to recover most of those 16 bytes of entropy just by calling the twister itself. Also, it is my understanding that /dev/urandom is continuously refilling its hardware based entropy source (so the supply is limitless, but not instant). ---------------------------------------------------------------------- Comment By: Steve Tyler (stephent98) Date: 2007-03-13 14:08 Message: Logged In: YES user_id=1741843 Originator: YES Here is a little more background on why wasting entropy is a problem. "When accessed as /dev/urandom, as many bytes as are requested are returned even when the entropy pool is exhausted." http://www.linux.com/howtos/Secure-Programs-HOWTO/random-numbers.shtml When the entropy pool is exhausted, the Linux RNG (accessed via /dev/urandom) behaves like a pseudo-random number generator, which is not acceptable for cryptographic applications such as password generators. Analysis of the Linux Random Number Generator http://www.pinkas.net/PAPERS/gpr06.pdf Of course one can work around this issue by not using the "random" module and accessing /dev/urandom or /dev/random directly. For some perspective, simply importing the gnome.ui module consumes 4096 bytes of random data in a library I have not been able to completely identify. (I don't think it is Python, though.) ---------------------------------------------------------------------- Comment By: Steve Tyler (stephent98) Date: 2007-03-13 13:30 Message: Logged In: YES user_id=1741843 Originator: YES Entropy is not an unlimited quantity, therefore the existing behavior is undesirable. My app is a random password generator which may need the entropy for itself. https://sourceforge.net/projects/gnome-password/ ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 12:32 Message: Logged In: YES user_id=849994 Originator: NO This is not caused by SystemRandom, but by instantiating (and thereby seeding) the normal (Mersenne Twister) random number generator, which is done automatically when random is imported. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1680034&group_id=5470 From noreply at sourceforge.net Tue Mar 13 21:33:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 13:33:15 -0700 Subject: [ python-Bugs-1680159 ] Misleading exception from unicode.__contains__ Message-ID: Bugs item #1680159, was opened at 2007-03-13 21: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=1680159&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Hudec (bulbjh) Assigned to: M.-A. Lemburg (lemburg) Summary: Misleading exception from unicode.__contains__ Initial Comment: Hello Folks, unicode.__contains__ throws: >>> '\xff' in u'foo' Traceback (most recent call last): File "", line 1, in TypeError: 'in ' requires string as left operand while: Traceback (most recent call last): File "", line 1, in UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position 0: ordinal not in range(128) would be more helpful, because that's what really fails there. The exception it throws now does not indicate that unicode is involved. (tried this with 2.4.4 and 2.5.0 and happens in both) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1680159&group_id=5470 From noreply at sourceforge.net Tue Mar 13 23:00:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 15:00:58 -0700 Subject: [ python-Bugs-1326406 ] pdb breaks programs which import from __main__ Message-ID: Bugs item #1326406, was opened at 2005-10-14 04:23 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1326406&group_id=5470 Please note that this 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: Fixed Priority: 5 Private: No Submitted By: Ilya Sandler (isandler) Assigned to: Nobody/Anonymous (nobody) Summary: pdb breaks programs which import from __main__ Initial Comment: The following example illustrates the problem: bagira:~/python/dist/src/Lib> cat tt/xx hello=None import yy print "in xx:yy imported" bagira:~/python/dist/src/Lib> cat tt/yy.py from __main__ import hello print "in yy: yy imported " this works by itself: bagira:~/python/dist/src/Lib> ../python tt/xx in yy: yy imported in xx:yy imported But breaks under pdb bagira:~/python/dist/src/Lib> ../python -m pdb tt/xx > /home/ilya/python/dist/src/Lib/tt/xx(1)?() -> hello=None (Pdb) c Traceback (most recent call last): File "/home/ilya/python/dist/src/Lib/pdb.py", line 1057, in main pdb._runscript(mainpyfile) File "/home/ilya/python/dist/src/Lib/pdb.py", line 982, in _runscript self.run(statement, globals=globals_, locals=locals_) File "/home/ilya/python/dist/src/Lib/bdb.py", line 367, in run exec cmd in globals, locals File "", line 1, in ? File "tt/xx", line 2, in ? import yy File "/home/ilya/python/dist/src/Lib/tt/yy.py", line 1, in ? from __main__ import hello ImportError: cannot import name hello Uncaught exception. Entering post mortem debugging Running 'cont' or 'step' will restart the program > /home/ilya/python/dist/src/Lib/tt/yy.py(1)?() -> from __main__ import hello ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 22:00 Message: Logged In: YES user_id=849994 Originator: NO Fixed with said patch. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-05-18 00:53 Message: Logged In: YES user_id=971153 I have submitted a patch #1429539 for this ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1326406&group_id=5470 From noreply at sourceforge.net Tue Mar 13 23:08:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 15:08:26 -0700 Subject: [ python-Bugs-796219 ] ntpath.expanduser() is still wrong Message-ID: Bugs item #796219, was opened at 2003-08-27 20:11 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=796219&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Guido van Rossum (gvanrossum) >Assigned to: Georg Brandl (gbrandl) Summary: ntpath.expanduser() is still wrong Initial Comment: I found a system with the following setup: - os.getenv("HOME") returns "%USERPROFILE%" - os.getenv("USERPROFILE") returns the home directory Currently, ntpath.py doesn't expand ~ correctly in this case. The fix is pretty simple, I'll try to submit it if I have time. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 22:08 Message: Logged In: YES user_id=849994 Originator: NO This is finally fixed with patch #957650. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-20 20:45 Message: Logged In: YES user_id=341410 I have submitted sf patch #957650 to fix the bug listed. There is still an issue when there actually exists folders with names that mirror environment variables, but regardless of whether we stat the filesystem, the meaning of such a thing is ambiguous. The patch also includes ~user\subpath functionality, which has been missing in ntpath. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-03-27 00:53 Message: Logged In: YES user_id=341410 After doing some more playing around, I discovered a few other examples that would kill either method described below: HOME=%USERDRIVE%%USERPATH% HOME=C:\%userprofiles\%USERNAME% The real trick is that % can exist in a path on windows, so even c:\%HOME% is a vaild path: Directory of D:\test 03/26/2004 03:58p . 03/26/2004 03:58p .. 03/26/2004 03:59p %HOME% 0 File(s) 0 bytes 3 Dir(s) 5,355,511,808 bytes free D:\test> I suppose the question remains as to what cases do we want to cover. If we assume that there aren't any % symbols in a path, then the code is straightforward, and I can have a patch for you in a few minutes. If % can be in a path, then the problem is a pain, and a miniature parser needs to be written to deal with it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-03-20 22:49 Message: Logged In: YES user_id=6380 Unclear what I'm asked to do here. Josiah, could you produce an actual patch against CVS rather than random example code? If you have forward slashes, you should use os.path.normpath(). Why doesn't that work? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-30 14:00 Message: Logged In: YES user_id=31435 Assigned back to Guido. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2003-09-30 06:33 Message: Logged In: YES user_id=341410 I just noticed that I've got some forward slashes in various paths on my windows machines...here's some updated code: def expandfull(var, rem=3): if not rem: return os.path.expandvars(var) a = os.path.expandvars(var) b = [] d = [b.extend(i.split('\\')) for i in a.split('/')] c = [] for i in b: if '%' in i: c.append(expandfull(i), rem-1) else: c.append(i) return '\\'.join(c) ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-08-30 09:55 Message: Logged In: YES user_id=539787 I stand corrected; multiple backslashes inside a path are not merged into one on Windows. Thank you. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2003-08-29 18:48 Message: Logged In: YES user_id=341410 Sourceforge ate my double-backslashes. All '\\' should be '\\\\'. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2003-08-29 18:20 Message: Logged In: YES user_id=341410 The code you offered won't work correctly for all environment variable returns. An example that would kill your code: %SYSTEMROOT%\System32 def expandfull(var, rem=3): if not rem: return expandvars(var) a = expandvars(var) b = a.split('\\') c = [] for i in b: if '%' in i: c.append(expandfull(i), rem-1) else: c.append(i) return '\\'.join(c) The above would work properly for all environment variables. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-08-29 08:38 Message: Logged In: YES user_id=539787 If expandvars worked for nt variable syntax too, then just before the expanduser final return, the following code would suffice, right? max_recursion = 3 while '%' in userhome and max_recursion > 0: userhome = expandvars(userhome) max_recursion -= 1 ignoring the fact that path[1:] could contain variables too. Shouldn't expandvars be made to work with %var% format too? If yes, I'll offer code. ---------------------------------------------------------------------- Comment By: Jarek Zgoda (zgoda) Date: 2003-08-28 07:47 Message: Logged In: YES user_id=92222 This is very common setting on Windows2000 Professional. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=796219&group_id=5470 From noreply at sourceforge.net Tue Mar 13 23:51:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 15:51:17 -0700 Subject: [ python-Bugs-1085283 ] binascii.b2a_qp oddities Message-ID: Bugs item #1085283, was opened at 2004-12-14 18:11 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085283&group_id=5470 Please note that this 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: Fixed Priority: 2 Private: No Submitted By: DSM (dsm001) Assigned to: Nobody/Anonymous (nobody) Summary: binascii.b2a_qp oddities Initial Comment: [Python 2.5a0 (#9, Dec 8 2004, 12:37:01); the behaviours go way back.] binascii.b2a_qp has several quirks discovered when reimplementing. (1) It lets low bytes pass through unescaped -- e.g. binascii.b2a_qp('\x08') == '\x08' -- unless quotetabs is True. This looks to be an error in program logic at lines ~1165 and ~1234, unless this is intended (although quopri's internal version quotes them). This doesn't seem RFC 1521 compatible on my reading of section 5 (admittedly I only read it for the first time last week. :-) (2) It determines whether to enforce \n or \r\n by scanning the string for the first occurrence [which should be mentioned in the docs]. binascii.c does this by calling strchr, which stops at the first \x00. This means that: >>> s0 = "The quick " + chr(0) + "brown fox.\r\n" >>> s1 = "The quick " + chr(1) + "brown fox.\r\n" >>> binascii.b2a_qp(s0) 'The quick \x00brown fox.\n' >>> binascii.b2a_qp(s1) 'The quick \x01brown fox.\r\n' and related strangenesses. (3) The code escapes the period "." if and only if it's the second character in a line. I'm not sure why; the only mention I can find in 1521 is in appendix B of escaping a period ALONE on a line in some situations, which binascii.b2a_qp doesn't do in any event. This behaviour may be prescribed by some other spec but is strange enough to be mentioned in the docs if it's intentional. A new strictly RFC1521-compliant qp encoding would be a good thing if backwards compatibility prevents changing some of these. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 22:51 Message: Logged In: YES user_id=849994 Originator: NO Fixed (1) and (3) in rev. 54367. I think (2) is not important enough to do anything about it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085283&group_id=5470 From noreply at sourceforge.net Tue Mar 13 23:52:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 15:52:26 -0700 Subject: [ python-Bugs-1678102 ] zlib.crc32() not cross-platform Message-ID: Bugs item #1678102, was opened at 2007-03-10 20:07 Message generated for change (Comment added) made by gagenellina You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678102&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ben Collver (bencollver) Assigned to: Nobody/Anonymous (nobody) Summary: zlib.crc32() not cross-platform Initial Comment: The zlib.crc32() function sometimes produces different results for the same input on big and little-endian processors. Same for zlib.adler32(). sparc64: >>> import zlib >>> print zlib.adler32("--------------------------------------------------", 1) > 3763407051 >>> print zlib.crc32("--------------------------------------------------", 1) 3044228349 i386: >>> import zlib >>> print zlib.adler32("--------------------------------------------------", 1) > -531560245 >>> print zlib.crc32("--------------------------------------------------", 1) -1250738947 ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-03-13 19:52 Message: Logged In: YES user_id=479790 Originator: NO py> -531560245 & 0xffffffff 3763407051L It's the same number (actually, the same bit pattern). The i386 version is signed, the other unsigned. The i386 platform uses a 32 bit "int"; the sparc64 uses 64 bits (I presume). 3763407051 doesnt fit in 31bits, so it's seen as a negative number. ---------------------------------------------------------------------- Comment By: Ben Collver (bencollver) Date: 2007-03-10 20:13 Message: Logged In: YES user_id=778667 Originator: YES The extra > characters before the first results come from me pasting the results to my irc client, then copying from there and pasting here. Sorry for any confusion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678102&group_id=5470 From noreply at sourceforge.net Wed Mar 14 00:09:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 16:09:57 -0700 Subject: [ python-Bugs-1680230 ] urllib.urlopen() raises AttributeError Message-ID: Bugs item #1680230, was opened at 2007-03-14 00:09 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=1680230&group_id=5470 Please note that this 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 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.urlopen() raises AttributeError Initial Comment: When you connect urlopen() to a socket that does not send any data, it produces an AttributeError. File "/lib/python2.6/urllib.py", line 608, in http_error_default return addinfourl(fp, headers, "http:" + url) File "/lib/python2.6/urllib.py", line 951, in __init__ addbase.__init__(self, fp) File "/lib/python2.6/urllib.py", line 898, in __init__ self.read = self.fp.read AttributeError: 'NoneType' object has no attribute 'read' Raising an exception is OK (I think?), but it should be an IOError instead of an AttributeError. See the attached patch for a test case for the bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1680230&group_id=5470 From noreply at sourceforge.net Wed Mar 14 00:13:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 16:13:58 -0700 Subject: [ python-Bugs-1680230 ] urllib.urlopen() raises AttributeError Message-ID: Bugs item #1680230, was opened at 2007-03-14 00:09 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1680230&group_id=5470 Please note that this 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 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.urlopen() raises AttributeError Initial Comment: When you connect urlopen() to a socket that does not send any data, it produces an AttributeError. File "/lib/python2.6/urllib.py", line 608, in http_error_default return addinfourl(fp, headers, "http:" + url) File "/lib/python2.6/urllib.py", line 951, in __init__ addbase.__init__(self, fp) File "/lib/python2.6/urllib.py", line 898, in __init__ self.read = self.fp.read AttributeError: 'NoneType' object has no attribute 'read' Raising an exception is OK (I think?), but it should be an IOError instead of an AttributeError. See the attached patch for a test case for the bug. ---------------------------------------------------------------------- >Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-14 00:13 Message: Logged In: YES user_id=51702 Originator: YES File Added: test-urllib-tc-attr-err.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1680230&group_id=5470 From noreply at sourceforge.net Wed Mar 14 05:33:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 21:33:57 -0700 Subject: [ python-Bugs-1680312 ] httplib fails to parse response on HEAD request Message-ID: Bugs item #1680312, was opened at 2007-03-13 23: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=1680312&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Patrick Altman (altman) Assigned to: Nobody/Anonymous (nobody) Summary: httplib fails to parse response on HEAD request Initial Comment: When attempting to get the response headers to a HEAD request, httplib hangs and then eventually throws an exception. Details can be found in the following post: http://groups.google.com/group/comp.lang.python/browse_thread/thread/ff9fa7c5e6dbea7f/ Thanks, Patrick Altman paltman at gmail.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1680312&group_id=5470 From noreply at sourceforge.net Wed Mar 14 05:34:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 21:34:31 -0700 Subject: [ python-Bugs-1680312 ] httplib fails to parse response on HEAD request Message-ID: Bugs item #1680312, was opened at 2007-03-13 23:33 Message generated for change (Settings changed) made by altman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1680312&group_id=5470 Please note that this 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.5 Status: Open Resolution: None >Priority: 7 Private: No Submitted By: Patrick Altman (altman) Assigned to: Nobody/Anonymous (nobody) Summary: httplib fails to parse response on HEAD request Initial Comment: When attempting to get the response headers to a HEAD request, httplib hangs and then eventually throws an exception. Details can be found in the following post: http://groups.google.com/group/comp.lang.python/browse_thread/thread/ff9fa7c5e6dbea7f/ Thanks, Patrick Altman paltman at gmail.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1680312&group_id=5470 From noreply at sourceforge.net Wed Mar 14 06:00:27 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 22:00:27 -0700 Subject: [ python-Bugs-1582282 ] email.header decode within word Message-ID: Bugs item #1582282, was opened at 2006-10-22 09:16 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582282&group_id=5470 Please note that this 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.5 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.header decode within word Initial Comment: The problem is filed in mailman bug report: http://sourceforge.net/tracker/index.php?func=detail&aid=1578539&group_id=103&atid=100103 While Microsoft Entourage's way of encoding iso-8859-1 text is not compliant with RFC-2047, Python email.header.decode_header should treat this 'word' as a simple us-ascii string and should not parse into series of string/charset list. Sm=?ISO-8859-1?B?9g==?=rg=?ISO-8859-1?B?5Q==?=sbord should be parsed as [('Sm=?ISO-8859-1?B?9rg==?=g=?ISO-8859-1?B?5Q==?=sbord', None)], not as [('Sm', None), ('\xf6', 'iso-8859-1'), ('g', None), ('\xe5', 'iso-8859-1'), ('sbord', None)] ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2007-03-14 01:00 Message: Logged In: YES user_id=12800 Originator: NO r54370 for Python 2.5 r54371 for Python 2.6 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582282&group_id=5470 From noreply at sourceforge.net Wed Mar 14 06:04:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 22:04:11 -0700 Subject: [ python-Bugs-1572084 ] .eml attachments in email Message-ID: Bugs item #1572084, was opened at 2006-10-06 08:23 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1572084&group_id=5470 Please note that this 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.5 >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: rainwolf8472 (rainwolf8472) Assigned to: Barry A. Warsaw (bwarsaw) Summary: .eml attachments in email Initial Comment: I think there's a bug somewhere in the email package. I wanted to write a script to send emails with certain attachments using libgmail, and found this one, http://pramode.net/articles/lfy/fuse/4.txt , it works fine with most files, but it fails with .eml files, and what i can't understand is that if I change the extension of those .eml files to .txt, the script works fine. However, when trying to mail a simple textfile containing "hello", en changing the extension to .eml before sending, it fails again. it doesn't fail when I don't change the extension to .eml. Any help please? I pasted the output I get (over and over again) in the attached textfile. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2007-03-14 01:04 Message: Logged In: YES user_id=12800 Originator: NO I'll need more information in order to debug this. Please try to create a small, standalone, reproducible test case. I don't have libgmail available so please don't write a test case that depends on that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1572084&group_id=5470 From noreply at sourceforge.net Wed Mar 14 08:00:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 00:00:34 -0700 Subject: [ python-Bugs-1680312 ] httplib fails to parse response on HEAD request Message-ID: Bugs item #1680312, was opened at 2007-03-14 04:33 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1680312&group_id=5470 Please note that this 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.5 >Status: Closed >Resolution: Duplicate Priority: 7 Private: No Submitted By: Patrick Altman (altman) Assigned to: Nobody/Anonymous (nobody) Summary: httplib fails to parse response on HEAD request Initial Comment: When attempting to get the response headers to a HEAD request, httplib hangs and then eventually throws an exception. Details can be found in the following post: http://groups.google.com/group/comp.lang.python/browse_thread/thread/ff9fa7c5e6dbea7f/ Thanks, Patrick Altman paltman at gmail.com ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 07:00 Message: Logged In: YES user_id=849994 Originator: NO This is a duplicate of #1486335. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1680312&group_id=5470 From noreply at sourceforge.net Wed Mar 14 09:28:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 01:28:11 -0700 Subject: [ python-Bugs-767111 ] AttributeError thrown by urllib.open_http Message-ID: Bugs item #767111, was opened at 2003-07-07 12:52 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767111&group_id=5470 Please note that this 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: Fixed Priority: 6 Private: No Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: AttributeError thrown by urllib.open_http Initial Comment: In 2.3b2, looks like an error condition isn't being picked up on line 300 or 301 of urllib.py. The code that triggered this traceback was simply: url = urllib.urlopen(action, data) Traceback (most recent call last): File "autospamrep.py", line 170, in ? current_page = handle_spamcop_page(current_page) File "autospamrep.py", line 140, in handle_spamcop_page url = urllib.urlopen(action, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 78, in urlopen return opener.open(url, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 183, in open return getattr(self, name)(url, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 308, in open_http return self.http_error(url, fp, errcode, errmsg, headers, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 323, in http_error return self.http_error_default(url, fp, errcode, errmsg, headers) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 551, in http_error_default return addinfourl(fp, headers, "http:" + url) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 837, in __init__ addbase.__init__(self, fp) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 787, in __init__ self.read = self.fp.read AttributeError: 'NoneType' object has no attribute 'read' ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 08:28 Message: Logged In: YES user_id=849994 Originator: NO Fixed in rev. 54376, 54377 (2.5). Raises IOError now. ---------------------------------------------------------------------- Comment By: Atul Varma (varmaa) Date: 2007-02-25 00:58 Message: Logged In: YES user_id=863202 Originator: NO I have attempted to fix this bug in patch 1668132: http://sourceforge.net/tracker/index.php?func=detail&aid=1668132&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-12-15 22:11 Message: Logged In: YES user_id=1188172 Further information can be found in #1163401 which has been closed as a duplicate. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-01-07 12:39 Message: Logged In: YES user_id=11375 No, not at this point in time. Unassigning (or, if this bug is on the radar for 2.3.5/2.4.1, I can find time to work on it). - ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-01-07 12:39 Message: Logged In: YES user_id=11375 No, not at this point in time. Unassigning (or, if this bug is on the radar for 2.3.5/2.4.1, I can find time to work on it). - ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-07 01:37 Message: Logged In: YES user_id=80475 Andrew, are you still working on this one? ---------------------------------------------------------------------- Comment By: Rob Probin (robzed) Date: 2004-03-18 23:43 Message: Logged In: YES user_id=1000470 The file pointer (fp) is None (inside urllib) from httplib. This appears to be caused by a BadStatusLine exception in getreply() (line1016 httplib). This sets self.file to self._conn.sock.makefile('rb', 0) then does a self.close() which sets self.file to None. Being new to this peice of code, I'm not sure whether it's urllib assuming the file isn't going to be closed, or the BadStatusLine exception clearing the file. Certainly it looks like the error -1 is not being trapped by open_http() in urllib upon calling h.getreply() and assuming that the file still exists even in an error condition? It maybe a coincidence but it appears to occur more when a web browser on the same machine is refreshing. Regards Rob ---------------------------------------------------------------------- Comment By: Rob Probin (robzed) Date: 2004-03-17 22:24 Message: Logged In: YES user_id=1000470 """ This comment is program to reproduce the problem. Sorry it's not an attachment - as a relative Sourceforge newbie I have no idea how to attach to an existing bug. More notes available via email if required - including all local variables for each function from post mortem. As said before, seems to be fp = None. Although the exception is caused by the 'self.read = self.fp.read', it looks like 'fp = h.getfile()' inside open_http() This is repeatable, but you may have to run this more than once. (Apologies to noaa.gov). *** PLEASE: Run only where absolutely necessary for reproduction of bug!!! *** """ """ Attribute Error test case - Python 2.3 """ import urllib url = "http://adds.aviationweather.noaa.gov/metars/index.php" params = urllib.urlencode({ "station_ids" : "KJFK", "hoursStr" : "most recent only", "std_trans" : "standard", "chk_metars" : "on", "submit":"Submit"}) print "test" for i in range(1, 1000): x = urllib.urlopen(url, params) string = x.read() print i """ Local variables for middle level routine... classURLopener open_http(self, url, data=None) args ('User-agent', 'Python-urllib/1.15') auth None data 'hoursStr=most+recent+only&station_ids=KJFK&std_trans=standard&sub mit=Submit&chk_metars=on' errcode -1 errmsg '' fp None h headers None host 'adds.aviationweather.noaa.gov' httplib realhost 'adds.aviationweather.noaa.gov' selector '/metars/index.php' self url '//adds.aviationweather.noaa.gov/metars/index.php' user_passwd None """ ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-29 03:23 Message: Logged In: YES user_id=12800 Please provide a self-contained, complete example that we can use to reproduce this problem. Without enough information, I can't see us fixing this for Python 2.3, and time for that is rapidly running out. Lowering to priority 6. ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-07-17 04:34 Message: Logged In: YES user_id=46639 I've finally managed to get another traceback with some more information, using an assert I inserted into urllib.py a while ago to catch .fp == None: Traceback (most recent call last): File "/Users/zen/bin/autospamrep.py", line 168, in ? current_page = urllib.urlopen(start_url).read() File "/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/urllib.py", line 76, in urlopen return opener.open(url) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/urllib.py", line 181, in open return getattr(self, name)(url) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/urllib.py", line 305, in open_http assert fp is not None, 'errcode %r, errmsg %r, headers %r' % (errcode, errmsg, headers) AssertionError: errcode -1, errmsg '', headers None ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-07-12 13:14 Message: Logged In: YES user_id=261020 HTTPResponse.read returns '' if its .fp is None, but the backwards-compat HTTP class' .getfile() just returns self.file, which it previously grabbed from HTTPResponse in .getreply(). Wild guess: maybe HTTP.getreply should just do self.file = response rather than self.file = response.fp The object returned by HTTP.getfile() was documented as returning an object supporting .readline() and .readlines(), while HTTPResponse only supports .read(), so that's obviously not the whole solution. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-09 05:50 Message: Logged In: YES user_id=80475 What were the values of 'action' and 'data' when the call was made? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767111&group_id=5470 From noreply at sourceforge.net Wed Mar 14 09:28:21 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 01:28:21 -0700 Subject: [ python-Bugs-1680230 ] urllib.urlopen() raises AttributeError Message-ID: Bugs item #1680230, was opened at 2007-03-13 23:09 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1680230&group_id=5470 Please note that this 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: Fixed Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.urlopen() raises AttributeError Initial Comment: When you connect urlopen() to a socket that does not send any data, it produces an AttributeError. File "/lib/python2.6/urllib.py", line 608, in http_error_default return addinfourl(fp, headers, "http:" + url) File "/lib/python2.6/urllib.py", line 951, in __init__ addbase.__init__(self, fp) File "/lib/python2.6/urllib.py", line 898, in __init__ self.read = self.fp.read AttributeError: 'NoneType' object has no attribute 'read' Raising an exception is OK (I think?), but it should be an IOError instead of an AttributeError. See the attached patch for a test case for the bug. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 08:28 Message: Logged In: YES user_id=849994 Originator: NO Committed fix and your test case in rev. 54376, 54377 (2.5). ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-13 23:13 Message: Logged In: YES user_id=51702 Originator: YES File Added: test-urllib-tc-attr-err.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1680230&group_id=5470 From noreply at sourceforge.net Wed Mar 14 09:29:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 01:29:28 -0700 Subject: [ python-Bugs-1429783 ] urllib.py: AttributeError on BadStatusLine Message-ID: Bugs item #1429783, was opened at 2006-02-11 18:15 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1429783&group_id=5470 Please note that this 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 Private: No Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.py: AttributeError on BadStatusLine Initial Comment: PythonWin 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on win32. in httplib errcode -1 & file=self._conn.sock.makefile('rb', 0) is returned on Badstatusline: except BadStatusLine, e: ### hmm. if getresponse() ever closes the socket on a bad request, ### then we are going to have problems with self.sock ### should we keep this behavior? do people use it? # keep the socket open (as a file), and return it self.file = self._conn.sock.makefile('rb', 0) # close our socket -- we want to restart after any protocol error self.close() self.headers = None return -1, e.line, None fp = h.getfile() delivers None in urllib.URLopener.open_http and this is traceback leading to an AttributeError Traceback (most recent call last): File "", line 1, in ? File "C:\Python23\lib\urllib.py", line 181, in open return getattr(self, name)(url) File "C:\Python23\lib\urllib.py", line 306, in open_http return self.http_error(url, fp, errcode, errmsg, headers) File "C:\Python23\lib\urllib.py", line 319, in http_error result = method(url, fp, errcode, errmsg, headers) File "C:\Python23\lib\urllib.py", line 584, in http_error_301 return self.http_error_302(url, fp, errcode, errmsg, headers, data) File "C:\Python23\lib\urllib.py", line 565, in http_error_302 data) File "C:\Python23\lib\urllib.py", line 580, in redirect_internal return self.open(newurl) File "C:\Python23\lib\urllib.py", line 181, in open return getattr(self, name)(url) File "C:\Python23\lib\urllib.py", line 306, in open_http return self.http_error(url, fp, errcode, errmsg, headers) File "C:\Python23\lib\urllib.py", line 323, in http_error return self.http_error_default(url, fp, errcode, errmsg, headers) File "C:\Python23\lib\urllib.py", line 327, in http_error_default void = fp.read() AttributeError: 'NoneType' object has no attribute 'read' As I get this error rarely I cannot reproduce exactly how self._conn.sock.makefile('rb', 0) delivers None in that case. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 08:29 Message: Logged In: YES user_id=849994 Originator: NO Fixed that bug finally in rev. 54376, 54377 (2.5). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-12 06:56 Message: Logged In: YES user_id=33168 I should add that the other bug is still open. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-12 06:55 Message: Logged In: YES user_id=33168 This may be a duplicate of a bug submitted by Bram Cohen. It was a couple of years ago and I don't remember any other details. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1429783&group_id=5470 From noreply at sourceforge.net Wed Mar 14 09:30:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 01:30:39 -0700 Subject: [ python-Bugs-1593751 ] poor urllib error handling Message-ID: Bugs item #1593751, was opened at 2006-11-09 21:04 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593751&group_id=5470 Please note that this 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 Private: No Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: poor urllib error handling Initial Comment: I set up a simple server that returns an empty response. >>> from socket import * >>> s = socket() >>> s.bind(("", 9999)) >>> while 1: x, c = s.accept(); print c; x.recv(1000); x.close() ... Pointing urllib at this gives a traceback: Python 2.6a0 (trunk:52099M, Oct 3 2006, 09:59:17) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import urllib >>> urllib.urlopen('http://localhost:9999/') Traceback (most recent call last): File "", line 1, in File "/home/guido/p/Lib/urllib.py", line 82, in urlopen return opener.open(url) File "/home/guido/p/Lib/urllib.py", line 190, in open return getattr(self, name)(url) File "/home/guido/p/Lib/urllib.py", line 334, in open_http return self.http_error(url, fp, errcode, errmsg, headers) File "/home/guido/p/Lib/urllib.py", line 351, in http_error return self.http_error_default(url, fp, errcode, errmsg, headers) File "/home/guido/p/Lib/urllib.py", line 608, in http_error_default return addinfourl(fp, headers, "http:" + url) File "/home/guido/p/Lib/urllib.py", line 951, in __init__ addbase.__init__(self, fp) File "/home/guido/p/Lib/urllib.py", line 898, in __init__ self.read = self.fp.read AttributeError: 'NoneType' object has no attribute 'read' >>> I can repeat this with 2.2.3 and 2.4.3 as well (don't have 2.3 around for testing). The direct cause of the problem is that h.getfile() on line 329 of urllib.py (in head of trunk) returns None. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 08:30 Message: Logged In: YES user_id=849994 Originator: NO Finally fixed in rev. 54376, 54377 (2.5). ---------------------------------------------------------------------- Comment By: Robert Winder (robertwinder) Date: 2006-12-15 16:15 Message: Logged In: YES user_id=195085 Originator: NO Same error handling with 2.3. Suggested fix doesn't work and gives. AttributeError: addinfourl instance has no attribute 'read' ---------------------------------------------------------------------- Comment By: Robert Carr (racarr) Date: 2006-12-05 15:26 Message: Logged In: YES user_id=1649655 Originator: NO Fix? Index: urllib.py =================================================================== --- urllib.py (revision 52918) +++ urllib.py (working copy) @@ -895,8 +895,10 @@ def __init__(self, fp): self.fp = fp - self.read = self.fp.read - self.readline = self.fp.readline + try: + self.read = self.fp.read + self.readline = self.fp.readline + except: print "File handler is none" if hasattr(self.fp, "readlines"): self.readlines = self.fp.readlines if hasattr(self.fp, "fileno"): self.fileno = self.fp.fileno ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593751&group_id=5470 From noreply at sourceforge.net Wed Mar 14 09:31:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 01:31:48 -0700 Subject: [ python-Bugs-855819 ] urllib does not handle Connection reset Message-ID: Bugs item #855819, was opened at 2003-12-07 16:59 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=855819&group_id=5470 Please note that this 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: Fixed Priority: 5 Private: No Submitted By: Stefan Fleiter (fleiter) Assigned to: Nobody/Anonymous (nobody) Summary: urllib does not handle Connection reset Initial Comment: Python 2.2.3+ (#1, Nov 18 2003, 01:16:59) [GCC 3.3.2 (Debian)] on linux2 and Python 2.3.3c1 (#2, Dec 6 2003, 16:44:56) [GCC 3.3.3 20031203 (prerelease) (Debian)] on linux2 Server which does reset Connection: ===================== import SocketServer class RequestHandler(SocketServer.BaseRequestHandler): def handle(self): self.request.send("") server = SocketServer.TCPServer(("localhost", 2000), RequestHandler) server.serve_forever() urllib-Code: ======= import urllib f = urllib.urlopen("http://localhost:2000") Traceback: ======= Traceback (most recent call last): File "url.py", line 4, in ? f = urllib.urlopen("http://localhost:2000") File "/usr/lib/python2.2/urllib.py", line 73, in urlopen return _urlopener.open(url) File "/usr/lib/python2.2/urllib.py", line 178, in open return getattr(self, name)(url) File "/usr/lib/python2.2/urllib.py", line 301, in open_http return self.http_error(url, fp, errcode, errmsg, headers) File "/usr/lib/python2.2/urllib.py", line 318, in http_error return self.http_error_default(url, fp, errcode, errmsg, headers) File "/usr/lib/python2.2/urllib.py", line 546, in http_error_default return addinfourl(fp, headers, "http:" + url) File "/usr/lib/python2.2/urllib.py", line 824, in __init__ addbase.__init__(self, fp) File "/usr/lib/python2.2/urllib.py", line 778, in __init__ self.read = self.fp.read The cause seems to be that urllib.addbase depends on the fp argument beeing a valid socket while fp = h.getfile() in open_http sets it to None because in httplib.HTTP.getreply() the BadStatusLine-Exception-Handling was triggered. urllib2 does handle this right. Thanks for reading all of this. :-) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 08:31 Message: Logged In: YES user_id=849994 Originator: NO Finally fixed in rev. 54376, 54377 (2.5). Now raises IOError. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=855819&group_id=5470 From noreply at sourceforge.net Wed Mar 14 09:34:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 01:34:50 -0700 Subject: [ python-Bugs-891832 ] commands module doesn't support background commands Message-ID: Bugs item #891832, was opened at 2004-02-06 14:57 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=891832&group_id=5470 Please note that this 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 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: commands module doesn't support background commands Initial Comment: The structure of the command passed to os.popen() prevents the getoutput() and getstatusoutput() functions from accepting commands for background execution. I think it would be sufficient to see if the last non-whitespace character in the command was '&' and if so, suppress insertion of the semicolon into the command passed to os.popen(): dosemi = not cmd.strip()[-1:] == '&' pipe = os.popen('{ %s%s } 2>&1' % (cmd, dosemi and ';' or ''), 'r') The above is untested, but based on my fiddling at the shell prompt seems to be what's called for. Since the status and output mean little or nothing when the command is executed in the background, perhaps a better alternative would be to add a new function to the module which doesn't return either, but dumps stdout and stderr to /dev/null. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 08:34 Message: Logged In: YES user_id=849994 Originator: NO I think now that the subprocess module is there, it should be used. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=891832&group_id=5470 From noreply at sourceforge.net Wed Mar 14 09:36:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 01:36:38 -0700 Subject: [ python-Bugs-506100 ] commands.getstatusoutput(): cmd.exe support Message-ID: Bugs item #506100, was opened at 2002-01-20 18:13 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=506100&group_id=5470 Please note that this 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: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Pierre Rouleau (pierre_rouleau) Assigned to: Nobody/Anonymous (nobody) Summary: commands.getstatusoutput(): cmd.exe support Initial Comment: ##commands.getstatusoutput(): Does not support for DOS-type shells # ------------------------------------------------------------- # # Inside commands.py, the getstatusoutput() function is not capable of running a # DOS-type shell command. The current code assumes that the operating system # is running a Unix-type shell. # # The old code is: def getstatusoutput(cmd): """Return (status, output) of executing cmd in a shell.""" import os pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r') text = pipe.read() sts = pipe.close() if sts is None: sts = 0 if text[-1:] == '\n': text = text[:-1] return sts, text # I propose that we update that code to check the operating system and support # DOS-style shells (for DOS, NT, OS/2) with the following modified code: def getstatusoutput(cmd): """Return (status, output) of executing cmd in a shell.""" import os if os.name in ['nt', 'dos', 'os2'] : # use Dos style command shell for NT, DOS and OS/2 pipe = os.popen(cmd + ' 2>&1', 'r') else : # use Unix style for all others pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r') text = pipe.read() sts = pipe.close() if sts is None: sts = 0 if text[-1:] == '\n': text = text[:-1] return sts, text ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 08:36 Message: Logged In: YES user_id=849994 Originator: NO commands.py explicitly states "UNIX only". Anyway, nowadays you should use the subprocess module for such tasks. ---------------------------------------------------------------------- Comment By: Pierre Rouleau (pierre_rouleau) Date: 2002-01-24 01:14 Message: Logged In: YES user_id=420631 The changed proposed is for DOS-type shells, not DOS itself (as far as I know pure MS-DOS or PC-DOS are not supported). But Win32 platforms are (NT, 2000, ...) and they use the same type of native command interpreter shell. With the proposed change getstatusoutput() works in those. cmd.exe is available in NT, 2000 and also in OS/2. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-01-23 08:05 Message: Logged In: YES user_id=21627 My first reaction to this was "Is DOS still supported"? Changing subject to mention cmd.exe (which is not a DOS application). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=506100&group_id=5470 From noreply at sourceforge.net Wed Mar 14 09:44:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 01:44:47 -0700 Subject: [ python-Bugs-1197883 ] Installation path sent to configure Message-ID: Bugs item #1197883, was opened at 2005-05-08 22:56 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1197883&group_id=5470 Please note that this 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: Closed >Resolution: Duplicate Priority: 5 Private: No 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. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 08:44 Message: Logged In: YES user_id=849994 Originator: NO Duplicate of #1676135. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1197883&group_id=5470 From noreply at sourceforge.net Wed Mar 14 13:17:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 05:17:55 -0700 Subject: [ python-Bugs-1680034 ] Importing SystemRandom wastes entropy. Message-ID: Bugs item #1680034, was opened at 2007-03-13 17:17 Message generated for change (Comment added) made by stephent98 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1680034&group_id=5470 Please note that this 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 Private: No Submitted By: Steve Tyler (stephent98) Assigned to: Nobody/Anonymous (nobody) Summary: Importing SystemRandom wastes entropy. Initial Comment: Importing SystemRandom wastes entropy. The strace snippet shows a 16 byte read from /dev/urandom, which is presumably done to seed a random number generator. However SystemRandom does not need a seed, so the read is not needed. test case: #!/usr/bin/python from random import SystemRandom strace snippet: open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 4 read(4, "\\\333\277Q\243>K\350 \321\316\26_\271\364~", 16) = 16 close(4) = 0 Python version: python-2.4.4-1.fc6 (Fedora Core 6) ---------------------------------------------------------------------- >Comment By: Steve Tyler (stephent98) Date: 2007-03-14 12:17 Message: Logged In: YES user_id=1741843 Originator: YES Here is how I monitor the entropy: watch -d -n 1 cat /proc/sys/kernel/random/entropy_avail Repeatedly running this script will consume almost all system entropy: #!/usr/bin/python import gnome.ui For the record, the entropy-hog in this test case is not Python-related: #6 0x007742ae in fread () from /lib/libc.so.6 #7 0x0014cfd9 in g_rand_new () from /lib/libglib-2.0.so.0 #8 0x043eef5c in ORBit_genuid_init () from /usr/lib/libORBit-2.so.0 #9 0x043f5892 in CORBA_ORB_init () from /usr/lib/libORBit-2.so.0 #10 0x045596de in bonobo_activation_orb_init () from /usr/lib/libbonobo-activation.so.4 #11 0x04559b46 in bonobo_activation_init () from /usr/lib/libbonobo-activation.so.4 #12 0x002a5317 in initactivation () from /usr/lib/python2.4/site-packages/gtk-2.0/bonobo/activation.so #13 0x049d2f48 in _PyImport_LoadDynamicModule () from /usr/lib/libpython2.4.so.1.0 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2007-03-13 20:17 Message: Logged In: YES user_id=80475 Originator: NO Sorry, am closing this as won't fix. The 16 bytes are used to seed the MersenneTwister which is used by tempfile.py upon startup. That is a reasonable use of the resource. FWIW, it is possible for you to recover most of those 16 bytes of entropy just by calling the twister itself. Also, it is my understanding that /dev/urandom is continuously refilling its hardware based entropy source (so the supply is limitless, but not instant). ---------------------------------------------------------------------- Comment By: Steve Tyler (stephent98) Date: 2007-03-13 19:08 Message: Logged In: YES user_id=1741843 Originator: YES Here is a little more background on why wasting entropy is a problem. "When accessed as /dev/urandom, as many bytes as are requested are returned even when the entropy pool is exhausted." http://www.linux.com/howtos/Secure-Programs-HOWTO/random-numbers.shtml When the entropy pool is exhausted, the Linux RNG (accessed via /dev/urandom) behaves like a pseudo-random number generator, which is not acceptable for cryptographic applications such as password generators. Analysis of the Linux Random Number Generator http://www.pinkas.net/PAPERS/gpr06.pdf Of course one can work around this issue by not using the "random" module and accessing /dev/urandom or /dev/random directly. For some perspective, simply importing the gnome.ui module consumes 4096 bytes of random data in a library I have not been able to completely identify. (I don't think it is Python, though.) ---------------------------------------------------------------------- Comment By: Steve Tyler (stephent98) Date: 2007-03-13 18:30 Message: Logged In: YES user_id=1741843 Originator: YES Entropy is not an unlimited quantity, therefore the existing behavior is undesirable. My app is a random password generator which may need the entropy for itself. https://sourceforge.net/projects/gnome-password/ ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 17:32 Message: Logged In: YES user_id=849994 Originator: NO This is not caused by SystemRandom, but by instantiating (and thereby seeding) the normal (Mersenne Twister) random number generator, which is done automatically when random is imported. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1680034&group_id=5470 From noreply at sourceforge.net Wed Mar 14 13:58:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 05:58:00 -0700 Subject: [ python-Bugs-1582282 ] email.header decode within word Message-ID: Bugs item #1582282, was opened at 2006-10-22 09:16 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582282&group_id=5470 Please note that this 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.5 Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.header decode within word Initial Comment: The problem is filed in mailman bug report: http://sourceforge.net/tracker/index.php?func=detail&aid=1578539&group_id=103&atid=100103 While Microsoft Entourage's way of encoding iso-8859-1 text is not compliant with RFC-2047, Python email.header.decode_header should treat this 'word' as a simple us-ascii string and should not parse into series of string/charset list. Sm=?ISO-8859-1?B?9g==?=rg=?ISO-8859-1?B?5Q==?=sbord should be parsed as [('Sm=?ISO-8859-1?B?9rg==?=g=?ISO-8859-1?B?5Q==?=sbord', None)], not as [('Sm', None), ('\xf6', 'iso-8859-1'), ('g', None), ('\xe5', 'iso-8859-1'), ('sbord', None)] ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2007-03-14 08:58 Message: Logged In: YES user_id=12800 Originator: NO Whoops! Resolution should have been "Fixed" ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2007-03-14 01:00 Message: Logged In: YES user_id=12800 Originator: NO r54370 for Python 2.5 r54371 for Python 2.6 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582282&group_id=5470 From noreply at sourceforge.net Wed Mar 14 16:39:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 08:39:02 -0700 Subject: [ python-Bugs-1486335 ] httplib: read/_read_chunked failes with ValueError sometime Message-ID: Bugs item #1486335, was opened at 2006-05-11 04:14 Message generated for change (Comment added) made by altman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486335&group_id=5470 Please note that this 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 Private: No Submitted By: kxroberto (kxroberto) Assigned to: Greg Ward (gward) Summary: httplib: read/_read_chunked failes with ValueError sometime Initial Comment: This occasionally shows up in a logged trace, when a application crahes on ValueError on a http(s)_response.read() : (py2.3.5 - yet relevant httplib code is still the same in current httplib) .... \' File "socket.pyo", line 283, in read\\n\', \' File "httplib.pyo", line 389, in read\\n\', \' File "httplib.pyo", line 426, in _read_chunked\\n\', \'ValueError: invalid literal for int(): \\n\'] ::: its the line: chunk_left = int(line, 16) Don't know what this line is about. Yet, that should be protected, as a http_response.read() should not fail with ValueError, but only with IOError/EnvironmentError, socket.error - otherwise Error Exception handling becomes a random task. -Robert Side note regarding IO exception handling: See also FR #1481036 (IOBaseError): why socket.error.__bases__ is (,) ? ---------------------------------------------------------------------- Comment By: Patrick Altman (altman) Date: 2007-03-14 10:39 Message: Logged In: YES user_id=405010 Originator: NO I am attempting to use a HEAD request against Amazon S3 to check whether a file exists or not and if it does parse the md5 hash from the ETag in the response to verify the contents of the file so as to save on bandwidth of uploading files when it is not necessary. If the file exist, the HEAD works as expected and I get valid headers back that I can parse and pull the ETag out of the dictionary using getheader('ETag')[1:-1] (using the slice to trim off the double-quotes in the string. The problem lies when I attempt to send a HEAD request when no file exists. As expected, a 404 Not Found response is sent back from Amazon however, my test scripts seem to hang. I run python with trace.py and it hangs here: --- modulename: httplib, funcname: _read_chunked httplib.py(536): assert self.chunked != _UNKNOWN httplib.py(537): chunk_left = self.chunk_left httplib.py(538): value = '' httplib.py(542): while True: httplib.py(543): if chunk_left is None: httplib.py(544): line = self.fp.readline() --- modulename: socket, funcname: readline socket.py(321): data = self._rbuf socket.py(322): if size < 0: socket.py(324): if self._rbufsize <= 1: socket.py(326): assert data == "" socket.py(327): buffers = [] socket.py(328): recv = self._sock.recv socket.py(329): while data != "\n": socket.py(330): data = recv(1) It eventually completes with an exception here: File "C:\Python25\lib\httplib.py", line 509, in read return self._read_chunked(amt) File "C:\Python25\lib\httplib.py", line 548, in _read_chunked chunk_left = int(line, 16) ValueError: invalid literal for int() with base 16: '' For reference, ethereal captured the following request and response: HEAD HTTP/1.1 Host: s3.amazonaws.com Accept-Encoding: identity Date: Tue, 13 Mar 2007 02:54:12 GMT Authorization: AWS HTTP/1.1 404 Not Found x-amz-request-id: E20B4C0D0C48B2EF x-amz-id-2: Content-Type: application/xml Transfer-Encoding: chunked Date: Tue, 13 Mar 2007 02:54:16 GMT Server: AmazonS3 ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-08-07 19:23 Message: Logged In: YES user_id=261020 I think it's only worth worrying about bad chunking that a) has been observed in the wild (though not necessarily by us) and b) popular browsers can cope with. Greg: """If there is an error here, it's at EOF, so it's not that big a deal.""" That's only if the response will be closed at the end of the current transaction. Quoting from 1411097: """if the connection will not close at the end of the transaction, the behaviour should not change from what's currently in SVN (we should not assume that the chunked response has ended unless we see the proper terminating CRLF).""" Perhaps we don't need to be quite as strict as that, but the point is that otherwise, how do we know the server hasn't already sent that last CRLF, and that it will turn up in three weeks' time?-) If that happens, not sure exactly how httplib will treat the CRLF and possible chunked encoding trailers, but I suspect something bad happens. Perhaps we could just always close the connection in this case? I'm not confident I know yet how best to fix these issues. I just tried reading curl's transfer.c and http_chunks.c. I discovered only that I have to be fully awake to read a 1200 line function :-/ ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2006-07-25 21:13 Message: Logged In: YES user_id=14422 OK, I've been working on this some more and I have a very crude addition to test_httplib.py. I'm going to attach it here and solicit feedback on python-dev: I'm not sure how many kinds of bad response chunking I really want to worry about. ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2006-07-24 14:38 Message: Logged In: YES user_id=14422 I'm seeing this with Python 2.3.5 and 2.4.3 hitting a PHP app and getting a large error page. It looks as though the server is incorrectly chunking the response: lwp-request at least gives a better error message than httplib.py: $ GET "http://..." 500 EOF when chunk header expected I'm unclear on precisely what the server is doing wrong. The response looks like this: HTTP/1.1 200 OK Date: Mon, 24 Jul 2006 19:18:47 GMT Server: Apache/2.0.54 (Fedora) X-Powered-By: PHP/4.3.11 Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=UTF-8 2169\r\n \r\n [...first 0x2169 bytes of response...]\r\n 20b2\r\n [...next 0x20b2 bytes...] [...repeat many times...] 20b2\r\n [...the last 0x20b2 bytes...] \r\n The blank line at eof appears to be confusing httplib.py: it bombs because int('', 16) raises ValueError. Observation #1: if this is indeed a protocol error (ie. the server is in the wrong), httplib.py should turn the ValueError into an HTTPException. Perhaps it should define a new exception class for low-level protocol errors (bad chunking). Maybe it should reuse IncompleteRead. Observation #2: gee, my web browser doesn't barf on this response, so why should httplib.py? If there is an error here, it's at EOF, so it's not that big a deal. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486335&group_id=5470 From noreply at sourceforge.net Wed Mar 14 21:11:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 13:11:47 -0700 Subject: [ python-Bugs-1528074 ] difflib.SequenceMatcher.find_longest_match() wrong result Message-ID: Bugs item #1528074, was opened at 2006-07-25 03:59 Message generated for change (Comment added) made by rtvd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528074&group_id=5470 Please note that this 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 Private: No Submitted By: John Machin (sjmachin) Assigned to: Tim Peters (tim_one) Summary: difflib.SequenceMatcher.find_longest_match() wrong result Initial Comment: A short example script is attached. Two strings, each 500 bytes long. Longest match is the first 32 bytes of each string. Result produced is a 10-byte match later in the string. If one byte is chopped off the end of each string (len now 499 each), the correct result is produced. Other observations, none of which may be relevant: 1. Problem may be in the heuristic for "popular" elements in the __chain_b method. In this particular example, the character '0' (which has frequency of 6 in the "b" string) is not "popular" with a len of 500 but is "popular" with a len of 499. 2. '0' is the last byte of the correct longest match. 3. The correct longest match is at the start of the each of the strings. 4. Disabling the "popular" heuristic (like below) appears to make the problem go away: if 0: # if n >= 200 and len(indices) * 100 > n: populardict[elt] = 1 del indices[:] else: indices.append(i) 5. The callable self.isbpopular is created but appears to be unused. 6. The determination of "popular" doesn't accord with the comments, which say 1%. However with len==500, takes 6 to be popular. ---------------------------------------------------------------------- Comment By: Denys Rtveliashvili (rtvd) Date: 2007-03-14 23:11 Message: Logged In: YES user_id=1416496 Originator: NO By the way, I found that the implementation should better be changed completely. The current one has a O(n^2) computational complexity, while the one, based on suffix trees using Ukkonen's algorithm would use only O(n) ---------------------------------------------------------------------- Comment By: Denys Rtveliashvili (rtvd) Date: 2007-03-11 18:29 Message: Logged In: YES user_id=1416496 Originator: NO I have sent a testcase for this bug into the SourceForge. The ID is #1678339. Also I have submitted a fix for this bug (ID #1678345), but the fix reduces the performance significantly. ---------------------------------------------------------------------- Comment By: Denys Rtveliashvili (rtvd) Date: 2007-03-10 20:24 Message: Logged In: YES user_id=1416496 Originator: NO The quick test for this bug is: for i in xrange(190, 200): text1 = "a" + "b"*i text2 = "b"*i + "c" m = difflib.SequenceMatcher(None, text1, text2) (aptr,bptr,l) = m.find_longest_match(0, len(text1), 0, len(text2)) print "i:", i, " l:", l, " aptr:", aptr, " bptr:", bptr assert l == i The assertion will fail when i==199 (the length of the texts will be 200). And yes, the bug is clearly "populardict"-related. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528074&group_id=5470 From noreply at sourceforge.net Wed Mar 14 21:48:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 13:48:03 -0700 Subject: [ python-Bugs-1660009 ] continuing problem with httplib multiple set-cookie headers Message-ID: Bugs item #1660009, was opened at 2007-02-14 19:52 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1660009&group_id=5470 Please note that this 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 Private: No Submitted By: David Margrave (davidma) Assigned to: Nobody/Anonymous (nobody) Summary: continuing problem with httplib multiple set-cookie headers Initial Comment: This is related to [ 432621 ] httplib: multiple Set-Cookie headers, which I was unable to re-open. The workaround that was adopted in the previous bug tracker item was to combine multiple set-cookie headers received from the server, into a single set-cookie element in the headers dictionary, with the cookies joined into a comma-separated string. The problem arises when a comma character appears inside the 'expires' field of one of the cookies. This makes it difficult to split the cookie headers back apart. The comma character should be escaped, or a different separator character used. i.e. expires=Sun, 17-Jan-2038 19:14:07 GMT For now I am using the workaround that gstein suggested, use response.msg.getallmatchingheaders() Python 2.3 has this behavior, and probably later versions. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-03-14 20:48 Message: Logged In: YES user_id=261020 Originator: NO I'm not sure what your complaint is. What's wrong with response.msg.getallmatchingheaders()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1660009&group_id=5470 From noreply at sourceforge.net Wed Mar 14 22:10:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 14:10:00 -0700 Subject: [ python-Bugs-1660009 ] continuing problem with httplib multiple set-cookie headers Message-ID: Bugs item #1660009, was opened at 2007-02-14 19:52 Message generated for change (Comment added) made by davidma You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1660009&group_id=5470 Please note that this 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 Private: No Submitted By: David Margrave (davidma) Assigned to: Nobody/Anonymous (nobody) Summary: continuing problem with httplib multiple set-cookie headers Initial Comment: This is related to [ 432621 ] httplib: multiple Set-Cookie headers, which I was unable to re-open. The workaround that was adopted in the previous bug tracker item was to combine multiple set-cookie headers received from the server, into a single set-cookie element in the headers dictionary, with the cookies joined into a comma-separated string. The problem arises when a comma character appears inside the 'expires' field of one of the cookies. This makes it difficult to split the cookie headers back apart. The comma character should be escaped, or a different separator character used. i.e. expires=Sun, 17-Jan-2038 19:14:07 GMT For now I am using the workaround that gstein suggested, use response.msg.getallmatchingheaders() Python 2.3 has this behavior, and probably later versions. ---------------------------------------------------------------------- >Comment By: David Margrave (davidma) Date: 2007-03-14 21:10 Message: Logged In: YES user_id=31040 Originator: YES getallmatchingheaders() works fine. The problem is with the self.headers in the SimpleHTTPRequestHandler and derived classes. A website may send multiple set-cookie headers, using gmail.com as an example: Set-Cookie: GMAIL_RTT=EXPIRED; Domain=.google.com; Expires=Tue, 13-Mar-07 21:03:04 GMT; Path=/mail Set-Cookie: GMAIL_LOGIN=EXPIRED; Domain=.google.com; Expires=Tue, 13-Mar-07 21:03:04 GMT; Path=/mail The SimpleHTTPRequestHandler class combines multiple set-cookie response headers into a single comma-separated string which it stores in the headers dictionary i.e. self.headers ['set-cookie'] = GMAIL_RTT=EXPIRED; Domain=.google.com; Expires=Tue, 13-Mar-07 21:03:04 GMT; Path=/mail, GMAIL_LOGIN=EXPIRED; Domain=.google.com; Expires=Tue, 13-Mar-07 21:03:04 GMT; Path=/mail The problem is if you try to use code that uses self.headers['set-cookie'] and use string.split to get the original distinct cookie values on the comma delimiter, you'll run into trouble because of the use of the comma character within the cookies' expiration tags, such as Expires=Tue, 13-Mar-07 21:03:04 GMT Again, getallmatchingheaders() is fine as an alternative, but as long as you are going to the trouble of storing multiple set-cookie response headers in the self.headers dict, using a delimiter of some sort, I'd argue you might as well also take care that your delimiter is either unique or escaped within the fields you are delimiting. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-03-14 20:48 Message: Logged In: YES user_id=261020 Originator: NO I'm not sure what your complaint is. What's wrong with response.msg.getallmatchingheaders()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1660009&group_id=5470 From noreply at sourceforge.net Wed Mar 14 22:16:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 14:16:08 -0700 Subject: [ python-Bugs-1681020 ] execfile locks file forever if there are any syntax errors Message-ID: Bugs item #1681020, was opened at 2007-03-14 22:16 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=1681020&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: virwen (virwen) Assigned to: Nobody/Anonymous (nobody) Summary: execfile locks file forever if there are any syntax errors Initial Comment: When I execfile a file which contains a syntax error, the file becomes locked and stays this way all the way until I exit the interpreter (I am unable to delete it, for example). I have tried but failed to find any way to unlock the file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681020&group_id=5470 From noreply at sourceforge.net Wed Mar 14 22:20:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 14:20:42 -0700 Subject: [ python-Bugs-1564508 ] BaseCookie does not support "$Port" Message-ID: Bugs item #1564508, was opened at 2006-09-24 14:05 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564508&group_id=5470 Please note that this 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 Private: No Submitted By: Anders Aagaard (aagaande) Assigned to: Nobody/Anonymous (nobody) Summary: BaseCookie does not support "$Port" Initial Comment: Sending a cookie containing $Port to python's Cookie.py causes this exception: File "/usr/lib64/python2.4/Cookie.py", line 621, in load self.__ParseString(rawdata) File "/usr/lib64/python2.4/Cookie.py", line 646, in __ParseString M[ K[1:] ] = V File "/usr/lib64/python2.4/Cookie.py", line 437, in __setitem__ raise CookieError("Invalid Attribute %s" % K) CookieError: Invalid Attribute port For RFC2965 compatibility more keys has to be added to the Morsel class in the same file. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-03-14 21:20 Message: Logged In: YES user_id=261020 Originator: NO Why do you want RFC 2965 compatibility? I'm not trolling; RFC 2965 is dead as an internet protocol (except as a basis for implementing the older cookie protocols, as RFC 2965 + compatibility hacks -- but $Port is not relevant in that case). The authors of the RFC gave up on an effort to publish errata to the RFC, due to the complexities and the lack of interest from the internet at large. AFAIK, $Port is not implemented by browsers (except for maybe Opera and lynx, IIRC). It just never caught on. See also http://python.org/sf/1638033 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564508&group_id=5470 From noreply at sourceforge.net Wed Mar 14 23:35:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 15:35:16 -0700 Subject: [ python-Bugs-1681020 ] execfile locks file forever if there are any syntax errors Message-ID: Bugs item #1681020, was opened at 2007-03-14 21:16 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681020&group_id=5470 Please note that this 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.5 >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: virwen (virwen) Assigned to: Nobody/Anonymous (nobody) Summary: execfile locks file forever if there are any syntax errors Initial Comment: When I execfile a file which contains a syntax error, the file becomes locked and stays this way all the way until I exit the interpreter (I am unable to delete it, for example). I have tried but failed to find any way to unlock the file. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 22:35 Message: Logged In: YES user_id=849994 Originator: NO Thanks for the report, this has already been fixed in SVN. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681020&group_id=5470 From noreply at sourceforge.net Wed Mar 14 23:36:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 15:36:00 -0700 Subject: [ python-Bugs-1068268 ] subprocess is not EINTR-safe Message-ID: Bugs item #1068268, was opened at 2004-11-17 22:07 Message generated for change (Comment added) made by mpitt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1068268&group_id=5470 Please note that this 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: 3 Private: No Submitted By: Peter ?strand (astrand) Assigned to: Peter ?strand (astrand) Summary: subprocess is not EINTR-safe Initial Comment: The subprocess module is not safe for use with signals, because it doesn't retry the system calls upon EINTR. However, as far as I understand it, this is true for most other Python modules as well, so it isn't obvious that the subprocess needs to be fixed. The problem was first noticed by John P Speno. ---------------------------------------------------------------------- Comment By: Martin Pitt (mpitt) Date: 2007-03-14 23:36 Message: Logged In: YES user_id=80975 Originator: NO I updated Peter's original patch to 2.5+svn fixes and added proper tests to test_subprocess.py. It works great now. What do you think about this approach? Fixing it only in submodule feels a bit strange, but then again, this is meant to be an easy to use abstraction, and most of the people that were hit by this (according to Google) encountered the problem in subprocess. I don't see how to attach something here, so I attached the updated patch to the Ubuntu bug (https://launchpad.net/bugs/87292): http://librarian.launchpad.net/6807594/subprocess-eintr-safety.patch Thanks, Martin ---------------------------------------------------------------------- Comment By: Martin Pitt (mpitt) Date: 2007-02-26 13:15 Message: Logged In: YES user_id=80975 Originator: NO I just got two different Ubuntu bug reports about this problem as well, and I'm unsure how to circumvent this at the application level. http://librarian.launchpad.net/6514580/Traceback.txt http://librarian.launchpad.net/6527195/Traceback.txt (from https://launchpad.net/bugs/87292 and its duplicate) ---------------------------------------------------------------------- Comment By: Matt Johnston (mattjohnston) Date: 2004-12-22 08:07 Message: Logged In: YES user_id=785805 I've hit this on a Solaris 9 box without explicitly using signals. Using the DCOracle module, a seperate Oracle process is executed. When this terminates, a SIGCHLD is sent to the calling python process, which may be in the middle of a select() in the communicate() call, causing EINTR. From the output of truss (like strace), a sigchld handler doesn't appear to be getting explicitly installed by the Oracle module. SunOS 5.9 Generic_112233-01 sun4u sparc SUNW,Sun-Fire-280R ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2004-11-17 22:15 Message: Logged In: YES user_id=344921 One way of testing subprocess for signal-safeness is to insert these lines just after _cleanup(): import signal signal.signal(signal.SIGALRM, lambda x,y: 1) signal.alarm(1) import time time.sleep(0.99) Then run test_subprocess.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1068268&group_id=5470 From noreply at sourceforge.net Thu Mar 15 00:57:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 16:57:41 -0700 Subject: [ python-Bugs-1660009 ] continuing problem with httplib multiple set-cookie headers Message-ID: Bugs item #1660009, was opened at 2007-02-14 19:52 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1660009&group_id=5470 Please note that this 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 Private: No Submitted By: David Margrave (davidma) Assigned to: Nobody/Anonymous (nobody) Summary: continuing problem with httplib multiple set-cookie headers Initial Comment: This is related to [ 432621 ] httplib: multiple Set-Cookie headers, which I was unable to re-open. The workaround that was adopted in the previous bug tracker item was to combine multiple set-cookie headers received from the server, into a single set-cookie element in the headers dictionary, with the cookies joined into a comma-separated string. The problem arises when a comma character appears inside the 'expires' field of one of the cookies. This makes it difficult to split the cookie headers back apart. The comma character should be escaped, or a different separator character used. i.e. expires=Sun, 17-Jan-2038 19:14:07 GMT For now I am using the workaround that gstein suggested, use response.msg.getallmatchingheaders() Python 2.3 has this behavior, and probably later versions. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-03-14 23:57 Message: Logged In: YES user_id=261020 Originator: NO SimpleHTTPRequestHandler is not part of httplib. Did you mean to refer to module SimpleHTTPServer rather than httplib, perhaps? I don't see the particular bit of code you refer to (neither in httplib nor in module SimpleHTTPServer), but re the general issue: Regardless of the fact that RFC 2616 ss. 4.2 says headers MUST be able to be combined with commas, Netscape Set-Cookie headers simply don't work that way, and Netscape Set-Cookie headers are here to stay. So, Set-Cookie headers must not be combined. (Quoting does not help, because Netscape Set-Cookie headers contain cookie values that 1. may contain commas and 2. do not support quoting -- any quote (") characters are in fact part of the cookie value itself rather than being part of a quoting mechanism. And there is no precedent for any choice of delimter other than a comma, nor for any other Netscape Set-Cookie cookie value quoting mechanism.) ---------------------------------------------------------------------- Comment By: David Margrave (davidma) Date: 2007-03-14 21:10 Message: Logged In: YES user_id=31040 Originator: YES getallmatchingheaders() works fine. The problem is with the self.headers in the SimpleHTTPRequestHandler and derived classes. A website may send multiple set-cookie headers, using gmail.com as an example: Set-Cookie: GMAIL_RTT=EXPIRED; Domain=.google.com; Expires=Tue, 13-Mar-07 21:03:04 GMT; Path=/mail Set-Cookie: GMAIL_LOGIN=EXPIRED; Domain=.google.com; Expires=Tue, 13-Mar-07 21:03:04 GMT; Path=/mail The SimpleHTTPRequestHandler class combines multiple set-cookie response headers into a single comma-separated string which it stores in the headers dictionary i.e. self.headers ['set-cookie'] = GMAIL_RTT=EXPIRED; Domain=.google.com; Expires=Tue, 13-Mar-07 21:03:04 GMT; Path=/mail, GMAIL_LOGIN=EXPIRED; Domain=.google.com; Expires=Tue, 13-Mar-07 21:03:04 GMT; Path=/mail The problem is if you try to use code that uses self.headers['set-cookie'] and use string.split to get the original distinct cookie values on the comma delimiter, you'll run into trouble because of the use of the comma character within the cookies' expiration tags, such as Expires=Tue, 13-Mar-07 21:03:04 GMT Again, getallmatchingheaders() is fine as an alternative, but as long as you are going to the trouble of storing multiple set-cookie response headers in the self.headers dict, using a delimiter of some sort, I'd argue you might as well also take care that your delimiter is either unique or escaped within the fields you are delimiting. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-03-14 20:48 Message: Logged In: YES user_id=261020 Originator: NO I'm not sure what your complaint is. What's wrong with response.msg.getallmatchingheaders()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1660009&group_id=5470 From noreply at sourceforge.net Thu Mar 15 01:30:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 17:30:34 -0700 Subject: [ python-Bugs-1660009 ] continuing problem with httplib multiple set-cookie headers Message-ID: Bugs item #1660009, was opened at 2007-02-14 19:52 Message generated for change (Comment added) made by davidma You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1660009&group_id=5470 Please note that this 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 Private: No Submitted By: David Margrave (davidma) Assigned to: Nobody/Anonymous (nobody) Summary: continuing problem with httplib multiple set-cookie headers Initial Comment: This is related to [ 432621 ] httplib: multiple Set-Cookie headers, which I was unable to re-open. The workaround that was adopted in the previous bug tracker item was to combine multiple set-cookie headers received from the server, into a single set-cookie element in the headers dictionary, with the cookies joined into a comma-separated string. The problem arises when a comma character appears inside the 'expires' field of one of the cookies. This makes it difficult to split the cookie headers back apart. The comma character should be escaped, or a different separator character used. i.e. expires=Sun, 17-Jan-2038 19:14:07 GMT For now I am using the workaround that gstein suggested, use response.msg.getallmatchingheaders() Python 2.3 has this behavior, and probably later versions. ---------------------------------------------------------------------- >Comment By: David Margrave (davidma) Date: 2007-03-15 00:30 Message: Logged In: YES user_id=31040 Originator: YES fair enough, the RFC says thay have to be joinable with commas, so the behavior is correct. I can get by with getallmatchingheaders if I need access to the original individual cookie values. thanks, dave ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-03-14 23:57 Message: Logged In: YES user_id=261020 Originator: NO SimpleHTTPRequestHandler is not part of httplib. Did you mean to refer to module SimpleHTTPServer rather than httplib, perhaps? I don't see the particular bit of code you refer to (neither in httplib nor in module SimpleHTTPServer), but re the general issue: Regardless of the fact that RFC 2616 ss. 4.2 says headers MUST be able to be combined with commas, Netscape Set-Cookie headers simply don't work that way, and Netscape Set-Cookie headers are here to stay. So, Set-Cookie headers must not be combined. (Quoting does not help, because Netscape Set-Cookie headers contain cookie values that 1. may contain commas and 2. do not support quoting -- any quote (") characters are in fact part of the cookie value itself rather than being part of a quoting mechanism. And there is no precedent for any choice of delimter other than a comma, nor for any other Netscape Set-Cookie cookie value quoting mechanism.) ---------------------------------------------------------------------- Comment By: David Margrave (davidma) Date: 2007-03-14 21:10 Message: Logged In: YES user_id=31040 Originator: YES getallmatchingheaders() works fine. The problem is with the self.headers in the SimpleHTTPRequestHandler and derived classes. A website may send multiple set-cookie headers, using gmail.com as an example: Set-Cookie: GMAIL_RTT=EXPIRED; Domain=.google.com; Expires=Tue, 13-Mar-07 21:03:04 GMT; Path=/mail Set-Cookie: GMAIL_LOGIN=EXPIRED; Domain=.google.com; Expires=Tue, 13-Mar-07 21:03:04 GMT; Path=/mail The SimpleHTTPRequestHandler class combines multiple set-cookie response headers into a single comma-separated string which it stores in the headers dictionary i.e. self.headers ['set-cookie'] = GMAIL_RTT=EXPIRED; Domain=.google.com; Expires=Tue, 13-Mar-07 21:03:04 GMT; Path=/mail, GMAIL_LOGIN=EXPIRED; Domain=.google.com; Expires=Tue, 13-Mar-07 21:03:04 GMT; Path=/mail The problem is if you try to use code that uses self.headers['set-cookie'] and use string.split to get the original distinct cookie values on the comma delimiter, you'll run into trouble because of the use of the comma character within the cookies' expiration tags, such as Expires=Tue, 13-Mar-07 21:03:04 GMT Again, getallmatchingheaders() is fine as an alternative, but as long as you are going to the trouble of storing multiple set-cookie response headers in the self.headers dict, using a delimiter of some sort, I'd argue you might as well also take care that your delimiter is either unique or escaped within the fields you are delimiting. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-03-14 20:48 Message: Logged In: YES user_id=261020 Originator: NO I'm not sure what your complaint is. What's wrong with response.msg.getallmatchingheaders()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1660009&group_id=5470 From noreply at sourceforge.net Thu Mar 15 01:45:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 17:45:03 -0700 Subject: [ python-Bugs-1660009 ] continuing problem with httplib multiple set-cookie headers Message-ID: Bugs item #1660009, was opened at 2007-02-14 19:52 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1660009&group_id=5470 Please note that this 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 Private: No Submitted By: David Margrave (davidma) Assigned to: Nobody/Anonymous (nobody) Summary: continuing problem with httplib multiple set-cookie headers Initial Comment: This is related to [ 432621 ] httplib: multiple Set-Cookie headers, which I was unable to re-open. The workaround that was adopted in the previous bug tracker item was to combine multiple set-cookie headers received from the server, into a single set-cookie element in the headers dictionary, with the cookies joined into a comma-separated string. The problem arises when a comma character appears inside the 'expires' field of one of the cookies. This makes it difficult to split the cookie headers back apart. The comma character should be escaped, or a different separator character used. i.e. expires=Sun, 17-Jan-2038 19:14:07 GMT For now I am using the workaround that gstein suggested, use response.msg.getallmatchingheaders() Python 2.3 has this behavior, and probably later versions. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-03-15 00:45 Message: Logged In: YES user_id=261020 Originator: NO Huh? 1. *What* behaviour is correct? You still have not said which bit of code you're talking about, or even which module. 2. You seem to have got the sense of what I said backwards. As I said, RFC 2616 is (in practice) WRONG about joining with commas being OK for Set-Cookie. Set-Cookies headers must NOT be joined with commas, despite what RFC 2616 says. ---------------------------------------------------------------------- Comment By: David Margrave (davidma) Date: 2007-03-15 00:30 Message: Logged In: YES user_id=31040 Originator: YES fair enough, the RFC says thay have to be joinable with commas, so the behavior is correct. I can get by with getallmatchingheaders if I need access to the original individual cookie values. thanks, dave ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-03-14 23:57 Message: Logged In: YES user_id=261020 Originator: NO SimpleHTTPRequestHandler is not part of httplib. Did you mean to refer to module SimpleHTTPServer rather than httplib, perhaps? I don't see the particular bit of code you refer to (neither in httplib nor in module SimpleHTTPServer), but re the general issue: Regardless of the fact that RFC 2616 ss. 4.2 says headers MUST be able to be combined with commas, Netscape Set-Cookie headers simply don't work that way, and Netscape Set-Cookie headers are here to stay. So, Set-Cookie headers must not be combined. (Quoting does not help, because Netscape Set-Cookie headers contain cookie values that 1. may contain commas and 2. do not support quoting -- any quote (") characters are in fact part of the cookie value itself rather than being part of a quoting mechanism. And there is no precedent for any choice of delimter other than a comma, nor for any other Netscape Set-Cookie cookie value quoting mechanism.) ---------------------------------------------------------------------- Comment By: David Margrave (davidma) Date: 2007-03-14 21:10 Message: Logged In: YES user_id=31040 Originator: YES getallmatchingheaders() works fine. The problem is with the self.headers in the SimpleHTTPRequestHandler and derived classes. A website may send multiple set-cookie headers, using gmail.com as an example: Set-Cookie: GMAIL_RTT=EXPIRED; Domain=.google.com; Expires=Tue, 13-Mar-07 21:03:04 GMT; Path=/mail Set-Cookie: GMAIL_LOGIN=EXPIRED; Domain=.google.com; Expires=Tue, 13-Mar-07 21:03:04 GMT; Path=/mail The SimpleHTTPRequestHandler class combines multiple set-cookie response headers into a single comma-separated string which it stores in the headers dictionary i.e. self.headers ['set-cookie'] = GMAIL_RTT=EXPIRED; Domain=.google.com; Expires=Tue, 13-Mar-07 21:03:04 GMT; Path=/mail, GMAIL_LOGIN=EXPIRED; Domain=.google.com; Expires=Tue, 13-Mar-07 21:03:04 GMT; Path=/mail The problem is if you try to use code that uses self.headers['set-cookie'] and use string.split to get the original distinct cookie values on the comma delimiter, you'll run into trouble because of the use of the comma character within the cookies' expiration tags, such as Expires=Tue, 13-Mar-07 21:03:04 GMT Again, getallmatchingheaders() is fine as an alternative, but as long as you are going to the trouble of storing multiple set-cookie response headers in the self.headers dict, using a delimiter of some sort, I'd argue you might as well also take care that your delimiter is either unique or escaped within the fields you are delimiting. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-03-14 20:48 Message: Logged In: YES user_id=261020 Originator: NO I'm not sure what your complaint is. What's wrong with response.msg.getallmatchingheaders()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1660009&group_id=5470 From noreply at sourceforge.net Thu Mar 15 01:58:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 17:58:36 -0700 Subject: [ python-Bugs-1660009 ] continuing problem with httplib multiple set-cookie headers Message-ID: Bugs item #1660009, was opened at 2007-02-14 19:52 Message generated for change (Comment added) made by davidma You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1660009&group_id=5470 Please note that this 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 Private: No Submitted By: David Margrave (davidma) Assigned to: Nobody/Anonymous (nobody) Summary: continuing problem with httplib multiple set-cookie headers Initial Comment: This is related to [ 432621 ] httplib: multiple Set-Cookie headers, which I was unable to re-open. The workaround that was adopted in the previous bug tracker item was to combine multiple set-cookie headers received from the server, into a single set-cookie element in the headers dictionary, with the cookies joined into a comma-separated string. The problem arises when a comma character appears inside the 'expires' field of one of the cookies. This makes it difficult to split the cookie headers back apart. The comma character should be escaped, or a different separator character used. i.e. expires=Sun, 17-Jan-2038 19:14:07 GMT For now I am using the workaround that gstein suggested, use response.msg.getallmatchingheaders() Python 2.3 has this behavior, and probably later versions. ---------------------------------------------------------------------- >Comment By: David Margrave (davidma) Date: 2007-03-15 00:58 Message: Logged In: YES user_id=31040 Originator: YES See the addheader method of the HTTPMessage class in httplib.py def addheader(self, key, value): """Add header for field key handling repeats.""" prev = self.dict.get(key) if prev is None: self.dict[key] = value else: combined = ", ".join((prev, value)) self.dict[key] = combined also see the original tracker entry where this fix was first discussed & implemented https://sourceforge.net/tracker/index.php?func=detail&aid=432621&group_id=5470&atid=105470 ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-03-15 00:45 Message: Logged In: YES user_id=261020 Originator: NO Huh? 1. *What* behaviour is correct? You still have not said which bit of code you're talking about, or even which module. 2. You seem to have got the sense of what I said backwards. As I said, RFC 2616 is (in practice) WRONG about joining with commas being OK for Set-Cookie. Set-Cookies headers must NOT be joined with commas, despite what RFC 2616 says. ---------------------------------------------------------------------- Comment By: David Margrave (davidma) Date: 2007-03-15 00:30 Message: Logged In: YES user_id=31040 Originator: YES fair enough, the RFC says thay have to be joinable with commas, so the behavior is correct. I can get by with getallmatchingheaders if I need access to the original individual cookie values. thanks, dave ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-03-14 23:57 Message: Logged In: YES user_id=261020 Originator: NO SimpleHTTPRequestHandler is not part of httplib. Did you mean to refer to module SimpleHTTPServer rather than httplib, perhaps? I don't see the particular bit of code you refer to (neither in httplib nor in module SimpleHTTPServer), but re the general issue: Regardless of the fact that RFC 2616 ss. 4.2 says headers MUST be able to be combined with commas, Netscape Set-Cookie headers simply don't work that way, and Netscape Set-Cookie headers are here to stay. So, Set-Cookie headers must not be combined. (Quoting does not help, because Netscape Set-Cookie headers contain cookie values that 1. may contain commas and 2. do not support quoting -- any quote (") characters are in fact part of the cookie value itself rather than being part of a quoting mechanism. And there is no precedent for any choice of delimter other than a comma, nor for any other Netscape Set-Cookie cookie value quoting mechanism.) ---------------------------------------------------------------------- Comment By: David Margrave (davidma) Date: 2007-03-14 21:10 Message: Logged In: YES user_id=31040 Originator: YES getallmatchingheaders() works fine. The problem is with the self.headers in the SimpleHTTPRequestHandler and derived classes. A website may send multiple set-cookie headers, using gmail.com as an example: Set-Cookie: GMAIL_RTT=EXPIRED; Domain=.google.com; Expires=Tue, 13-Mar-07 21:03:04 GMT; Path=/mail Set-Cookie: GMAIL_LOGIN=EXPIRED; Domain=.google.com; Expires=Tue, 13-Mar-07 21:03:04 GMT; Path=/mail The SimpleHTTPRequestHandler class combines multiple set-cookie response headers into a single comma-separated string which it stores in the headers dictionary i.e. self.headers ['set-cookie'] = GMAIL_RTT=EXPIRED; Domain=.google.com; Expires=Tue, 13-Mar-07 21:03:04 GMT; Path=/mail, GMAIL_LOGIN=EXPIRED; Domain=.google.com; Expires=Tue, 13-Mar-07 21:03:04 GMT; Path=/mail The problem is if you try to use code that uses self.headers['set-cookie'] and use string.split to get the original distinct cookie values on the comma delimiter, you'll run into trouble because of the use of the comma character within the cookies' expiration tags, such as Expires=Tue, 13-Mar-07 21:03:04 GMT Again, getallmatchingheaders() is fine as an alternative, but as long as you are going to the trouble of storing multiple set-cookie response headers in the self.headers dict, using a delimiter of some sort, I'd argue you might as well also take care that your delimiter is either unique or escaped within the fields you are delimiting. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-03-14 20:48 Message: Logged In: YES user_id=261020 Originator: NO I'm not sure what your complaint is. What's wrong with response.msg.getallmatchingheaders()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1660009&group_id=5470 From noreply at sourceforge.net Thu Mar 15 03:33:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 19:33:57 -0700 Subject: [ python-Bugs-1328278 ] __getslice__ taking priority over __getitem__ Message-ID: Bugs item #1328278, was opened at 2005-10-16 18:22 Message generated for change (Comment added) made by stupidgeekman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1328278&group_id=5470 Please note that this 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 Private: No Submitted By: Josh Marshall (jpmarshall) Assigned to: Nobody/Anonymous (nobody) Summary: __getslice__ taking priority over __getitem__ Initial Comment: When creating a class that uses __getitem__ to implement slicing, if __getattr__ is also implemented, slicing will fail. This is due to the (deprecated) __getslice__ method being called before __getitem__. The attached file demonstrates this. If __getitem__ is implemented on its own, all is rosy. When we add __getattr__ and do not raise an AttributeError when __getslice__ is searched for, the slicing fails. If we raise this AttributeError, __getitem__ is called next. The only other reference I could find to this bug is on the jython mailing list, from 2003: http://sourceforge.net/mailarchive/forum.php? thread_id=2350972&forum_id=5586 My question is; why is __getslice__ called before __getitem__? I assumed that because it is deprecated, it would be the last resort for a slicing. Is this planned to be fixed, or is there existing behaviour that is reliant on it? ---------------------------------------------------------------------- Comment By: Tim (stupidgeekman) Date: 2007-03-14 19:33 Message: Logged In: YES user_id=1743956 Originator: NO I would suggest that the list class should use the same form suggested on the documentation site, namely: if sys.version_info < (2, 0): # They won't be defined if version is at least 2.0 final def __getslice__(self, i, j): return self[max(0, i):max(0, j):] def __setslice__(self, i, j, seq): self[max(0, i):max(0, j):] = seq def __delslice__(self, i, j): del self[max(0, i):max(0, j):] ... in order to assure that the *slice methods are not defined unless needed for backward compatability in an older interpreter; then classes developed with the above suggested structure should work properly. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-11-11 11:50 Message: Logged In: YES user_id=1188172 You're correct. __getslice__ is supported for backwards compatibility, and its semantics cannot change (before 3.0, that is). ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-10 06:48 Message: Logged In: YES user_id=315535 This seems to be the documented, expected behavior: http://www.python.org/doc/2.4.2/ref/sequence-methods.html As to _why_ __getslice__ is called before __getitem__, I'm not sure - but it's right there in the docs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1328278&group_id=5470 From noreply at sourceforge.net Thu Mar 15 04:57:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 20:57:20 -0700 Subject: [ python-Bugs-1603150 ] wave module forgets to close file on exception Message-ID: Bugs item #1603150, was opened at 2006-11-26 10:59 Message generated for change (Comment added) made by polivare You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603150&group_id=5470 Please note that this 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 Private: No Submitted By: amerinese (amerinese) Assigned to: Nobody/Anonymous (nobody) Summary: wave module forgets to close file on exception Initial Comment: I am using python 2.4 on Windows XP SP2 The wave module function: f = wave.open(file) In the case that file is a path to the file and the file is not yet opened, wave.open(file) may raise an exception if the file is opened and it does not fulfill the format of a WAV file. However, it forgets to close the file when the exception is raised keeping other functions from accessing the file (at least until the file is garbage collected). The regular file opening idiom doesn't work f = wave.open(file) try: ## do something with the wav file finally: f.close() Since wave.open(file) raises an exception before return the file name, f can't be closed, but the file is open. The reason I know this is because I try to delete the file if trying to open it raises an RIFF or not a WAV file exception and it claims the file is locked. ---------------------------------------------------------------------- Comment By: Patricio Olivares (polivare) Date: 2007-03-14 23:57 Message: Logged In: YES user_id=1413642 Originator: NO wave.open expects either a str or a file object. When it gets a str, it opens the file, works on it, and closes the file. All of this in the inner scope of the wave.open function. But if the file pointed by the str is not a correct wav format, then wave.open throws wave.Error but *doesn't close the file*. It assumes that the file will be garbage collected and then closed but that does not happen. I believe that it has to do with the "Note" at The problem is noted mostly on the interactive interpreter on windows because on windows you can't delete/move a file if it's being used by another process so you need to close the interpreter to release the file. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-19 16:59 Message: Logged In: YES user_id=11375 Originator: NO Try putting the Wave.open() inside the try...finally. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603150&group_id=5470 From noreply at sourceforge.net Thu Mar 15 05:08:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 21:08:02 -0700 Subject: [ python-Bugs-1603150 ] wave module forgets to close file on exception Message-ID: Bugs item #1603150, was opened at 2006-11-26 10:59 Message generated for change (Comment added) made by polivare You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603150&group_id=5470 Please note that this 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 Private: No Submitted By: amerinese (amerinese) Assigned to: Nobody/Anonymous (nobody) Summary: wave module forgets to close file on exception Initial Comment: I am using python 2.4 on Windows XP SP2 The wave module function: f = wave.open(file) In the case that file is a path to the file and the file is not yet opened, wave.open(file) may raise an exception if the file is opened and it does not fulfill the format of a WAV file. However, it forgets to close the file when the exception is raised keeping other functions from accessing the file (at least until the file is garbage collected). The regular file opening idiom doesn't work f = wave.open(file) try: ## do something with the wav file finally: f.close() Since wave.open(file) raises an exception before return the file name, f can't be closed, but the file is open. The reason I know this is because I try to delete the file if trying to open it raises an RIFF or not a WAV file exception and it claims the file is locked. ---------------------------------------------------------------------- Comment By: Patricio Olivares (polivare) Date: 2007-03-15 00:08 Message: Logged In: YES user_id=1413642 Originator: NO Simple patch added: [1681153] ---------------------------------------------------------------------- Comment By: Patricio Olivares (polivare) Date: 2007-03-14 23:57 Message: Logged In: YES user_id=1413642 Originator: NO wave.open expects either a str or a file object. When it gets a str, it opens the file, works on it, and closes the file. All of this in the inner scope of the wave.open function. But if the file pointed by the str is not a correct wav format, then wave.open throws wave.Error but *doesn't close the file*. It assumes that the file will be garbage collected and then closed but that does not happen. I believe that it has to do with the "Note" at The problem is noted mostly on the interactive interpreter on windows because on windows you can't delete/move a file if it's being used by another process so you need to close the interpreter to release the file. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-19 16:59 Message: Logged In: YES user_id=11375 Originator: NO Try putting the Wave.open() inside the try...finally. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603150&group_id=5470 From noreply at sourceforge.net Thu Mar 15 08:42:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 00:42:39 -0700 Subject: [ python-Bugs-1603150 ] wave module forgets to close file on exception Message-ID: Bugs item #1603150, was opened at 2006-11-26 13:59 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603150&group_id=5470 Please note that this 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: Fixed Priority: 5 Private: No Submitted By: amerinese (amerinese) Assigned to: Nobody/Anonymous (nobody) Summary: wave module forgets to close file on exception Initial Comment: I am using python 2.4 on Windows XP SP2 The wave module function: f = wave.open(file) In the case that file is a path to the file and the file is not yet opened, wave.open(file) may raise an exception if the file is opened and it does not fulfill the format of a WAV file. However, it forgets to close the file when the exception is raised keeping other functions from accessing the file (at least until the file is garbage collected). The regular file opening idiom doesn't work f = wave.open(file) try: ## do something with the wav file finally: f.close() Since wave.open(file) raises an exception before return the file name, f can't be closed, but the file is open. The reason I know this is because I try to delete the file if trying to open it raises an RIFF or not a WAV file exception and it claims the file is locked. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 07:42 Message: Logged In: YES user_id=849994 Originator: NO Fixed with said patch. ---------------------------------------------------------------------- Comment By: Patricio Olivares (polivare) Date: 2007-03-15 04:08 Message: Logged In: YES user_id=1413642 Originator: NO Simple patch added: [1681153] ---------------------------------------------------------------------- Comment By: Patricio Olivares (polivare) Date: 2007-03-15 03:57 Message: Logged In: YES user_id=1413642 Originator: NO wave.open expects either a str or a file object. When it gets a str, it opens the file, works on it, and closes the file. All of this in the inner scope of the wave.open function. But if the file pointed by the str is not a correct wav format, then wave.open throws wave.Error but *doesn't close the file*. It assumes that the file will be garbage collected and then closed but that does not happen. I believe that it has to do with the "Note" at The problem is noted mostly on the interactive interpreter on windows because on windows you can't delete/move a file if it's being used by another process so you need to close the interpreter to release the file. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-19 19:59 Message: Logged In: YES user_id=11375 Originator: NO Try putting the Wave.open() inside the try...finally. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603150&group_id=5470 From noreply at sourceforge.net Thu Mar 15 09:03:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 01:03:06 -0700 Subject: [ python-Bugs-1681228 ] webbrowser priorities Message-ID: Bugs item #1681228, was opened at 2007-03-15 09:03 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=1681228&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lukas Lalinsky (luks) Assigned to: Nobody/Anonymous (nobody) Summary: webbrowser priorities Initial Comment: Recently I've run into a Windows-specific bug in webbrowser (using close_fds and preexec_fn in subprocess.Popen), and I noticed there are some strange priorities in the default browsers. For example: * Why is firefox, firebird, seamonkey, mozilla, netscape and opera preferred over the *user's* preferred browser on Windows? * Why is the GNOME default browser preferred even if the user is currently running KDE (but has GNOME installed)? >From all the platforms, only on Mac OS X it really respects the user's preferrencies. I'd like to propose this: * On Windows, make "windows-default" the first in _try_order * If the user is running GNOME ("GNOME_DESKTOP_SESSION_ID" in os.environ) and command "gnome-open" exists, use `gnome-open '%s'`. * If the user is running KDE (os.environ.get("KDE_FULL_SESSION") == "true") and command "kfmclient" exists, use `kfmclient exec '%s'`. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681228&group_id=5470 From noreply at sourceforge.net Thu Mar 15 09:06:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 01:06:10 -0700 Subject: [ python-Bugs-1681228 ] webbrowser priorities Message-ID: Bugs item #1681228, was opened at 2007-03-15 09:03 Message generated for change (Comment added) made by luks You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681228&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lukas Lalinsky (luks) Assigned to: Nobody/Anonymous (nobody) Summary: webbrowser priorities Initial Comment: Recently I've run into a Windows-specific bug in webbrowser (using close_fds and preexec_fn in subprocess.Popen), and I noticed there are some strange priorities in the default browsers. For example: * Why is firefox, firebird, seamonkey, mozilla, netscape and opera preferred over the *user's* preferred browser on Windows? * Why is the GNOME default browser preferred even if the user is currently running KDE (but has GNOME installed)? >From all the platforms, only on Mac OS X it really respects the user's preferrencies. I'd like to propose this: * On Windows, make "windows-default" the first in _try_order * If the user is running GNOME ("GNOME_DESKTOP_SESSION_ID" in os.environ) and command "gnome-open" exists, use `gnome-open '%s'`. * If the user is running KDE (os.environ.get("KDE_FULL_SESSION") == "true") and command "kfmclient" exists, use `kfmclient exec '%s'`. ---------------------------------------------------------------------- >Comment By: Lukas Lalinsky (luks) Date: 2007-03-15 09:06 Message: Logged In: YES user_id=587716 Originator: YES Just a note, if you agree with this behavior, I'll be more than happy to make a patch. Currently I'm using similar mechanism in my own code (because Python's lib in 2.4 doesn't respect GNOME/KDE settings at all), so I can easily turn it into a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681228&group_id=5470 From noreply at sourceforge.net Thu Mar 15 09:35:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 01:35:33 -0700 Subject: [ python-Bugs-1681248 ] WindowsError in webbrowser.open Message-ID: Bugs item #1681248, was opened at 2007-03-15 09: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=1681248&group_id=5470 Please note that this 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 Private: No Submitted By: Lukas Lalinsky (luks) Assigned to: Nobody/Anonymous (nobody) Summary: WindowsError in webbrowser.open Initial Comment: On Windows, os.startfile can throw an exception if the URL action is not assigned to any program. I think the function should catch it and return False. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681248&group_id=5470 From noreply at sourceforge.net Thu Mar 15 09:35:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 01:35:54 -0700 Subject: [ python-Bugs-1681248 ] WindowsError in webbrowser.open Message-ID: Bugs item #1681248, was opened at 2007-03-15 09:35 Message generated for change (Settings changed) made by luks You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681248&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lukas Lalinsky (luks) Assigned to: Nobody/Anonymous (nobody) Summary: WindowsError in webbrowser.open Initial Comment: On Windows, os.startfile can throw an exception if the URL action is not assigned to any program. I think the function should catch it and return False. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681248&group_id=5470 From noreply at sourceforge.net Thu Mar 15 09:50:27 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 01:50:27 -0700 Subject: [ python-Bugs-1681228 ] webbrowser priorities Message-ID: Bugs item #1681228, was opened at 2007-03-15 08:03 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681228&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lukas Lalinsky (luks) Assigned to: Nobody/Anonymous (nobody) Summary: webbrowser priorities Initial Comment: Recently I've run into a Windows-specific bug in webbrowser (using close_fds and preexec_fn in subprocess.Popen), and I noticed there are some strange priorities in the default browsers. For example: * Why is firefox, firebird, seamonkey, mozilla, netscape and opera preferred over the *user's* preferred browser on Windows? * Why is the GNOME default browser preferred even if the user is currently running KDE (but has GNOME installed)? >From all the platforms, only on Mac OS X it really respects the user's preferrencies. I'd like to propose this: * On Windows, make "windows-default" the first in _try_order * If the user is running GNOME ("GNOME_DESKTOP_SESSION_ID" in os.environ) and command "gnome-open" exists, use `gnome-open '%s'`. * If the user is running KDE (os.environ.get("KDE_FULL_SESSION") == "true") and command "kfmclient" exists, use `kfmclient exec '%s'`. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 08:50 Message: Logged In: YES user_id=849994 Originator: NO I agree with your suggestion. Can you make a patch (and include a fix for the other bug you filed)? ---------------------------------------------------------------------- Comment By: Lukas Lalinsky (luks) Date: 2007-03-15 08:06 Message: Logged In: YES user_id=587716 Originator: YES Just a note, if you agree with this behavior, I'll be more than happy to make a patch. Currently I'm using similar mechanism in my own code (because Python's lib in 2.4 doesn't respect GNOME/KDE settings at all), so I can easily turn it into a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681228&group_id=5470 From noreply at sourceforge.net Thu Mar 15 09:57:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 01:57:22 -0700 Subject: [ python-Bugs-1068268 ] subprocess is not EINTR-safe Message-ID: Bugs item #1068268, was opened at 2004-11-17 22:07 Message generated for change (Comment added) made by mpitt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1068268&group_id=5470 Please note that this 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: 3 Private: No Submitted By: Peter ?strand (astrand) Assigned to: Peter ?strand (astrand) Summary: subprocess is not EINTR-safe Initial Comment: The subprocess module is not safe for use with signals, because it doesn't retry the system calls upon EINTR. However, as far as I understand it, this is true for most other Python modules as well, so it isn't obvious that the subprocess needs to be fixed. The problem was first noticed by John P Speno. ---------------------------------------------------------------------- Comment By: Martin Pitt (mpitt) Date: 2007-03-15 09:57 Message: Logged In: YES user_id=80975 Originator: NO Updated patch: http://librarian.launchpad.net/6820347/subprocess-eintr-safety.patch I removed the _read_all() function, since that broke the 1 MB exception limit and does not seem to be necessary in the first place. ---------------------------------------------------------------------- Comment By: Martin Pitt (mpitt) Date: 2007-03-14 23:36 Message: Logged In: YES user_id=80975 Originator: NO I updated Peter's original patch to 2.5+svn fixes and added proper tests to test_subprocess.py. It works great now. What do you think about this approach? Fixing it only in submodule feels a bit strange, but then again, this is meant to be an easy to use abstraction, and most of the people that were hit by this (according to Google) encountered the problem in subprocess. I don't see how to attach something here, so I attached the updated patch to the Ubuntu bug (https://launchpad.net/bugs/87292): http://librarian.launchpad.net/6807594/subprocess-eintr-safety.patch Thanks, Martin ---------------------------------------------------------------------- Comment By: Martin Pitt (mpitt) Date: 2007-02-26 13:15 Message: Logged In: YES user_id=80975 Originator: NO I just got two different Ubuntu bug reports about this problem as well, and I'm unsure how to circumvent this at the application level. http://librarian.launchpad.net/6514580/Traceback.txt http://librarian.launchpad.net/6527195/Traceback.txt (from https://launchpad.net/bugs/87292 and its duplicate) ---------------------------------------------------------------------- Comment By: Matt Johnston (mattjohnston) Date: 2004-12-22 08:07 Message: Logged In: YES user_id=785805 I've hit this on a Solaris 9 box without explicitly using signals. Using the DCOracle module, a seperate Oracle process is executed. When this terminates, a SIGCHLD is sent to the calling python process, which may be in the middle of a select() in the communicate() call, causing EINTR. From the output of truss (like strace), a sigchld handler doesn't appear to be getting explicitly installed by the Oracle module. SunOS 5.9 Generic_112233-01 sun4u sparc SUNW,Sun-Fire-280R ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2004-11-17 22:15 Message: Logged In: YES user_id=344921 One way of testing subprocess for signal-safeness is to insert these lines just after _cleanup(): import signal signal.signal(signal.SIGALRM, lambda x,y: 1) signal.alarm(1) import time time.sleep(0.99) Then run test_subprocess.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1068268&group_id=5470 From noreply at sourceforge.net Thu Mar 15 12:47:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 04:47:54 -0700 Subject: [ python-Bugs-1681228 ] webbrowser priorities Message-ID: Bugs item #1681228, was opened at 2007-03-15 09:03 Message generated for change (Comment added) made by luks You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681228&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lukas Lalinsky (luks) Assigned to: Nobody/Anonymous (nobody) Summary: webbrowser priorities Initial Comment: Recently I've run into a Windows-specific bug in webbrowser (using close_fds and preexec_fn in subprocess.Popen), and I noticed there are some strange priorities in the default browsers. For example: * Why is firefox, firebird, seamonkey, mozilla, netscape and opera preferred over the *user's* preferred browser on Windows? * Why is the GNOME default browser preferred even if the user is currently running KDE (but has GNOME installed)? >From all the platforms, only on Mac OS X it really respects the user's preferrencies. I'd like to propose this: * On Windows, make "windows-default" the first in _try_order * If the user is running GNOME ("GNOME_DESKTOP_SESSION_ID" in os.environ) and command "gnome-open" exists, use `gnome-open '%s'`. * If the user is running KDE (os.environ.get("KDE_FULL_SESSION") == "true") and command "kfmclient" exists, use `kfmclient exec '%s'`. ---------------------------------------------------------------------- >Comment By: Lukas Lalinsky (luks) Date: 2007-03-15 12:47 Message: Logged In: YES user_id=587716 Originator: YES Ok, here is the patch, including the fix for #1681248. The priorities on all platforms with this patch are: 1. The BROWSER environment variable overrides everything 2. Next step is to check the preferred browsers for desktop environments (Windows, Mac OS X, GNOME and KDE) 3. Fallback to available installed browsers (firefox, opera, konqueror, epiphany, ...) File Added: webbrowser-defaults.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 09:50 Message: Logged In: YES user_id=849994 Originator: NO I agree with your suggestion. Can you make a patch (and include a fix for the other bug you filed)? ---------------------------------------------------------------------- Comment By: Lukas Lalinsky (luks) Date: 2007-03-15 09:06 Message: Logged In: YES user_id=587716 Originator: YES Just a note, if you agree with this behavior, I'll be more than happy to make a patch. Currently I'm using similar mechanism in my own code (because Python's lib in 2.4 doesn't respect GNOME/KDE settings at all), so I can easily turn it into a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681228&group_id=5470 From noreply at sourceforge.net Thu Mar 15 12:53:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 04:53:40 -0700 Subject: [ python-Bugs-931877 ] Segfault in object_reduce_ex Message-ID: Bugs item #931877, was opened at 2004-04-08 19:46 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=931877&group_id=5470 Please note that this 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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Tim Peters (tim_one) Assigned to: Tim Peters (tim_one) Summary: Segfault in object_reduce_ex Initial Comment: Shane Hathaway bumped into this, unbounded recursion in typeobject.c's object_reduce_ex(). This occurs in Python 2.3.3 and current CVS. Assigned to Guido, to ponder whether object_reduce_ex is doing what it should; if it is (which seems likely to me), I suppose we need to inject a recursion counter to prevent the segfault. The failing case is short, but I'll attach it (temp99.py) to avoid SF line mangling. While the test uses pickle, same symptom if it's changed to use cPickle instead. Jim Fulton's analysis: """ This is a very clever infinite loop. The proxy doesn't actually proxy, but it does manage to confuse reduce about what's going on. reduce tries to figure out if it has been overridden by asking whether the class's reduce is the same as object.__reduce__. It doesn't expect to be lied to about the class. Things wouldn't have been so bad if the proxy had proxied __reduce__ as well as __class__. """ The priority hasn't been bumped, because "the real code" from which this was whittled down wasn't doing what it needed to do anyway, and the recursion went away when the real code was repaired. ---------------------------------------------------------------------- >Comment By: ?iga Seilnacht (zseil) Date: 2007-03-15 12:53 Message: Logged In: YES user_id=1326842 Originator: NO Fixed with said patch in rev. 54397, 54398 (2.5). ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-04-01 03:43 Message: Logged In: YES user_id=1326842 See patch #1462488. If that patch is accepted, this bug should be closed as fixed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-15 06:05 Message: Logged In: YES user_id=6380 Unassigning. I need to concentrate on Python 3000. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 22:58 Message: Logged In: YES user_id=1188172 Still crashing with 2.5... ---------------------------------------------------------------------- Comment By: Nathan Srebro (nati) Date: 2004-11-30 02:26 Message: Logged In: YES user_id=63133 This infinite recursion also occurs in another place, that got me stumped for a couple of days when old code that worked with Python 2.2 stopped working. If __class__ is not fidgeted with (as in original bug report), but a descriptor returns a custom reduce for the class, but not for its objects, reduce enters an infinite loop on the object: """ class descriptor_for_reduce(object): def __get__(self,obj,tp=None): if obj is not None: return super(ASpecialClass,obj).__reduce__ return self.reducer def reducer(self,proto=None): return "VerySpecial" class ASpecialClass(object): __reduce__ = descriptor_for_reduce() copy.copy(ASpecialClass()) """ ASpecialClass().__reduce__ is object.__reduce__, which is implemented by typeobject.c:object_reduce_ex. This function (that doesn't know if its called as the __reduce__ or the __reduce_ex__ method) tries to detect if the object's __reduce__ is overridden. It does so by checking if the object's class's __reduce__ is overridden, and in fact it is. It then assumes that the object's __reduce__ is overridden, and calls it. But the object's __reduce__ is the same function, causing the infinite loop. If __reduce_ex__ is used instead of __reduce__, the problem goes away, ASpecialClass().__reduce_ex__() return the usual tuple, and ASpecialClass.__reduce_ex__() return "VerySpecial". But when __reduce__ is overridden, ASpecialClass().__reduce__() enters an infinite loop. I believe this is a legitimate example that should behave just as when __reduce_ex__ is overridden. The example doesn't lie about __class__, and it is certainly legitimate for define a property that behaves differently for the class and for its objects. Where did this come up and why would I ever care about a class's __reduce__? The __reduce__ attribute of a class is never used by (the standard) pickle or copy, since save_global() is called instead. However, I have a custom pickler, implemented as a subclass of pickle.Pickler, which falls back on the class's __reduce__ when save_global() fails. This way, I can pickle certain classes that are created at run-time (and can be easily recreated, e.g. from their bases and dictionaries). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-04-08 19:51 Message: Logged In: YES user_id=31435 Hmm! The temp99.py download link doesn't work for me. Here's the content in case it doesn't work for others either: """ import cPickle as pickle from pickle import dumps class SimpleItem: def __reduce__(self): return (self.__class__, None, {}) class Proxy(object): __class__ = property(lambda self: self.__target.__class__) def __init__(self, target): self.__target = target def __getstate__(self): raise RuntimeError("No don't pickle me! Aaarrgghh!") p = Proxy(SimpleItem()) dumps(p) """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=931877&group_id=5470 From noreply at sourceforge.net Thu Mar 15 20:28:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 12:28:05 -0700 Subject: [ python-Bugs-1681671 ] Python and Indeterminate Forms (Math) Message-ID: Bugs item #1681671, was opened at 2007-03-15 15: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=1681671&group_id=5470 Please note that this 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 Private: No Submitted By: jehahn (jehahn) Assigned to: Nobody/Anonymous (nobody) Summary: Python and Indeterminate Forms (Math) Initial Comment: Primary example: Python 2.3.5 (#1, Mar 20 2005, 20:38:20) [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> 0 ** 0 1 Per http://mathworld.wolfram.com/Indeterminate.html, 0 ** 0 is an indeterminate form. 0 ** 0 should probably return NaN and NOT 1. Other examples include: Python 2.3.5 (#1, Mar 20 2005, 20:38:20) [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> inf = float("infinity") >>> inf ** 0 1.0 >>> 1 ** inf 1.0 For a few others, Python provides an arguably correct answer of NaN. Examples: Python 2.3.5 (#1, Mar 20 2005, 20:38:20) [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> inf = float("infinity") >>> inf * 0 nan >>> inf / inf nan >>> inf - inf nan And, of course, for the most obvious indeterminate form (0/0) Python does precisely the right thing: Python 2.3.5 (#1, Mar 20 2005, 20:38:20) [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> 0/0 Traceback (most recent call last): File "", line 1, in ? ZeroDivisionError: integer division or modulo by zero It could be argued that the correct thing to do here is to throw an exception - mathematically speaking these forms are about as meaningful as division by zero which Python handles by throwing an exception. (unlike Java and IEEE 754, which do arguably evil things here by returning +/- infinity for the quantity k/0 for all k != 0) Unfortunately, some people doing numerical work may have gotten used to the current Python behavior so the change isn't without risk. And some of the current values are common "conventions" used to simplify certain common issues. (e.g. 0 ** 0 == 1) Moreover, I don't know if this is dependent on platform (having only tried it on a couple of the boxes I have handy.) However, from a mathematical purist's standpoint, Python is doing the wrong thing on these counts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681671&group_id=5470 From noreply at sourceforge.net Thu Mar 15 20:32:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 12:32:40 -0700 Subject: [ python-Bugs-1681674 ] subprocess.Popen fails with socket._fileobject on Windows Message-ID: Bugs item #1681674, was opened at 2007-03-15 20: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=1681674&group_id=5470 Please note that this 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 Private: No Submitted By: Hartmut Goebel (htgoebel) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.Popen fails with socket._fileobject on Windows Initial Comment: When using a socket._fileobject as stdin or stdout, subprocess.Popen fails: Traceback (most recent call last): ... File "c:\Python25\lib\subprocess.py", line 586, in __init__ errread, errwrite) = self._get_handles(stdin, stdout, stderr) File "c:\Python25\lib\subprocess.py", line 680, in _get_handles p2cread = msvcrt.get_osfhandle(stdin.fileno()) IOError: [Errno 9] Bad file descriptor Enclose are a _simple_ TCPSocket-Server using subprocess.Popen for echoing some text to the socket. On Linux this works, on Windows this fails with the above traceback. Usage: 1) In one shell start tst_subprocess_socket.py 2) In a second shell start tst_subprocess_socket_client.py 3) On Window, the server will fail and produce the obove traceback. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681674&group_id=5470 From noreply at sourceforge.net Thu Mar 15 20:33:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 12:33:08 -0700 Subject: [ python-Bugs-1681674 ] subprocess.Popen fails with socket._fileobject on Windows Message-ID: Bugs item #1681674, was opened at 2007-03-15 20:32 Message generated for change (Comment added) made by htgoebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681674&group_id=5470 Please note that this 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 Private: No Submitted By: Hartmut Goebel (htgoebel) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.Popen fails with socket._fileobject on Windows Initial Comment: When using a socket._fileobject as stdin or stdout, subprocess.Popen fails: Traceback (most recent call last): ... File "c:\Python25\lib\subprocess.py", line 586, in __init__ errread, errwrite) = self._get_handles(stdin, stdout, stderr) File "c:\Python25\lib\subprocess.py", line 680, in _get_handles p2cread = msvcrt.get_osfhandle(stdin.fileno()) IOError: [Errno 9] Bad file descriptor Enclose are a _simple_ TCPSocket-Server using subprocess.Popen for echoing some text to the socket. On Linux this works, on Windows this fails with the above traceback. Usage: 1) In one shell start tst_subprocess_socket.py 2) In a second shell start tst_subprocess_socket_client.py 3) On Window, the server will fail and produce the obove traceback. ---------------------------------------------------------------------- >Comment By: Hartmut Goebel (htgoebel) Date: 2007-03-15 20:33 Message: Logged In: YES user_id=376953 Originator: YES File Added: tst_subprocess_socket_client.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681674&group_id=5470 From noreply at sourceforge.net Thu Mar 15 21:19:24 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 13:19:24 -0700 Subject: [ python-Bugs-1660009 ] continuing problem with httplib multiple set-cookie headers Message-ID: Bugs item #1660009, was opened at 2007-02-14 19:52 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1660009&group_id=5470 Please note that this 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 Private: No Submitted By: David Margrave (davidma) Assigned to: Nobody/Anonymous (nobody) Summary: continuing problem with httplib multiple set-cookie headers Initial Comment: This is related to [ 432621 ] httplib: multiple Set-Cookie headers, which I was unable to re-open. The workaround that was adopted in the previous bug tracker item was to combine multiple set-cookie headers received from the server, into a single set-cookie element in the headers dictionary, with the cookies joined into a comma-separated string. The problem arises when a comma character appears inside the 'expires' field of one of the cookies. This makes it difficult to split the cookie headers back apart. The comma character should be escaped, or a different separator character used. i.e. expires=Sun, 17-Jan-2038 19:14:07 GMT For now I am using the workaround that gstein suggested, use response.msg.getallmatchingheaders() Python 2.3 has this behavior, and probably later versions. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-03-15 20:19 Message: Logged In: YES user_id=261020 Originator: NO OK, thanks! That certainly does look wrong. The Set-Cookie case should be special-cased in that method, I think. ---------------------------------------------------------------------- Comment By: David Margrave (davidma) Date: 2007-03-15 00:58 Message: Logged In: YES user_id=31040 Originator: YES See the addheader method of the HTTPMessage class in httplib.py def addheader(self, key, value): """Add header for field key handling repeats.""" prev = self.dict.get(key) if prev is None: self.dict[key] = value else: combined = ", ".join((prev, value)) self.dict[key] = combined also see the original tracker entry where this fix was first discussed & implemented https://sourceforge.net/tracker/index.php?func=detail&aid=432621&group_id=5470&atid=105470 ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-03-15 00:45 Message: Logged In: YES user_id=261020 Originator: NO Huh? 1. *What* behaviour is correct? You still have not said which bit of code you're talking about, or even which module. 2. You seem to have got the sense of what I said backwards. As I said, RFC 2616 is (in practice) WRONG about joining with commas being OK for Set-Cookie. Set-Cookies headers must NOT be joined with commas, despite what RFC 2616 says. ---------------------------------------------------------------------- Comment By: David Margrave (davidma) Date: 2007-03-15 00:30 Message: Logged In: YES user_id=31040 Originator: YES fair enough, the RFC says thay have to be joinable with commas, so the behavior is correct. I can get by with getallmatchingheaders if I need access to the original individual cookie values. thanks, dave ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-03-14 23:57 Message: Logged In: YES user_id=261020 Originator: NO SimpleHTTPRequestHandler is not part of httplib. Did you mean to refer to module SimpleHTTPServer rather than httplib, perhaps? I don't see the particular bit of code you refer to (neither in httplib nor in module SimpleHTTPServer), but re the general issue: Regardless of the fact that RFC 2616 ss. 4.2 says headers MUST be able to be combined with commas, Netscape Set-Cookie headers simply don't work that way, and Netscape Set-Cookie headers are here to stay. So, Set-Cookie headers must not be combined. (Quoting does not help, because Netscape Set-Cookie headers contain cookie values that 1. may contain commas and 2. do not support quoting -- any quote (") characters are in fact part of the cookie value itself rather than being part of a quoting mechanism. And there is no precedent for any choice of delimter other than a comma, nor for any other Netscape Set-Cookie cookie value quoting mechanism.) ---------------------------------------------------------------------- Comment By: David Margrave (davidma) Date: 2007-03-14 21:10 Message: Logged In: YES user_id=31040 Originator: YES getallmatchingheaders() works fine. The problem is with the self.headers in the SimpleHTTPRequestHandler and derived classes. A website may send multiple set-cookie headers, using gmail.com as an example: Set-Cookie: GMAIL_RTT=EXPIRED; Domain=.google.com; Expires=Tue, 13-Mar-07 21:03:04 GMT; Path=/mail Set-Cookie: GMAIL_LOGIN=EXPIRED; Domain=.google.com; Expires=Tue, 13-Mar-07 21:03:04 GMT; Path=/mail The SimpleHTTPRequestHandler class combines multiple set-cookie response headers into a single comma-separated string which it stores in the headers dictionary i.e. self.headers ['set-cookie'] = GMAIL_RTT=EXPIRED; Domain=.google.com; Expires=Tue, 13-Mar-07 21:03:04 GMT; Path=/mail, GMAIL_LOGIN=EXPIRED; Domain=.google.com; Expires=Tue, 13-Mar-07 21:03:04 GMT; Path=/mail The problem is if you try to use code that uses self.headers['set-cookie'] and use string.split to get the original distinct cookie values on the comma delimiter, you'll run into trouble because of the use of the comma character within the cookies' expiration tags, such as Expires=Tue, 13-Mar-07 21:03:04 GMT Again, getallmatchingheaders() is fine as an alternative, but as long as you are going to the trouble of storing multiple set-cookie response headers in the self.headers dict, using a delimiter of some sort, I'd argue you might as well also take care that your delimiter is either unique or escaped within the fields you are delimiting. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-03-14 20:48 Message: Logged In: YES user_id=261020 Originator: NO I'm not sure what your complaint is. What's wrong with response.msg.getallmatchingheaders()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1660009&group_id=5470 From noreply at sourceforge.net Thu Mar 15 21:46:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 13:46:39 -0700 Subject: [ python-Bugs-1660009 ] continuing problem with httplib multiple set-cookie headers Message-ID: Bugs item #1660009, was opened at 2007-02-14 19:52 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1660009&group_id=5470 Please note that this 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 Private: No Submitted By: David Margrave (davidma) Assigned to: Nobody/Anonymous (nobody) Summary: continuing problem with httplib multiple set-cookie headers Initial Comment: This is related to [ 432621 ] httplib: multiple Set-Cookie headers, which I was unable to re-open. The workaround that was adopted in the previous bug tracker item was to combine multiple set-cookie headers received from the server, into a single set-cookie element in the headers dictionary, with the cookies joined into a comma-separated string. The problem arises when a comma character appears inside the 'expires' field of one of the cookies. This makes it difficult to split the cookie headers back apart. The comma character should be escaped, or a different separator character used. i.e. expires=Sun, 17-Jan-2038 19:14:07 GMT For now I am using the workaround that gstein suggested, use response.msg.getallmatchingheaders() Python 2.3 has this behavior, and probably later versions. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-03-15 20:46 Message: Logged In: YES user_id=261020 Originator: NO Hold on, httplib.HTTPMessage.addheader() is undocumented, hence private. httplib.HTTPMessage.readheaders() itself calls that method, but also keeps the raw multiple-header data in the .headers list, so .getallmatchingheaders() still works. So the only bug I see is that the documentation for APIs that return should point out the fact that Set-Cookie is an oddity, and that .getallmatchingheaders() should be used in that case. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-03-15 20:19 Message: Logged In: YES user_id=261020 Originator: NO OK, thanks! That certainly does look wrong. The Set-Cookie case should be special-cased in that method, I think. ---------------------------------------------------------------------- Comment By: David Margrave (davidma) Date: 2007-03-15 00:58 Message: Logged In: YES user_id=31040 Originator: YES See the addheader method of the HTTPMessage class in httplib.py def addheader(self, key, value): """Add header for field key handling repeats.""" prev = self.dict.get(key) if prev is None: self.dict[key] = value else: combined = ", ".join((prev, value)) self.dict[key] = combined also see the original tracker entry where this fix was first discussed & implemented https://sourceforge.net/tracker/index.php?func=detail&aid=432621&group_id=5470&atid=105470 ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-03-15 00:45 Message: Logged In: YES user_id=261020 Originator: NO Huh? 1. *What* behaviour is correct? You still have not said which bit of code you're talking about, or even which module. 2. You seem to have got the sense of what I said backwards. As I said, RFC 2616 is (in practice) WRONG about joining with commas being OK for Set-Cookie. Set-Cookies headers must NOT be joined with commas, despite what RFC 2616 says. ---------------------------------------------------------------------- Comment By: David Margrave (davidma) Date: 2007-03-15 00:30 Message: Logged In: YES user_id=31040 Originator: YES fair enough, the RFC says thay have to be joinable with commas, so the behavior is correct. I can get by with getallmatchingheaders if I need access to the original individual cookie values. thanks, dave ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-03-14 23:57 Message: Logged In: YES user_id=261020 Originator: NO SimpleHTTPRequestHandler is not part of httplib. Did you mean to refer to module SimpleHTTPServer rather than httplib, perhaps? I don't see the particular bit of code you refer to (neither in httplib nor in module SimpleHTTPServer), but re the general issue: Regardless of the fact that RFC 2616 ss. 4.2 says headers MUST be able to be combined with commas, Netscape Set-Cookie headers simply don't work that way, and Netscape Set-Cookie headers are here to stay. So, Set-Cookie headers must not be combined. (Quoting does not help, because Netscape Set-Cookie headers contain cookie values that 1. may contain commas and 2. do not support quoting -- any quote (") characters are in fact part of the cookie value itself rather than being part of a quoting mechanism. And there is no precedent for any choice of delimter other than a comma, nor for any other Netscape Set-Cookie cookie value quoting mechanism.) ---------------------------------------------------------------------- Comment By: David Margrave (davidma) Date: 2007-03-14 21:10 Message: Logged In: YES user_id=31040 Originator: YES getallmatchingheaders() works fine. The problem is with the self.headers in the SimpleHTTPRequestHandler and derived classes. A website may send multiple set-cookie headers, using gmail.com as an example: Set-Cookie: GMAIL_RTT=EXPIRED; Domain=.google.com; Expires=Tue, 13-Mar-07 21:03:04 GMT; Path=/mail Set-Cookie: GMAIL_LOGIN=EXPIRED; Domain=.google.com; Expires=Tue, 13-Mar-07 21:03:04 GMT; Path=/mail The SimpleHTTPRequestHandler class combines multiple set-cookie response headers into a single comma-separated string which it stores in the headers dictionary i.e. self.headers ['set-cookie'] = GMAIL_RTT=EXPIRED; Domain=.google.com; Expires=Tue, 13-Mar-07 21:03:04 GMT; Path=/mail, GMAIL_LOGIN=EXPIRED; Domain=.google.com; Expires=Tue, 13-Mar-07 21:03:04 GMT; Path=/mail The problem is if you try to use code that uses self.headers['set-cookie'] and use string.split to get the original distinct cookie values on the comma delimiter, you'll run into trouble because of the use of the comma character within the cookies' expiration tags, such as Expires=Tue, 13-Mar-07 21:03:04 GMT Again, getallmatchingheaders() is fine as an alternative, but as long as you are going to the trouble of storing multiple set-cookie response headers in the self.headers dict, using a delimiter of some sort, I'd argue you might as well also take care that your delimiter is either unique or escaped within the fields you are delimiting. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-03-14 20:48 Message: Logged In: YES user_id=261020 Originator: NO I'm not sure what your complaint is. What's wrong with response.msg.getallmatchingheaders()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1660009&group_id=5470 From noreply at sourceforge.net Thu Mar 15 21:49:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 13:49:07 -0700 Subject: [ python-Bugs-1660009 ] continuing problem with httplib multiple set-cookie headers Message-ID: Bugs item #1660009, was opened at 2007-02-14 19:52 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1660009&group_id=5470 Please note that this 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 Private: No Submitted By: David Margrave (davidma) Assigned to: Nobody/Anonymous (nobody) Summary: continuing problem with httplib multiple set-cookie headers Initial Comment: This is related to [ 432621 ] httplib: multiple Set-Cookie headers, which I was unable to re-open. The workaround that was adopted in the previous bug tracker item was to combine multiple set-cookie headers received from the server, into a single set-cookie element in the headers dictionary, with the cookies joined into a comma-separated string. The problem arises when a comma character appears inside the 'expires' field of one of the cookies. This makes it difficult to split the cookie headers back apart. The comma character should be escaped, or a different separator character used. i.e. expires=Sun, 17-Jan-2038 19:14:07 GMT For now I am using the workaround that gstein suggested, use response.msg.getallmatchingheaders() Python 2.3 has this behavior, and probably later versions. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-03-15 20:49 Message: Logged In: YES user_id=261020 Originator: NO Sorry, my last paragraph got garbled a bit, here it is again: So the only bug I see is that the documentation for APIs that always return single headers (as opposed to lists of headers) should point out the fact that Set-Cookie is an oddity, and that .getallmatchingheaders() should be used in that case. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-03-15 20:46 Message: Logged In: YES user_id=261020 Originator: NO Hold on, httplib.HTTPMessage.addheader() is undocumented, hence private. httplib.HTTPMessage.readheaders() itself calls that method, but also keeps the raw multiple-header data in the .headers list, so .getallmatchingheaders() still works. So the only bug I see is that the documentation for APIs that return should point out the fact that Set-Cookie is an oddity, and that .getallmatchingheaders() should be used in that case. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-03-15 20:19 Message: Logged In: YES user_id=261020 Originator: NO OK, thanks! That certainly does look wrong. The Set-Cookie case should be special-cased in that method, I think. ---------------------------------------------------------------------- Comment By: David Margrave (davidma) Date: 2007-03-15 00:58 Message: Logged In: YES user_id=31040 Originator: YES See the addheader method of the HTTPMessage class in httplib.py def addheader(self, key, value): """Add header for field key handling repeats.""" prev = self.dict.get(key) if prev is None: self.dict[key] = value else: combined = ", ".join((prev, value)) self.dict[key] = combined also see the original tracker entry where this fix was first discussed & implemented https://sourceforge.net/tracker/index.php?func=detail&aid=432621&group_id=5470&atid=105470 ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-03-15 00:45 Message: Logged In: YES user_id=261020 Originator: NO Huh? 1. *What* behaviour is correct? You still have not said which bit of code you're talking about, or even which module. 2. You seem to have got the sense of what I said backwards. As I said, RFC 2616 is (in practice) WRONG about joining with commas being OK for Set-Cookie. Set-Cookies headers must NOT be joined with commas, despite what RFC 2616 says. ---------------------------------------------------------------------- Comment By: David Margrave (davidma) Date: 2007-03-15 00:30 Message: Logged In: YES user_id=31040 Originator: YES fair enough, the RFC says thay have to be joinable with commas, so the behavior is correct. I can get by with getallmatchingheaders if I need access to the original individual cookie values. thanks, dave ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-03-14 23:57 Message: Logged In: YES user_id=261020 Originator: NO SimpleHTTPRequestHandler is not part of httplib. Did you mean to refer to module SimpleHTTPServer rather than httplib, perhaps? I don't see the particular bit of code you refer to (neither in httplib nor in module SimpleHTTPServer), but re the general issue: Regardless of the fact that RFC 2616 ss. 4.2 says headers MUST be able to be combined with commas, Netscape Set-Cookie headers simply don't work that way, and Netscape Set-Cookie headers are here to stay. So, Set-Cookie headers must not be combined. (Quoting does not help, because Netscape Set-Cookie headers contain cookie values that 1. may contain commas and 2. do not support quoting -- any quote (") characters are in fact part of the cookie value itself rather than being part of a quoting mechanism. And there is no precedent for any choice of delimter other than a comma, nor for any other Netscape Set-Cookie cookie value quoting mechanism.) ---------------------------------------------------------------------- Comment By: David Margrave (davidma) Date: 2007-03-14 21:10 Message: Logged In: YES user_id=31040 Originator: YES getallmatchingheaders() works fine. The problem is with the self.headers in the SimpleHTTPRequestHandler and derived classes. A website may send multiple set-cookie headers, using gmail.com as an example: Set-Cookie: GMAIL_RTT=EXPIRED; Domain=.google.com; Expires=Tue, 13-Mar-07 21:03:04 GMT; Path=/mail Set-Cookie: GMAIL_LOGIN=EXPIRED; Domain=.google.com; Expires=Tue, 13-Mar-07 21:03:04 GMT; Path=/mail The SimpleHTTPRequestHandler class combines multiple set-cookie response headers into a single comma-separated string which it stores in the headers dictionary i.e. self.headers ['set-cookie'] = GMAIL_RTT=EXPIRED; Domain=.google.com; Expires=Tue, 13-Mar-07 21:03:04 GMT; Path=/mail, GMAIL_LOGIN=EXPIRED; Domain=.google.com; Expires=Tue, 13-Mar-07 21:03:04 GMT; Path=/mail The problem is if you try to use code that uses self.headers['set-cookie'] and use string.split to get the original distinct cookie values on the comma delimiter, you'll run into trouble because of the use of the comma character within the cookies' expiration tags, such as Expires=Tue, 13-Mar-07 21:03:04 GMT Again, getallmatchingheaders() is fine as an alternative, but as long as you are going to the trouble of storing multiple set-cookie response headers in the self.headers dict, using a delimiter of some sort, I'd argue you might as well also take care that your delimiter is either unique or escaped within the fields you are delimiting. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-03-14 20:48 Message: Logged In: YES user_id=261020 Originator: NO I'm not sure what your complaint is. What's wrong with response.msg.getallmatchingheaders()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1660009&group_id=5470 From noreply at sourceforge.net Fri Mar 16 00:12:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 16:12:40 -0700 Subject: [ python-Bugs-1681762 ] too long string causes segmentation fault Message-ID: Bugs item #1681762, was opened at 2007-03-16 00:12 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=1681762&group_id=5470 Please note that this 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 Private: No Submitted By: L (llukas11) Assigned to: Nobody/Anonymous (nobody) Summary: too long string causes segmentation fault Initial Comment: consider running this on machine with 16GB of ram: line = "x" for i in range(40): line = line + line print len(line) and it's output: 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 65536 131072 262144 524288 1048576 2097152 4194304 8388608 16777216 33554432 67108864 134217728 268435456 536870912 1073741824 -2147483648 Segmentation fault [lligo at kwaw-b1 0.1.x]$ python Python 2.4.4 (#1, Oct 23 2006, 13:58:18) [GCC 4.1.1 20061011 (Red Hat 4.1.1-30)] on linux2 I'll can try to chceck if it fails with python 2.5 but I need to compile one. I have stumlbed on this bug when reading line by line 3GB file and forgetting to clear string after I processed data. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681762&group_id=5470 From noreply at sourceforge.net Fri Mar 16 06:27:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 22:27:07 -0700 Subject: [ python-Feature Requests-443775 ] Update to the BEGIN_ALLOW_THREADS macros Message-ID: Feature Requests item #443775, was opened at 2001-07-23 05:34 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=443775&group_id=5470 Please note that this 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: 1 Private: No Submitted By: Martin Sj?gren (msjogren) Assigned to: Nobody/Anonymous (nobody) Summary: Update to the BEGIN_ALLOW_THREADS macros Initial Comment: The Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS currently do not support supplying WHERE to save the thread state via an argument. I needed that for a project myself so I wrote the following: #ifdef WITH_THREAD # define MY_BEGIN_ALLOW_THREADS(st) \ { st = PyEval_SaveThread(); } # define MY_END_ALLOW_THREADS(st) \ { PyEval_RestoreThread(st); st = NULL; } #else # define MY_BEGIN_ALLOW_THREADS(st) # define MY_END_ALLOW_THREADS(st) { st = NULL; } #endif This has, of course, the drawback that whenever the Py_BEGIN_ALLOW_THREADS macro changes I have to change mine! Therefore, I propose that these macros (under different names certainly) or macros that work something like this (I can't have asymmetric { and } in them, since I needed to retrieve the thread state somewhere else) in the standard Python distribution. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 22:27 Message: Logged In: YES user_id=33168 Originator: NO As Brett says, you can use the _save variable. Since no one else has requested this feature it doesn't seem worth it to change. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 17:08 Message: Logged In: YES user_id=357491 Couldn't you cheat and access the _save variable that Py_BEGIN_ALLOW_THREADS creates? And does PEP 311 help solve your usage need at all? ---------------------------------------------------------------------- Comment By: Michael Dubner (dubnerm) Date: 2003-01-17 21:16 Message: Logged In: YES user_id=39274 I think that current Py_BEGIN/END_ALLOW_THREADS macroses model (with block) is choosen to enforce compile-time pairwise check. Isn't it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=443775&group_id=5470 From noreply at sourceforge.net Fri Mar 16 06:39:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 22:39:09 -0700 Subject: [ python-Feature Requests-464605 ] moving the Mac/ src dir to a diff packag Message-ID: Feature Requests item #464605, was opened at 2001-09-24 14:57 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=464605&group_id=5470 Please note that this 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 Private: No Submitted By: Frederic Giacometti (giacometti) Assigned to: Nobody/Anonymous (nobody) Summary: moving the Mac/ src dir to a diff packag Initial Comment: Given the size of the Mac/ source directory, in the 2.1.1 source distribution (314 python files, 13 MB uncompressed of platform-specific material; a large amount of Mac-specific modules in the module documentation, would it be possible to move this outside the Python core source distribution ? This is taking dispk space and consuming CVS cpu time for nothing, for all but a few developpers. Thanks, Frederic Giacometti ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 22:39 Message: Logged In: YES user_id=33168 Originator: NO The file count is down to 268 not including files under .svn/. Although the size has increased to 17MB. Given the size of disks, etc and the effort involved with changing this, it's not likely to happen. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2001-10-16 01:09 Message: Logged In: YES user_id=21627 This won't happen. The Mac hierarchy was deliberately introduced into the Python CVS recently to simplify maintenance of the PythonMac port, and it won't be removed just for size reasons. OTOH, removing specific code because it is not used anymore may be feasible - it just needs somebody to identify these pieces. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-24 15:21 Message: Logged In: YES user_id=93657 Actually, it even a lot worse: there are over 1300 files in the Mac directory. Just think of the time CVS spends on them :(( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=464605&group_id=5470 From noreply at sourceforge.net Fri Mar 16 06:48:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 22:48:07 -0700 Subject: [ python-Feature Requests-585915 ] assert return values Message-ID: Feature Requests item #585915, was opened at 2002-07-24 06:28 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=585915&group_id=5470 Please note that this 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 Private: No Submitted By: Thomas Leonard (tal197) Assigned to: Nobody/Anonymous (nobody) Summary: assert return values Initial Comment: It would be nice to write: def root(x): assert x >= 0 assert return >= 0 ... or def get_path(foo): if foo is None: return None assert return is not None ... and have the 'return' assertion checked when the function exits. 'return' is already a reserved keyword so the syntax doesn't introduce any incompatibility. This might make functions more self-documenting, since asserts at the end / in the middle tend to get lost. Even if the assert goes at the end, it's still clearer, eg: def foo(): ... assert min <= return <= max return bar(min, max) vs def foo(): ... tmp = bar(min, max) assert min <= tmp <= max return tmp Thanks! ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 22:48 Message: Logged In: YES user_id=33168 Originator: NO Raymond pretty much summed up my opinion. :-) This could only happen with a PEP and still doesn't seem likely. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 23:41 Message: Logged In: YES user_id=80475 Yuck! ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 19:32 Message: Logged In: YES user_id=357491 Wouldn't this require turning 'return' into an expression instead of a statement? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-07-24 08:42 Message: Logged In: YES user_id=31435 Re-opened but moved to the Feature Request tracker (it's certainly not "a bug", but there's no rule against asking for new features either, provided they're in the right place). I don't believe there's any control flow in the suggestion, just that the name "return" be taken as being bound, in assert statements, to the possibly anonyous return expression. Eiffel does something very much like this for the benefit of expressing post-conditions. I certainly agree this way of spelling it in Python has problems, though, and a PEP would be in order. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-07-24 08:06 Message: Logged In: YES user_id=31392 I don't think this is a great feature. It seems like control flow via yield or return could easily be overlooked if it's inside an assert statement. Regardless of whether I like the idea, the SF bug tracker isn't the right place to make this suggestion. The right thing to do is write a PEP describing the feature in detail, then come up with a patch to implement it. If that's too much work, but you really like the idea, you could try to drum up interest on comp.lang.python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=585915&group_id=5470 From noreply at sourceforge.net Fri Mar 16 06:51:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 22:51:04 -0700 Subject: [ python-Feature Requests-706970 ] Including python-codecs codecs in standard distribution? Message-ID: Feature Requests item #706970, was opened at 2003-03-20 08:07 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=706970&group_id=5470 Please note that this 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: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Bjorn Stabell (bjoerns) Assigned to: Nobody/Anonymous (nobody) Summary: Including python-codecs codecs in standard distribution? Initial Comment: Are there any plans to include the python-codecs in the standard distribution? They are Chinese and Japanese encodings, very useful if you live in China or Japan, which quite a few people do :) -- Imagine having to download ASCII encoding separately. What's stopping the inclusion, if anything? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 22:51 Message: Logged In: YES user_id=33168 Originator: NO CJK codecs was introduced in Python 2.4 IIRC. I assume that satisfies this request. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-29 09:32 Message: Logged In: YES user_id=12800 We should continue to discuss this. There are good technical and political reasons for re-evaluating whether to include Asian codecs in a batteries included Python distribution. I suggest python-dev and/or i18n-sig @python.org. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-03-29 07:05 Message: Logged In: YES user_id=21627 The size of the code, and its correctness is stopping inclusion of these codecs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=706970&group_id=5470 From noreply at sourceforge.net Fri Mar 16 06:58:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 22:58:49 -0700 Subject: [ python-Feature Requests-878458 ] optparse help text is not easily extensible Message-ID: Feature Requests item #878458, was opened at 2004-01-16 10:59 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=878458&group_id=5470 Please note that this 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 Private: No Submitted By: Ian Bicking (ianbicking) Assigned to: Nobody/Anonymous (nobody) Summary: optparse help text is not easily extensible Initial Comment: optparse doesn't allow for paragraph/narrative help text. This text would typically go below the option listing. There is currently no place to describe positional arguments, and this would be a simple way to allow for that. This could be provided as an extra keyword argument to OptionParser.__init__, included in the help in the function OptionParser.format_help. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 22:58 Message: Logged In: YES user_id=33168 Originator: NO Since optik is maintained separately from the core, this request should go there. http://sourceforge.net/projects/optik ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=878458&group_id=5470 From noreply at sourceforge.net Fri Mar 16 07:02:35 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 23:02:35 -0700 Subject: [ python-Feature Requests-925537 ] dir(mod) OK or use vars(mod).keys()? Message-ID: Feature Requests item #925537, was opened at 2004-03-29 11:28 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=925537&group_id=5470 Please note that this 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: 4 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: dir(mod) OK or use vars(mod).keys()? Initial Comment: The documentation on dir() notes that its behavior may change across releases. Several library modules use dir(x) in ways that might break if it changed too much. Should these be changed to use vars(obj).keys() (and possibly sort()), or should the note on dir() be removed? My own preference would just be to provide some guidance, such as "The output of dir() will always include all public variables which do not have a magic meaning." I realize that the standard library itself could be updated if dir() changes in an uncomfortable way. My real concern is which spelling to use in my own code. The library examples suggest a simpler (and clearer) dir(), but the documentation still says otherwise. A quick search for modules using dir() showed possible trouble in at least cgitb, cmd, FCNTL, inspect, optparse, os, pickle, rlcompleter, SimpleXMLRPCServer, TERMIOS, tokenize, unittest, and urllib2. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 23:02 Message: Logged In: YES user_id=33168 Originator: NO Has anything happened? Is this still relevant? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-20 23:05 Message: Logged In: YES user_id=80475 One possible change is in the works. Someone, suggested that dir() starting including the __name__ attribute. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-03-30 16:51 Message: Logged In: YES user_id=31435 Ya, dir() was *intended* to be a convenience for use at the interactive shell. I expect the only promise Guido wants to make about it is that it will show him stuff he finds interesting as Python changes <0.7 wink>. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-03-30 13:09 Message: Logged In: YES user_id=21627 Ok, marking it as a feature request then: Explicitly pointing out that behaviour may change in the future has usually been done because change in behaviour is anticipated, or has happened in the past. Giving stronger guarantees about future versions a feature that is currently not provided. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-03-30 07:28 Message: Logged In: YES user_id=764593 The ideal fix would be in documentation (and therefore policy). I want to do something like import_list = [x for x in dir(other_mod) if wanted(x)] It happens to work today on my machine, but the documentation says that dir(x) may return different results in different releases. This means that I can't safely use it in released code. If there were some indication that dir(module) would continue to return the same names as vars(module).keys(), then I could use it. If the differences were only in variables not intended for export, that would also be OK -- but dir does not current promise this. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-03-29 14:11 Message: Logged In: YES user_id=21627 I fail to see a bug. Which specific usage of dir() does not work as intended? ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-03-29 11:58 Message: Logged In: YES user_id=764593 Correction: "The output of dir (module) will always include ..." The most common use is figuring out what to do with (import from) a module. Symmetry suggests the same for a no-argument call or a class or type object, but object instances do not use their __dict__ for their attributes; the results are already different there. -jJ ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-03-29 11:39 Message: Logged In: YES user_id=764593 If there concern is over attributes that are "public" but don't exist until called, then most uses of dir and vars are already broken. An alternative reasonable promise would be The output of dir(obj) will always include all (public?, non-magical?) names in vars(obj).keys(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=925537&group_id=5470 From noreply at sourceforge.net Fri Mar 16 07:04:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 23:04:46 -0700 Subject: [ python-Feature Requests-950644 ] Allow any lvalue for function definitions Message-ID: Feature Requests item #950644, was opened at 2004-05-08 18:52 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=950644&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Albert Torpey (dtorp) Assigned to: Nobody/Anonymous (nobody) Summary: Allow any lvalue for function definitions Initial Comment: A definition like: def M(x): return 2*x is the same as: M = lambda x: 2*x With the latter form, I can use any lvalue: A[0] = lambda x: 2*x B.f = lambda x: 2*x But with the first form, you're locked into just using a plain variable name. If this were fixed, it wouldn't break anything else but would be useful for making method definitons outside of a class definition: This came up when I was experimenting with David MacQuigg's ideas for prototype OO. I want to write something like: Account = Object.clone() Account.balance = 0 def Account.deposit(self, v): self.balance += v Unfortunately, the latter has to be written: def Account.deposit(self, v): self.balance += v Account.deposit = deposit ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 23:04 Message: Logged In: YES user_id=33168 Originator: NO Pinging to check interest. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-06-28 10:43 Message: Logged In: YES user_id=6380 This is the kind of thing that needs a lot of thought going into it to decide whether it is a net improvement to the language. Right now my gut feeling is that it's not worth the complexity, and more likely to be used towards unnecessary obfuscation. The redability gain is minimal if not negative IMO. Also, I've sometimes typed "def self.foo(args):" instead of "def foo(self, args):" suggesting that there's more than one intuitive way of interpreting the proposed syntax. Another minus point. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-24 10:08 Message: Logged In: YES user_id=80475 Guido, are you open to this? If so, I would be happy to draft a patch. I wouldn't expect it to become mainstream, but it would open the door to working with namespaces more directly. AFAICT, there is no downside to allowing this capability. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-20 22:57 Message: Logged In: YES user_id=80475 I think this should be made possible. It allows for alternate coding styles wihout harming anything else. The Lua programming language has something similar. It is a lightweight, non-OO language that revolves around making the best possible use of namespaces. Direct assignments into a namespace come up in several contexts throughout the language and are key to Lua's flexibility (using one concept to meet all needs). My only concern is that "def" and "class" statements also have the side effect of binding the __name__ attribute. We would have to come up with a lambda style placeholder for the attribute. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-05-19 17:56 Message: Logged In: YES user_id=99874 I'm highly dubious of this. I see little advantage to doing the definition and storing the value in a single line, mostly because I rarely want to do such a thing. Your example may be convincing in Prothon or some relative, but in Python the sensible way to do it is a normal method. I'd suggest that if you want this idea to go anywhere that you try posting this to c.l.py and seeing if you can drum up interest and support there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=950644&group_id=5470 From noreply at sourceforge.net Fri Mar 16 07:08:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 23:08:36 -0700 Subject: [ python-Feature Requests-967161 ] pty.spawn() enhancements Message-ID: Feature Requests item #967161, was opened at 2004-06-05 09:29 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=967161&group_id=5470 Please note that this 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 Private: No Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: pty.spawn() enhancements Initial Comment: (Originally suggested by James Henstridge in bug #897935) There are also a few changes that would be nice to see in pty.spawn: 1) get the exit status of the child. Could be fixed by adding the following to the end of the function: pid, status = os.waitpid(pid, 0) return status 2) set master_fd to non-blocking mode, so that the output is printed to the screen at the speed it is produced by the child. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 23:08 Message: Logged In: YES user_id=33168 Originator: NO Wouldn't it be better to just return the pid. The caller can get the status if they want or do anything else with the pid. I'm guessing #2 is no longer requested? ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2004-06-09 07:16 Message: Logged In: YES user_id=146903 Since filing the original bug report, I got reports that simply setting the fds to non-blocking caused problems under Solaris. Some details are available in this bug report: http://bugzilla.gnome.org/show_bug.cgi?id=139168 The _copy() function never raised an IOError or OSError, so it never exited. I'd imagine that EOF could be detected by getting back then empty string when reading from the fd when select() says it is ready for reading, but I haven't checked whether this works. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=967161&group_id=5470 From noreply at sourceforge.net Fri Mar 16 07:11:27 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 23:11:27 -0700 Subject: [ python-Feature Requests-1073198 ] Extension to optparse: options with optional arguments Message-ID: Feature Requests item #1073198, was opened at 2004-11-25 06:18 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1073198&group_id=5470 Please note that this 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: Invalid Priority: 5 Private: No Submitted By: pollastri (pollastri) Assigned to: Greg Ward (gward) Summary: Extension to optparse: options with optional arguments Initial Comment: When parsing command line options, I found very useful to have an option with a facultative value, able to do the following: 1-tell to me if the option was or was not seen on the command line, return the value None if the option was not seen; 2-if the option only was specified, return a default value. 3-if the option with a value was specified on the command line, return the specified value; A way to reach this goal can be the addition of a new value for the options actions in module optparse, it may be something like "store_with_default". ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 23:11 Message: Logged In: YES user_id=33168 Originator: NO Greg, since optik is maintained separately, it seems to make sense to close this and possibly create a new report in optik. http://sourceforge.net/projects/optik . Let me know if that's not how you want to handle bugs/feature requests. ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2005-01-05 05:19 Message: Logged In: YES user_id=14422 I don't know what "facultative" means, but what you want is optional option arguments. Don't worry, I want that feature too, and have even started implementing it on a branch of the Optik source repository. See http://sourceforge.net/tracker/?func=detail&aid=1050431&group_id=38019&atid=421100 for a similar feature request. I'm leaving this open, since I haven't finished anything or merged it into the Python CVS. It could be a few months before there's any action here, and it certainly won't happen before Optik 1.6 / Python 2.5. Might require Optik 2.0, in which case I'm not certain when it'll get into Python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1073198&group_id=5470 From noreply at sourceforge.net Fri Mar 16 07:16:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 23:16:37 -0700 Subject: [ python-Feature Requests-1085861 ] subprocess.Popen feature request Message-ID: Feature Requests item #1085861, was opened at 2004-12-15 07:33 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1085861&group_id=5470 Please note that this 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 Private: No Submitted By: Michele Simionato (michele_s) Assigned to: Peter ?strand (astrand) Summary: subprocess.Popen feature request Initial Comment: I asked on comp.lang.python for a "kill" method in the Popen class. The answer was "the kill method is missing since it is not portable to Windows". However I got this message from Fredrik Lund """ I suggest filing a "bug" report about this. the Unix version is trivial, as you noticed, and it shouldn't take many minutes to add a TerminateProcess helper to _subprocess. """ So, I am following his suggestion ;-) Michele Simionato ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 23:16 Message: Logged In: YES user_id=33168 Originator: NO TerminateProcess is now in _subprocess.c. Can you work up a patch? It's not likely to get done otherwise. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-06-26 15:37 Message: Logged In: YES user_id=1188172 Moving to RFE tracker. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1085861&group_id=5470 From noreply at sourceforge.net Fri Mar 16 07:17:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 23:17:18 -0700 Subject: [ python-Feature Requests-1087741 ] subclassable mmap Message-ID: Feature Requests item #1087741, was opened at 2004-12-18 16:16 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1087741&group_id=5470 Please note that this 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 Private: No Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: subclassable mmap Initial Comment: As the subject says, it would be nice if mmaps were subclassable...like nearly every other Python object type. Note that pseudo-subclasses (copying the instance methods to a different class (not necessarily of the same type) instance) don't work completely due to python.org/sf/1087735 , and is probably a Python "anti-pattern". ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 23:17 Message: Logged In: YES user_id=33168 Originator: NO Josiah, care to work up a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1087741&group_id=5470 From noreply at sourceforge.net Fri Mar 16 07:27:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 23:27:01 -0700 Subject: [ python-Feature Requests-1087741 ] subclassable mmap Message-ID: Feature Requests item #1087741, was opened at 2004-12-18 16:16 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1087741&group_id=5470 Please note that this 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 Private: No Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: subclassable mmap Initial Comment: As the subject says, it would be nice if mmaps were subclassable...like nearly every other Python object type. Note that pseudo-subclasses (copying the instance methods to a different class (not necessarily of the same type) instance) don't work completely due to python.org/sf/1087735 , and is probably a Python "anti-pattern". ---------------------------------------------------------------------- >Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-15 23:27 Message: Logged In: YES user_id=341410 Originator: YES I honestly wouldn't know where to start. I don't know what the differences are between the currently un-subclassable mmap, and something like int/list/dict. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 23:17 Message: Logged In: YES user_id=33168 Originator: NO Josiah, care to work up a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1087741&group_id=5470 From noreply at sourceforge.net Fri Mar 16 07:27:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 23:27:11 -0700 Subject: [ python-Feature Requests-1222235 ] Bad optparse help wrapping with multiple paragraphs Message-ID: Feature Requests item #1222235, was opened at 2005-06-16 15:18 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1222235&group_id=5470 Please note that this 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: Invalid Priority: 5 Private: No Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Greg Ward (gward) Summary: Bad optparse help wrapping with multiple paragraphs Initial Comment: If the help text for an option consists of multiple paragraphs, optparse wraps all the paragraphs into one big mess when --help is used. optparse should really split the text by paragraphs and fill each individual paragraph. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 23:27 Message: Logged In: YES user_id=33168 Originator: NO Closing, assuming this is tracked in http://sourceforge.net/projects/optik ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2005-07-21 19:08 Message: Logged In: YES user_id=14422 This sounds an awful lot like Optik RFE #1055954 -- see https://sourceforge.net/tracker/?func=detail&atid=421100&aid=1055954&group_id=38019 . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1222235&group_id=5470 From noreply at sourceforge.net Fri Mar 16 07:39:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 23:39:57 -0700 Subject: [ python-Feature Requests-1379573 ] python executable optionally should search script on PATH Message-ID: Feature Requests item #1379573, was opened at 2005-12-13 07:13 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&group_id=5470 Please note that this 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 Private: No Submitted By: Christoph Conrad (cconrad) Assigned to: Nobody/Anonymous (nobody) Summary: python executable optionally should search script on PATH Initial Comment: I've seen that with perl - parameter -S means search script on path. Very helpful. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 23:39 Message: Logged In: YES user_id=33168 Originator: NO What's the status of this? Is it a bug report? ---------------------------------------------------------------------- Comment By: Christoph Conrad (cconrad) Date: 2006-02-20 03:10 Message: Logged In: YES user_id=21338 (1) (HKCU|HKLM)\Software\Classes\Python.File\open\command really is (HKCU|HKLM)\Software\Classes\Python.File\shell\open\command (2) with python 24 a new behaviour occurs: i try to execute the script on the commandline, but a dialog boy appears with: the file "[...correct complete path to the script...]" could not be found. Again, if i prepend python.exe, everything works as expected. windows 2000 professional. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-20 01:14 Message: Logged In: YES user_id=1188172 Do you mean that the registry setting is ok, but the parameters are not passed correctly? ---------------------------------------------------------------------- Comment By: Christoph Conrad (cconrad) Date: 2006-02-20 00:12 Message: Logged In: YES user_id=21338 I checked the registry. It's ok. It's windows 2000. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-01-16 13:29 Message: Logged In: YES user_id=21627 That (arguments not passed to the script) was a bug in some versions of the Windows installer. Please verify that the registry, at (HKCU|HKLM)\Software\Classes\Python.File\open\command has the value '[path]python.exe "%1" %*'. The %* part should arrange for arguments being passed. ---------------------------------------------------------------------- Comment By: Christoph Conrad (cconrad) Date: 2006-01-16 02:59 Message: Logged In: YES user_id=21338 > On windows, you should be able to just invoke the_script.py > (i.e. without a preceding python.exe). Does this not work > for you? It works - but command line args are not given to the called script. If i prepend python.exe, command line args are transferred correctly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-01-14 10:34 Message: Logged In: YES user_id=21627 On windows, you should be able to just invoke the_script.py (i.e. without a preceding python.exe). Does this not work for you? ---------------------------------------------------------------------- Comment By: Christoph Conrad (cconrad) Date: 2005-12-15 14:00 Message: Logged In: YES user_id=21338 i meant the windows operating system. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-12-15 13:40 Message: Logged In: YES user_id=1188172 I don't know... if the script is in the PATH, isn't it normally executable too? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&group_id=5470 From noreply at sourceforge.net Fri Mar 16 07:44:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 23:44:39 -0700 Subject: [ python-Feature Requests-1527705 ] optparse should support arbitrary number of arguments Message-ID: Feature Requests item #1527705, was opened at 2006-07-24 05:03 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1527705&group_id=5470 Please note that this 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: Invalid Priority: 5 Private: No Submitted By: Ritesh Raj Sarraf (riteshsarraf) Assigned to: Greg Ward (gward) Summary: optparse should support arbitrary number of arguments Initial Comment: Currently, the number of arguments an option can/should have, needs be defined. This is done using "nagrs". parser.add_option("", "--my-option", nargs=3) The problem is that at times it isn't predictable how many arguments you'll be receiving. I request the implementation of this feature in optparse, where the following could be possible. parser.add_option("", "--my-option", nargs=*) Thanks, Ritesh ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 23:44 Message: Logged In: YES user_id=33168 Originator: NO Optik is maintained separately. Please file a feature request there: http://sourceforge.net/projects/optik ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-24 06:31 Message: Logged In: YES user_id=849994 I share effbot's view on that, but leaving to Greg to decide. In any case, this is a feature request. ---------------------------------------------------------------------- Comment By: Ritesh Raj Sarraf (riteshsarraf) Date: 2006-07-24 06:21 Message: Logged In: YES user_id=382018 Can you please go through the following link and give your comments ? http://groups.google.com/group/comp.lang.python/browse_thre ad/thread/277522927334b8d8 I feel its a valid feature request. Ritesh ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-24 05:57 Message: Logged In: YES user_id=849994 I don't know of any program that uses command line switches with a variable number of args, partly because you then cannot distinguish between option arguments and normal arguments. I you still need this, you can implement a custom callback, I think. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1527705&group_id=5470 From noreply at sourceforge.net Fri Mar 16 07:50:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 23:50:05 -0700 Subject: [ python-Feature Requests-1578269 ] Add os.link() and os.symlink() support for Windows Message-ID: Feature Requests item #1578269, was opened at 2006-10-16 08:21 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1578269&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: M.-A. Lemburg (lemburg) Assigned to: Nobody/Anonymous (nobody) Summary: Add os.link() and os.symlink() support for Windows Initial Comment: NTFS version 5.0 and up has all the needed APIs for creating hard links and symlinks (junctions), so it should be possible to add support for both hard links and symlinks to the posixmodule. Here are a few references: http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html (see list of links at the end of the page) http://www.codeproject.com/w2k/junctionpoints.asp (junction points only, but includes analysis and source code) Note: NTFS 5.0 is supported in Win 2k, XP, 2003 and later. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 23:50 Message: Logged In: YES user_id=33168 Originator: NO Note a similar feature request which also contains a possible patch: 478407 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-17 08:47 Message: Logged In: YES user_id=21627 We shouldn't expose junctions as symlinks. Instead, Vista will get real symlinks, so we should use that: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/createsymboliclink.asp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1578269&group_id=5470 From noreply at sourceforge.net Fri Mar 16 07:54:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 23:54:02 -0700 Subject: [ python-Feature Requests-1627266 ] optparse "store" action should not gobble up next option Message-ID: Feature Requests item #1627266, was opened at 2007-01-03 10:46 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1627266&group_id=5470 Please note that this 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: Invalid Priority: 5 Private: No Submitted By: Raghuram Devarakonda (draghuram) Assigned to: Greg Ward (gward) Summary: optparse "store" action should not gobble up next option Initial Comment: Hi, Check the following code: --------------opttest.py---------- from optparse import OptionParser def process_options(): global options, args, parser parser = OptionParser() parser.add_option("--test", action="store_true") parser.add_option("-m", metavar="COMMENT", dest="comment", default=None) (options, args) = parser.parse_args() return process_options() print "comment (%r)" % options.comment --------------------- $ ./opttest.py -m --test comment ('--test') I was expecting this to give an error as "--test" is an option. But it looks like even C library's getopt() behaves similarly. It will be nice if optparse can report error in this case. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 23:54 Message: Logged In: YES user_id=33168 Originator: NO Closing since optik is maintained separately. Please file a feature request at http://sourceforge.net/projects/optik ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2007-01-11 10:19 Message: Logged In: YES user_id=945502 Originator: NO At the moment, you generally can't: http://argparse.python-hosting.com/ticket/25 though the simple value "-" is valid. I do plan to address this in the not-so-distant future (though no one yet has complained about it). For optparse module, I think the OP's problem could likely be fixed by editing _process_long_opt() and _process_short_opts() to do some checks around the code: elif nargs == 1: value = rargs.pop(0) else: value = tuple(rargs[0:nargs]) del rargs[0:nargs] You could make sure that the option arguments (the "value" objects in the code above) were not already existing options with a check like: all(not self._match_long_opt(arg) and not self._short_opt.get(arg) for arg in rargs[0:nargs]) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-01-11 08:16 Message: Logged In: YES user_id=849994 Originator: NO So how does one give option arguments starting with - to argparse? ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2007-01-11 07:41 Message: Logged In: YES user_id=945502 Originator: NO For what it's worth, argparse_ gives an error here: >>> parser = argparse.ArgumentParser(prog='PROG') >>> parser.add_argument('--test', action='store_true') >>> parser.add_argument('-m', dest='comment') >>> parser.parse_args(['-m', '--test']) usage: PROG [-h] [--test] [-m COMMENT] PROG: error: argument -m: expected one argument That's because argparse assumes that anything that looks like "--foo" is an option (unless it's after the pseudo-argument "--" on the command line). .. _argparse: http://argparse.python-hosting.com/ ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-05 09:58 Message: Logged In: YES user_id=984087 Originator: YES It is possible to deduce "--test" as an option because it is in the list of options given to optparse. But your point about what if the user really wants "--test" as an option argument is valid. I guess this request can be closed. Thanks, Raghu. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2007-01-05 08:28 Message: Logged In: YES user_id=7733 Originator: NO I think what you're asking for is ambiguous at best. In your example, how could optparse possibly decide that the "--test" is a second option, not an option argument? What if you *do* want "--test" as an argument? Assigning to Greg Ward. Recommend closing as invalid. ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-05 07:19 Message: Logged In: YES user_id=984087 Originator: YES I am attaching the code fragment as a file since the indentation got all messed up in the original post. File Added: opttest.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1627266&group_id=5470 From noreply at sourceforge.net Fri Mar 16 07:59:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 23:59:14 -0700 Subject: [ python-Bugs-1665333 ] Documentation missing for OptionGroup class in optparse Message-ID: Bugs item #1665333, was opened at 2007-02-21 07:40 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1665333&group_id=5470 Please note that this 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 Private: No Submitted By: LunarYorn (lunar_yorn) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation missing for OptionGroup class in optparse Initial Comment: Python seems to lack documentation for the OptionGroup class and related methods in the optparse modul. In detail documentation of the following classes and methods in optparse is missing: - OptionGroup - OptionParser.add_option_group - OptionParser.get_option_group These classes and methods also lack docstrings. I found this in Python 2.4.4c1 which comes with Ubuntu 6.10 Edgy. It seems, that Python 2.5 on Ubuntu Edgy also suffers from this bug. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 23:59 Message: Logged In: YES user_id=33168 Originator: NO LunarYorn, thanks for the report. bediviere, thanks to for filing a report with optik. Since the issue is tracked there, I'm closing this report. ---------------------------------------------------------------------- Comment By: LunarYorn (lunar_yorn) Date: 2007-02-26 09:45 Message: Logged In: YES user_id=1485244 Originator: YES Thanks for filing the patch there! I didn't know, that optparse is developt outside of Python... Anyway I think you're right not to comment the whole api. I did not intend that. I would be content with a little note in the docs quickly explains OptionGroups and how to create them. More shouldn't be told, since they are only useful for formatting help output. I just needed such a thing for my recent project and was short of overwriting the OptionParser and HelpFormatter classes. For that purpose I looked into the sources, where I found the OptionGroup capabilities. A little note would have shortened the development of the option parsing code quite a bit... ;) ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2007-02-26 09:39 Message: Logged In: YES user_id=945502 Originator: NO Looks like the optparse docs are also auto-generated from optik. Here's the first line of liboptparse.tex: % THIS FILE IS AUTO-GENERATED! DO NOT EDIT! So I guess this needs to be handled in the optparse bugs. ---------------------------------------------------------------------- Comment By: Steven Bethard (bediviere) Date: 2007-02-26 09:37 Message: Logged In: YES user_id=945502 Originator: NO The docstrings need to be modified in the Optik package (from which the stdlib optparse module is derived). I've filed you an appropriate patch there: http://sourceforge.net/tracker/index.php?func=detail&aid=1669315&group_id=38019&atid=421097. I'll see what I can do about adding some documentation. My preference is only to document OptionParser.add_option_group -- I think making the OptionGroup API public is a mistake (like making the STORE_ACTIONS, etc. APIs public was). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1665333&group_id=5470 From noreply at sourceforge.net Fri Mar 16 08:37:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 00:37:58 -0700 Subject: [ python-Feature Requests-1527705 ] optparse should support arbitrary number of arguments Message-ID: Feature Requests item #1527705, was opened at 2006-07-24 17:33 Message generated for change (Comment added) made by riteshsarraf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1527705&group_id=5470 Please note that this 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: Invalid Priority: 5 Private: No Submitted By: Ritesh Raj Sarraf (riteshsarraf) Assigned to: Greg Ward (gward) Summary: optparse should support arbitrary number of arguments Initial Comment: Currently, the number of arguments an option can/should have, needs be defined. This is done using "nagrs". parser.add_option("", "--my-option", nargs=3) The problem is that at times it isn't predictable how many arguments you'll be receiving. I request the implementation of this feature in optparse, where the following could be possible. parser.add_option("", "--my-option", nargs=*) Thanks, Ritesh ---------------------------------------------------------------------- >Comment By: Ritesh Raj Sarraf (riteshsarraf) Date: 2007-03-16 13:07 Message: Logged In: YES user_id=382018 Originator: YES I don't think this is the correct way of resolving a bug. You mark it as "Close" with a resolution "Invalid" when the bug was filed against "Python Library", of which optparse is one. Python ships optparse as part of its libraries. If internally, it is a separate project, you could file one there and link to it. But why just plain close it ? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-16 12:14 Message: Logged In: YES user_id=33168 Originator: NO Optik is maintained separately. Please file a feature request there: http://sourceforge.net/projects/optik ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-24 19:01 Message: Logged In: YES user_id=849994 I share effbot's view on that, but leaving to Greg to decide. In any case, this is a feature request. ---------------------------------------------------------------------- Comment By: Ritesh Raj Sarraf (riteshsarraf) Date: 2006-07-24 18:51 Message: Logged In: YES user_id=382018 Can you please go through the following link and give your comments ? http://groups.google.com/group/comp.lang.python/browse_thre ad/thread/277522927334b8d8 I feel its a valid feature request. Ritesh ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-24 18:27 Message: Logged In: YES user_id=849994 I don't know of any program that uses command line switches with a variable number of args, partly because you then cannot distinguish between option arguments and normal arguments. I you still need this, you can implement a custom callback, I think. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1527705&group_id=5470 From noreply at sourceforge.net Fri Mar 16 08:47:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 00:47:41 -0700 Subject: [ python-Feature Requests-1527705 ] optparse should support arbitrary number of arguments Message-ID: Feature Requests item #1527705, was opened at 2006-07-24 05:03 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1527705&group_id=5470 Please note that this 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: Invalid Priority: 5 Private: No Submitted By: Ritesh Raj Sarraf (riteshsarraf) Assigned to: Greg Ward (gward) Summary: optparse should support arbitrary number of arguments Initial Comment: Currently, the number of arguments an option can/should have, needs be defined. This is done using "nagrs". parser.add_option("", "--my-option", nargs=3) The problem is that at times it isn't predictable how many arguments you'll be receiving. I request the implementation of this feature in optparse, where the following could be possible. parser.add_option("", "--my-option", nargs=*) Thanks, Ritesh ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-16 00:47 Message: Logged In: YES user_id=33168 Originator: NO I encourage you to file a feature request with optik if it's important to you. While it may not be the nicest way, it's the only way we can get anything done. I pointed you to optik so you can file the feature request if it's important to you. What has happened in the past is that this report would be left open forever. That is worse. If you think this is wrong, you can fix the problem by helping us resolve all the issues in python. Otherwise, there's no hope of us managing it. ---------------------------------------------------------------------- Comment By: Ritesh Raj Sarraf (riteshsarraf) Date: 2007-03-16 00:37 Message: Logged In: YES user_id=382018 Originator: YES I don't think this is the correct way of resolving a bug. You mark it as "Close" with a resolution "Invalid" when the bug was filed against "Python Library", of which optparse is one. Python ships optparse as part of its libraries. If internally, it is a separate project, you could file one there and link to it. But why just plain close it ? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 23:44 Message: Logged In: YES user_id=33168 Originator: NO Optik is maintained separately. Please file a feature request there: http://sourceforge.net/projects/optik ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-24 06:31 Message: Logged In: YES user_id=849994 I share effbot's view on that, but leaving to Greg to decide. In any case, this is a feature request. ---------------------------------------------------------------------- Comment By: Ritesh Raj Sarraf (riteshsarraf) Date: 2006-07-24 06:21 Message: Logged In: YES user_id=382018 Can you please go through the following link and give your comments ? http://groups.google.com/group/comp.lang.python/browse_thre ad/thread/277522927334b8d8 I feel its a valid feature request. Ritesh ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-24 05:57 Message: Logged In: YES user_id=849994 I don't know of any program that uses command line switches with a variable number of args, partly because you then cannot distinguish between option arguments and normal arguments. I you still need this, you can implement a custom callback, I think. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1527705&group_id=5470 From noreply at sourceforge.net Fri Mar 16 08:55:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 00:55:25 -0700 Subject: [ python-Bugs-1681228 ] webbrowser priorities Message-ID: Bugs item #1681228, was opened at 2007-03-15 08:03 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681228&group_id=5470 Please note that this 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.5 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Lukas Lalinsky (luks) Assigned to: Nobody/Anonymous (nobody) Summary: webbrowser priorities Initial Comment: Recently I've run into a Windows-specific bug in webbrowser (using close_fds and preexec_fn in subprocess.Popen), and I noticed there are some strange priorities in the default browsers. For example: * Why is firefox, firebird, seamonkey, mozilla, netscape and opera preferred over the *user's* preferred browser on Windows? * Why is the GNOME default browser preferred even if the user is currently running KDE (but has GNOME installed)? >From all the platforms, only on Mac OS X it really respects the user's preferrencies. I'd like to propose this: * On Windows, make "windows-default" the first in _try_order * If the user is running GNOME ("GNOME_DESKTOP_SESSION_ID" in os.environ) and command "gnome-open" exists, use `gnome-open '%s'`. * If the user is running KDE (os.environ.get("KDE_FULL_SESSION") == "true") and command "kfmclient" exists, use `kfmclient exec '%s'`. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 07:55 Message: Logged In: YES user_id=849994 Originator: NO Committed in rev. 54406. ---------------------------------------------------------------------- Comment By: Lukas Lalinsky (luks) Date: 2007-03-15 11:47 Message: Logged In: YES user_id=587716 Originator: YES Ok, here is the patch, including the fix for #1681248. The priorities on all platforms with this patch are: 1. The BROWSER environment variable overrides everything 2. Next step is to check the preferred browsers for desktop environments (Windows, Mac OS X, GNOME and KDE) 3. Fallback to available installed browsers (firefox, opera, konqueror, epiphany, ...) File Added: webbrowser-defaults.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 08:50 Message: Logged In: YES user_id=849994 Originator: NO I agree with your suggestion. Can you make a patch (and include a fix for the other bug you filed)? ---------------------------------------------------------------------- Comment By: Lukas Lalinsky (luks) Date: 2007-03-15 08:06 Message: Logged In: YES user_id=587716 Originator: YES Just a note, if you agree with this behavior, I'll be more than happy to make a patch. Currently I'm using similar mechanism in my own code (because Python's lib in 2.4 doesn't respect GNOME/KDE settings at all), so I can easily turn it into a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681228&group_id=5470 From noreply at sourceforge.net Fri Mar 16 08:56:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 00:56:16 -0700 Subject: [ python-Bugs-1681248 ] WindowsError in webbrowser.open Message-ID: Bugs item #1681248, was opened at 2007-03-15 08:35 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681248&group_id=5470 Please note that this 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.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Lukas Lalinsky (luks) Assigned to: Nobody/Anonymous (nobody) Summary: WindowsError in webbrowser.open Initial Comment: On Windows, os.startfile can throw an exception if the URL action is not assigned to any program. I think the function should catch it and return False. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 07:56 Message: Logged In: YES user_id=849994 Originator: NO Fixed with your patch from #1681228. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681248&group_id=5470 From noreply at sourceforge.net Fri Mar 16 09:30:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 01:30:38 -0700 Subject: [ python-Bugs-1681762 ] too long string causes segmentation fault Message-ID: Bugs item #1681762, was opened at 2007-03-15 23:12 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681762&group_id=5470 Please note that this 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 Private: No Submitted By: L (llukas11) >Assigned to: Martin v. L?wis (loewis) Summary: too long string causes segmentation fault Initial Comment: consider running this on machine with 16GB of ram: line = "x" for i in range(40): line = line + line print len(line) and it's output: 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 65536 131072 262144 524288 1048576 2097152 4194304 8388608 16777216 33554432 67108864 134217728 268435456 536870912 1073741824 -2147483648 Segmentation fault [lligo at kwaw-b1 0.1.x]$ python Python 2.4.4 (#1, Oct 23 2006, 13:58:18) [GCC 4.1.1 20061011 (Red Hat 4.1.1-30)] on linux2 I'll can try to chceck if it fails with python 2.5 but I need to compile one. I have stumlbed on this bug when reading line by line 3GB file and forgetting to clear string after I processed data. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 08:30 Message: Logged In: YES user_id=849994 Originator: NO Martin, do you think the Py_ssize_t changes prevent this in Py2.5? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681762&group_id=5470 From noreply at sourceforge.net Fri Mar 16 09:31:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 01:31:25 -0700 Subject: [ python-Feature Requests-925537 ] dir(mod) OK or use vars(mod).keys()? Message-ID: Feature Requests item #925537, was opened at 2004-03-29 19:28 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=925537&group_id=5470 Please note that this 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: 4 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: dir(mod) OK or use vars(mod).keys()? Initial Comment: The documentation on dir() notes that its behavior may change across releases. Several library modules use dir(x) in ways that might break if it changed too much. Should these be changed to use vars(obj).keys() (and possibly sort()), or should the note on dir() be removed? My own preference would just be to provide some guidance, such as "The output of dir() will always include all public variables which do not have a magic meaning." I realize that the standard library itself could be updated if dir() changes in an uncomfortable way. My real concern is which spelling to use in my own code. The library examples suggest a simpler (and clearer) dir(), but the documentation still says otherwise. A quick search for modules using dir() showed possible trouble in at least cgitb, cmd, FCNTL, inspect, optparse, os, pickle, rlcompleter, SimpleXMLRPCServer, TERMIOS, tokenize, unittest, and urllib2. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 08:31 Message: Logged In: YES user_id=849994 Originator: NO Now that we have __dir__(), I think this is "rejected". ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-16 06:02 Message: Logged In: YES user_id=33168 Originator: NO Has anything happened? Is this still relevant? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-21 06:05 Message: Logged In: YES user_id=80475 One possible change is in the works. Someone, suggested that dir() starting including the __name__ attribute. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-03-31 00:51 Message: Logged In: YES user_id=31435 Ya, dir() was *intended* to be a convenience for use at the interactive shell. I expect the only promise Guido wants to make about it is that it will show him stuff he finds interesting as Python changes <0.7 wink>. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-03-30 21:09 Message: Logged In: YES user_id=21627 Ok, marking it as a feature request then: Explicitly pointing out that behaviour may change in the future has usually been done because change in behaviour is anticipated, or has happened in the past. Giving stronger guarantees about future versions a feature that is currently not provided. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-03-30 15:28 Message: Logged In: YES user_id=764593 The ideal fix would be in documentation (and therefore policy). I want to do something like import_list = [x for x in dir(other_mod) if wanted(x)] It happens to work today on my machine, but the documentation says that dir(x) may return different results in different releases. This means that I can't safely use it in released code. If there were some indication that dir(module) would continue to return the same names as vars(module).keys(), then I could use it. If the differences were only in variables not intended for export, that would also be OK -- but dir does not current promise this. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-03-29 22:11 Message: Logged In: YES user_id=21627 I fail to see a bug. Which specific usage of dir() does not work as intended? ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-03-29 19:58 Message: Logged In: YES user_id=764593 Correction: "The output of dir (module) will always include ..." The most common use is figuring out what to do with (import from) a module. Symmetry suggests the same for a no-argument call or a class or type object, but object instances do not use their __dict__ for their attributes; the results are already different there. -jJ ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-03-29 19:39 Message: Logged In: YES user_id=764593 If there concern is over attributes that are "public" but don't exist until called, then most uses of dir and vars are already broken. An alternative reasonable promise would be The output of dir(obj) will always include all (public?, non-magical?) names in vars(obj).keys(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=925537&group_id=5470 From noreply at sourceforge.net Fri Mar 16 09:34:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 01:34:00 -0700 Subject: [ python-Feature Requests-1670167 ] isinstance.__doc__ is somewhat irritating Message-ID: Feature Requests item #1670167, was opened at 2007-02-27 17:26 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1670167&group_id=5470 Please note that this 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 Private: No Submitted By: Ren? Fleschenberg (refl) Assigned to: Nobody/Anonymous (nobody) Summary: isinstance.__doc__ is somewhat irritating Initial Comment: "With a type as second argument, return whether that is the object's type." That sentence does not really make sense, at least not for new-style classes. After reading that, one could expect that isinstance(1, object) would return False. I think the best thing would be to just drop that sentence from the doc string. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 08:34 Message: Logged In: YES user_id=849994 Originator: NO Fixed in rev. 54409, 54410 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1670167&group_id=5470 From noreply at sourceforge.net Fri Mar 16 10:18:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 02:18:08 -0700 Subject: [ python-Feature Requests-1527705 ] optparse should support arbitrary number of arguments Message-ID: Feature Requests item #1527705, was opened at 2006-07-24 17:33 Message generated for change (Comment added) made by riteshsarraf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1527705&group_id=5470 Please note that this 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: Invalid Priority: 5 Private: No Submitted By: Ritesh Raj Sarraf (riteshsarraf) Assigned to: Greg Ward (gward) Summary: optparse should support arbitrary number of arguments Initial Comment: Currently, the number of arguments an option can/should have, needs be defined. This is done using "nagrs". parser.add_option("", "--my-option", nargs=3) The problem is that at times it isn't predictable how many arguments you'll be receiving. I request the implementation of this feature in optparse, where the following could be possible. parser.add_option("", "--my-option", nargs=*) Thanks, Ritesh ---------------------------------------------------------------------- >Comment By: Ritesh Raj Sarraf (riteshsarraf) Date: 2007-03-16 14:48 Message: Logged In: YES user_id=382018 Originator: YES Thanks for clarifying Neal. I've filed a bug with optik, #1681933 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-16 13:17 Message: Logged In: YES user_id=33168 Originator: NO I encourage you to file a feature request with optik if it's important to you. While it may not be the nicest way, it's the only way we can get anything done. I pointed you to optik so you can file the feature request if it's important to you. What has happened in the past is that this report would be left open forever. That is worse. If you think this is wrong, you can fix the problem by helping us resolve all the issues in python. Otherwise, there's no hope of us managing it. ---------------------------------------------------------------------- Comment By: Ritesh Raj Sarraf (riteshsarraf) Date: 2007-03-16 13:07 Message: Logged In: YES user_id=382018 Originator: YES I don't think this is the correct way of resolving a bug. You mark it as "Close" with a resolution "Invalid" when the bug was filed against "Python Library", of which optparse is one. Python ships optparse as part of its libraries. If internally, it is a separate project, you could file one there and link to it. But why just plain close it ? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-16 12:14 Message: Logged In: YES user_id=33168 Originator: NO Optik is maintained separately. Please file a feature request there: http://sourceforge.net/projects/optik ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-24 19:01 Message: Logged In: YES user_id=849994 I share effbot's view on that, but leaving to Greg to decide. In any case, this is a feature request. ---------------------------------------------------------------------- Comment By: Ritesh Raj Sarraf (riteshsarraf) Date: 2006-07-24 18:51 Message: Logged In: YES user_id=382018 Can you please go through the following link and give your comments ? http://groups.google.com/group/comp.lang.python/browse_thre ad/thread/277522927334b8d8 I feel its a valid feature request. Ritesh ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-24 18:27 Message: Logged In: YES user_id=849994 I don't know of any program that uses command line switches with a variable number of args, partly because you then cannot distinguish between option arguments and normal arguments. I you still need this, you can implement a custom callback, I think. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1527705&group_id=5470 From noreply at sourceforge.net Fri Mar 16 11:03:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 03:03:49 -0700 Subject: [ python-Bugs-1681974 ] mkdtemp fails on Windows if username has non-ASCII character Message-ID: Bugs item #1681974, was opened at 2007-03-16 12:03 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=1681974&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Markus Niemist? (niemisto) Assigned to: Nobody/Anonymous (nobody) Summary: mkdtemp fails on Windows if username has non-ASCII character Initial Comment: mkdtemp fails miserably on Windows if Windows user name has any non-ASCII characters, like ?? or ??, in it. mkdtemp throws an encoding error. This seems to be because the default temp dir in Windows is "c:\documents and settings\\local settings\temp". Now if the user name has non-ASCII characters ASCII decoder cannot handle it and creating temp directories won't work. As a work around I have used the following code: tempdir = unicode(tempfile.gettempdir(), 'mbcs') mkdtemp(suffix='foo', dir=tempdir) This applies for both Python 2.4 and Python 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681974&group_id=5470 From noreply at sourceforge.net Fri Mar 16 11:17:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 03:17:59 -0700 Subject: [ python-Bugs-1681984 ] unittest documentation is incomplete Message-ID: Bugs item #1681984, was opened at 2007-03-16 11:17 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=1681984&group_id=5470 Please note that this 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 Private: No Submitted By: STINNER Victor (haypo) Assigned to: Nobody/Anonymous (nobody) Summary: unittest documentation is incomplete Initial Comment: When I tried to write a test suite using many test cases, I read the documentation (docs.python.org) but it does work because I was unable to run my test suite. Using Google I realised that documentation is incomplete! In Python binding of gstreamer, I found a "TextTestRunner"! So, would it be possible to update the doc? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681984&group_id=5470 From noreply at sourceforge.net Fri Mar 16 12:17:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 04:17:08 -0700 Subject: [ python-Bugs-1681762 ] too long string causes segmentation fault Message-ID: Bugs item #1681762, was opened at 2007-03-16 00:12 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681762&group_id=5470 Please note that this 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 Private: No Submitted By: L (llukas11) Assigned to: Martin v. L?wis (loewis) Summary: too long string causes segmentation fault Initial Comment: consider running this on machine with 16GB of ram: line = "x" for i in range(40): line = line + line print len(line) and it's output: 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 65536 131072 262144 524288 1048576 2097152 4194304 8388608 16777216 33554432 67108864 134217728 268435456 536870912 1073741824 -2147483648 Segmentation fault [lligo at kwaw-b1 0.1.x]$ python Python 2.4.4 (#1, Oct 23 2006, 13:58:18) [GCC 4.1.1 20061011 (Red Hat 4.1.1-30)] on linux2 I'll can try to chceck if it fails with python 2.5 but I need to compile one. I have stumlbed on this bug when reading line by line 3GB file and forgetting to clear string after I processed data. ---------------------------------------------------------------------- >Comment By: ?iga Seilnacht (zseil) Date: 2007-03-16 12:17 Message: Logged In: YES user_id=1326842 Originator: NO This looks like a duplicate of bug #1526585: http://www.python.org/sf/1526585 That bug was fixed in Python 2.5, but it didn't get backported to the 2.4 branch (string_concatenate() in ceval.c is still missing an overflow check). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 09:30 Message: Logged In: YES user_id=849994 Originator: NO Martin, do you think the Py_ssize_t changes prevent this in Py2.5? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681762&group_id=5470 From noreply at sourceforge.net Fri Mar 16 13:31:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 05:31:49 -0700 Subject: [ python-Bugs-1681674 ] subprocess.Popen fails with socket._fileobject on Windows Message-ID: Bugs item #1681674, was opened at 2007-03-15 20:32 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681674&group_id=5470 Please note that this 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 Private: No Submitted By: Hartmut Goebel (htgoebel) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.Popen fails with socket._fileobject on Windows Initial Comment: When using a socket._fileobject as stdin or stdout, subprocess.Popen fails: Traceback (most recent call last): ... File "c:\Python25\lib\subprocess.py", line 586, in __init__ errread, errwrite) = self._get_handles(stdin, stdout, stderr) File "c:\Python25\lib\subprocess.py", line 680, in _get_handles p2cread = msvcrt.get_osfhandle(stdin.fileno()) IOError: [Errno 9] Bad file descriptor Enclose are a _simple_ TCPSocket-Server using subprocess.Popen for echoing some text to the socket. On Linux this works, on Windows this fails with the above traceback. Usage: 1) In one shell start tst_subprocess_socket.py 2) In a second shell start tst_subprocess_socket_client.py 3) On Window, the server will fail and produce the obove traceback. ---------------------------------------------------------------------- >Comment By: ?iga Seilnacht (zseil) Date: 2007-03-16 13:31 Message: Logged In: YES user_id=1326842 Originator: NO This is a known limitation of Windows; unlike UNIX like systems, it treats sockets and file descriptors as completely different entities. I don't think there is anything that Python can do to hide this difference. ---------------------------------------------------------------------- Comment By: Hartmut Goebel (htgoebel) Date: 2007-03-15 20:33 Message: Logged In: YES user_id=376953 Originator: YES File Added: tst_subprocess_socket_client.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681674&group_id=5470 From noreply at sourceforge.net Fri Mar 16 13:36:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 05:36:11 -0700 Subject: [ python-Feature Requests-950644 ] Allow any lvalue for function definitions Message-ID: Feature Requests item #950644, was opened at 2004-05-08 21:52 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=950644&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: David Albert Torpey (dtorp) Assigned to: Nobody/Anonymous (nobody) Summary: Allow any lvalue for function definitions Initial Comment: A definition like: def M(x): return 2*x is the same as: M = lambda x: 2*x With the latter form, I can use any lvalue: A[0] = lambda x: 2*x B.f = lambda x: 2*x But with the first form, you're locked into just using a plain variable name. If this were fixed, it wouldn't break anything else but would be useful for making method definitons outside of a class definition: This came up when I was experimenting with David MacQuigg's ideas for prototype OO. I want to write something like: Account = Object.clone() Account.balance = 0 def Account.deposit(self, v): self.balance += v Unfortunately, the latter has to be written: def Account.deposit(self, v): self.balance += v Account.deposit = deposit ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-16 08:36 Message: Logged In: YES user_id=6380 Originator: NO I don't think so. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-16 02:04 Message: Logged In: YES user_id=33168 Originator: NO Pinging to check interest. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-06-28 13:43 Message: Logged In: YES user_id=6380 This is the kind of thing that needs a lot of thought going into it to decide whether it is a net improvement to the language. Right now my gut feeling is that it's not worth the complexity, and more likely to be used towards unnecessary obfuscation. The redability gain is minimal if not negative IMO. Also, I've sometimes typed "def self.foo(args):" instead of "def foo(self, args):" suggesting that there's more than one intuitive way of interpreting the proposed syntax. Another minus point. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-24 13:08 Message: Logged In: YES user_id=80475 Guido, are you open to this? If so, I would be happy to draft a patch. I wouldn't expect it to become mainstream, but it would open the door to working with namespaces more directly. AFAICT, there is no downside to allowing this capability. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-21 01:57 Message: Logged In: YES user_id=80475 I think this should be made possible. It allows for alternate coding styles wihout harming anything else. The Lua programming language has something similar. It is a lightweight, non-OO language that revolves around making the best possible use of namespaces. Direct assignments into a namespace come up in several contexts throughout the language and are key to Lua's flexibility (using one concept to meet all needs). My only concern is that "def" and "class" statements also have the side effect of binding the __name__ attribute. We would have to come up with a lambda style placeholder for the attribute. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-05-19 20:56 Message: Logged In: YES user_id=99874 I'm highly dubious of this. I see little advantage to doing the definition and storing the value in a single line, mostly because I rarely want to do such a thing. Your example may be convincing in Prothon or some relative, but in Python the sensible way to do it is a normal method. I'd suggest that if you want this idea to go anywhere that you try posting this to c.l.py and seeing if you can drum up interest and support there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=950644&group_id=5470 From noreply at sourceforge.net Fri Mar 16 14:02:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 06:02:23 -0700 Subject: [ python-Bugs-1681984 ] unittest documentation is incomplete Message-ID: Bugs item #1681984, was opened at 2007-03-16 10:17 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681984&group_id=5470 Please note that this 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 Private: No Submitted By: STINNER Victor (haypo) Assigned to: Nobody/Anonymous (nobody) Summary: unittest documentation is incomplete Initial Comment: When I tried to write a test suite using many test cases, I read the documentation (docs.python.org) but it does work because I was unable to run my test suite. Using Google I realised that documentation is incomplete! In Python binding of gstreamer, I found a "TextTestRunner"! So, would it be possible to update the doc? ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 13:02 Message: Logged In: YES user_id=849994 Originator: NO Could you please state what exactly is missing from the documentation, in your opinion? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681984&group_id=5470 From noreply at sourceforge.net Fri Mar 16 15:06:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 07:06:40 -0700 Subject: [ python-Bugs-1666807 ] Incorrect file path reported by inspect.getabsfile() Message-ID: Bugs item #1666807, was opened at 2007-02-23 08:08 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666807&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Fernando P?rez (fer_perez) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect file path reported by inspect.getabsfile() Initial Comment: The following code demonstrates the problem succinctly: ### import inspect,sys print 'Version info:',sys.version_info print f1 = inspect.getabsfile(inspect) f2 = inspect.getabsfile(inspect.iscode) print 'File for `inspect` :',f1 print 'File for `inspect.iscode`:',f2 print 'Do these match?',f1==f2 if f1==f2: print 'OK' else: print 'BUG - this is a bug in this version of Python' ### EOF Running this on my system (Linux, Ubuntu Edgy) with 2.3, 2.4 and 2.5 produces: tlon[bin]> ./python2.3 ~/code/python/inspect_bug.py Version info: (2, 3, 6, 'final', 0) File for `inspect` : /home/fperez/tmp/local/lib/python2.3/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/lib/python2.3/inspect.py Do these match? True OK tlon[bin]> python2.4 ~/code/python/inspect_bug.py Version info: (2, 4, 4, 'candidate', 1) File for `inspect` : /usr/lib/python2.4/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/bin/inspect.py Do these match? False BUG - this is a bug in this version of Python tlon[bin]> python2.5 ~/code/python/inspect_bug.py Version info: (2, 5, 0, 'final', 0) File for `inspect` : /usr/lib/python2.5/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/bin/inspect.py Do these match? False BUG - this is a bug in this version of Python ### The problem arises in the fact that inspect relies, for functions (at least), on the func_code.co_filename attribute to contain a complete path. This changed between 2.3 and 2.4, but the inspect module was never updated. This code: ### import inspect,sys print 'Python version info:',sys.version_info print 'File info for `inspect.iscode function`:' print ' ',inspect.iscode.func_code.co_filename print ### EOF shows the problem: tlon[bin]> ./python2.3 ~/code/python/inspect_bug_details.py Python version info: (2, 3, 6, 'final', 0) File info for `inspect.iscode function`: /home/fperez/tmp/local//lib/python2.3/inspect.py tlon[bin]> python2.5 ~/code/python/inspect_bug_details.py Python version info: (2, 5, 0, 'final', 0) File info for `inspect.iscode function`: inspect.py ### (2.4 has the same issue). Basically, if the func_code.co_filename attribute now stores only the final filename without the full path, then the logic in the inspect module needs to be changed to accomodate this so that correct paths are reported to the user like they were in the 2.3 days. ---------------------------------------------------------------------- >Comment By: ??iga Seilnacht (zseil) Date: 2007-03-16 15:06 Message: Logged In: YES user_id=1326842 Originator: NO It looks like this is a bug in Ubuntu build process. The logging package had the same problem: http://www.python.org/sf/1669498 http://www.python.org/sf/1633605 http://www.python.org/sf/1616422 ---------------------------------------------------------------------- Comment By: Fernando P?rez (fer_perez) Date: 2007-03-09 03:00 Message: Logged In: YES user_id=395388 Originator: YES As I mentioned, on hand-built Pythons I don't get the bug at all. So it may be a problem with how Ubuntu builds its Python, since I can reproduce the problem with both 2.4 and 2.5, but only with the default ones provided by Ubuntu Edgy. I don't know enough about their packaging system to know how to retrieve build info. There may be something odd in their build, but it would be nice if this simply couldn't happen at all. If anyone knows how to retrieve the relevant info from an ubuntu build, I'll be happy to try and provide it. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-09 01:04 Message: Logged In: YES user_id=1344176 Originator: NO I haven't been able to reproduce this with Python 2.3.5, 2.4.4, 2.5.0 or SVN HEAD (all hand-built on Slackware Linux). What options are you providing to ./configure? ---------------------------------------------------------------------- Comment By: Fernando P?rez (fer_perez) Date: 2007-02-24 08:22 Message: Logged In: YES user_id=395388 Originator: YES No, in my case the original tests with 2.4 and 2.5 were done with the Ubuntu-provided (Edgy) versions, unmodified from their apt-get install state. But your comments are interesting. I just rebuilt 2.5 by hand from source on the same system, and this is what I get: tlon[bin]> ./python2.5 ~/code/python/inspect_bug.py Version info: (2, 5, 0, 'final', 0) File for `inspect` : /home/fperez/tmp/local/lib/python2.5/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/lib/python2.5/inspect.py Do these match? True OK tlon[bin]> ./python2.5 ~/code/python/inspect_bug_details.py Python version info: (2, 5, 0, 'final', 0) File info for `inspect.iscode function`: /home/fperez/tmp/local//lib/python2.5/inspect.py So basically it seems that there's a difference in the value of the func_code.co_filename object attribute depending on how the build was made. At this point I'm not really sure if this should be considered a Python bug or an Ubuntu one... Perhaps the Python build process can be made more robust, I simply don't know. But the end-user behavior /is/ a bug, so it would be nice to know how to fix it. Thanks for your info! ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-02-24 07:51 Message: Logged In: YES user_id=1727609 Originator: NO Hi, On a custom-compiled Python 2.5 on Ubuntu Dapper, I get: yello at outback:~/code/python $ python bug_1666807.py Version info: (2, 5, 0, 'final', 0) File for `inspect` : /usr/local/lib/python2.5/inspect.py File for `inspect.iscode`: /usr/local/lib/python2.5/inspect.py Do these match? True OK On a system python 2.4.3 on another Ubuntu Dapper system, I get: yello at adelaide:~/code/python $ python bug_1666807.py Version info: (2, 4, 3, 'final', 0) File for `inspect` : /usr/lib/python2.4/inspect.py File for `inspect.iscode`: /usr/lib/python2.4/inspect.py Do these match? True OK However, I can recreate this issue on another system (CentOS4) with a custom install where a symlink is involved. I get: [prompt goes here python]$ python bug_1666807.py Version info: (2, 2, 3, 'final', 0) File for `inspect` : /xxx/yyyy/PythonHome/lib/python2.2/inspect.py File for `inspect.iscode`: /xxx/yyyy/Python-2.2/lib/python2.2/inspect.py Do these match? 0 BUG - this is a bug in this version of Python Is a symlink involved on the system where you saw this behaviour? ---------------------------------------------------------------------- Comment By: Fernando P?rez (fer_perez) Date: 2007-02-23 17:57 Message: Logged In: YES user_id=395388 Originator: YES Note: a colleague just tested this under Python 2.4 for Mac OSX (intel), and the problem didn't show up there: import inspect print 'File for `code` :',inspect.getabsfile(code) print 'File for `code.interact`:',inspect.getabsfile(code.interact) Gives: File for `code` : /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/code.py File for `code.interact`: /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/code.py My original tests were done under Ubuntu Edgy Eft, using the Ubuntu-provided 2.4 and 2.5, and a hand-compiled 2.3.6 from the source download at python.org. HTH, f ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666807&group_id=5470 From noreply at sourceforge.net Fri Mar 16 15:42:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 07:42:20 -0700 Subject: [ python-Bugs-1531016 ] Comma not allowed at the end of argument list for **argument Message-ID: Bugs item #1531016, was opened at 2006-07-29 20:21 Message generated for change (Comment added) made by sean_gillespie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531016&group_id=5470 Please note that this 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: 2 Private: No Submitted By: Roman Suzi (rnd0110) Assigned to: Nobody/Anonymous (nobody) Summary: Comma not allowed at the end of argument list for **argument Initial Comment: This tells it all: >>> str('sdfd', **a,) File "", line 1 str('sdfd', **a,) ^ SyntaxError: invalid syntax >>> str('sdfd', *a,) File "", line 1 str('sdfd', *a,) ^ SyntaxError: invalid syntax While the docs tell otherwise: http://docs.python.org/ref/calls.html While having arguments after ** doesn't make sense, comma after ANY kinds of arguments seem to be more consistent. ---------------------------------------------------------------------- Comment By: Sean Gillespie (sean_gillespie) Date: 2007-03-16 14:42 Message: Logged In: YES user_id=1744567 Originator: NO This behavior seems as intended. According to the docs (http://docs.python.org/ref/calls.html): A trailing comma may be present after the positional and keyword arguments but does not affect the semantics. [snip] Formal parameters using the syntax "*identifier" or "**identifier" cannot be used as positional argument slots or as keyword argument names. I'm having trouble with what this actually means. However, the relevant section in the Grammar looks like this: arglist: (argument ',')* (argument [',']| '*' test [',' '**' test] | '**' test ) It looks like this logic was explicitly coded. If this is determined to be a bug, we can just add [','] after the test in both cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531016&group_id=5470 From noreply at sourceforge.net Fri Mar 16 16:22:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 08:22:39 -0700 Subject: [ python-Bugs-1682205 ] [PATCH] TypeError swallowing in UNPACK_SEQUENCE opcode Message-ID: Bugs item #1682205, was opened at 2007-03-16 17:22 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=1682205&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Piet Delport (pjdelport) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] TypeError swallowing in UNPACK_SEQUENCE opcode Initial Comment: When UNPACK_SEQUENCE unpacks an iterable, it replaces any TypeError raised by the iterator with a new, catch-all TypeError('unpack non-sequence') instance (and empty traceback). This message is less useful than the ones it's (presumably) intended to replace (raised by PyObject_GetIter(), via unpack_iterable()), and obviously wrong when the TypeError originates in unrelated user code. The attached patch simply removes the check, which (as far as i can tell) has no ill effects. Examples (without the patch): >>> a, b, c = 7 TypeError: unpack non-sequence >>> a, b = ( int(x) for x in ['5', ()] ) TypeError: unpack non-sequence With the patch applied, these result in: >>> a, b, c = 7 TypeError: 'int' object is not iterable >>> a, b = ( int(x) for x in ['5', ()] ) TypeError: int() argument must be a string or a number, not 'tuple' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682205&group_id=5470 From noreply at sourceforge.net Fri Mar 16 16:41:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 08:41:31 -0700 Subject: [ python-Feature Requests-1379573 ] python executable optionally should search script on PATH Message-ID: Feature Requests item #1379573, was opened at 2005-12-13 16:13 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&group_id=5470 Please note that this 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 Private: No Submitted By: Christoph Conrad (cconrad) Assigned to: Nobody/Anonymous (nobody) Summary: python executable optionally should search script on PATH Initial Comment: I've seen that with perl - parameter -S means search script on path. Very helpful. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-16 16:41 Message: Logged In: YES user_id=21627 Originator: NO I believe this was fixed some time ago. cconrad, if it still doesn't work for you, please give precise instructions on how to reproduce the problem: what exact Python version are you using (it's supposed to work for 2.4.4 and 2.5.0 atleast), what path did you install Python to what does your demo script look like, where is it installed, and what is the precise error that you get when you run it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-16 07:39 Message: Logged In: YES user_id=33168 Originator: NO What's the status of this? Is it a bug report? ---------------------------------------------------------------------- Comment By: Christoph Conrad (cconrad) Date: 2006-02-20 12:10 Message: Logged In: YES user_id=21338 (1) (HKCU|HKLM)\Software\Classes\Python.File\open\command really is (HKCU|HKLM)\Software\Classes\Python.File\shell\open\command (2) with python 24 a new behaviour occurs: i try to execute the script on the commandline, but a dialog boy appears with: the file "[...correct complete path to the script...]" could not be found. Again, if i prepend python.exe, everything works as expected. windows 2000 professional. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-20 10:14 Message: Logged In: YES user_id=1188172 Do you mean that the registry setting is ok, but the parameters are not passed correctly? ---------------------------------------------------------------------- Comment By: Christoph Conrad (cconrad) Date: 2006-02-20 09:12 Message: Logged In: YES user_id=21338 I checked the registry. It's ok. It's windows 2000. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-01-16 22:29 Message: Logged In: YES user_id=21627 That (arguments not passed to the script) was a bug in some versions of the Windows installer. Please verify that the registry, at (HKCU|HKLM)\Software\Classes\Python.File\open\command has the value '[path]python.exe "%1" %*'. The %* part should arrange for arguments being passed. ---------------------------------------------------------------------- Comment By: Christoph Conrad (cconrad) Date: 2006-01-16 11:59 Message: Logged In: YES user_id=21338 > On windows, you should be able to just invoke the_script.py > (i.e. without a preceding python.exe). Does this not work > for you? It works - but command line args are not given to the called script. If i prepend python.exe, command line args are transferred correctly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-01-14 19:34 Message: Logged In: YES user_id=21627 On windows, you should be able to just invoke the_script.py (i.e. without a preceding python.exe). Does this not work for you? ---------------------------------------------------------------------- Comment By: Christoph Conrad (cconrad) Date: 2005-12-15 23:00 Message: Logged In: YES user_id=21338 i meant the windows operating system. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-12-15 22:40 Message: Logged In: YES user_id=1188172 I don't know... if the script is in the PATH, isn't it normally executable too? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&group_id=5470 From noreply at sourceforge.net Fri Mar 16 17:00:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 09:00:20 -0700 Subject: [ python-Bugs-1682241 ] Problems with urllib2 read() Message-ID: Bugs item #1682241, was opened at 2007-03-16 17:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682241&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lucas Malor (lucas_malor) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with urllib2 read() Initial Comment: urllib2 objects opened with urlopen() does not have the method seek() as file objects. So reading only some bytes from opened urls is pratically forbidden. An example: I tried to open an url and check if it's a gzip file. If IOError is raised I read the file (to do this I applied the #1675951 patch: https://sourceforge.net/tracker/index.php?func=detail&aid=1675951&group_id=5470&atid=305470 ) But after I tried to open the file as gzip, if it's not a gzip file the current position in the urllib object is on the second byte. So read() returns the data from the 3rd to the last byte. You can't check the header of the file before storing it on hd. Well, so what is urlopen() for? If I must store the file by url on hd and reload it, I can use urlretrieve() ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682241&group_id=5470 From noreply at sourceforge.net Fri Mar 16 20:58:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 12:58:36 -0700 Subject: [ python-Bugs-1682403 ] docutils clarification request for "rest" Message-ID: Bugs item #1682403, was opened at 2007-03-16 19: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=1682403&group_id=5470 Please note that this 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 Private: No Submitted By: j vickroy (jvickroy) Assigned to: Nobody/Anonymous (nobody) Summary: docutils clarification request for "rest" Initial Comment: >From the definition of long_description: *'long string'* Multiple lines of plain text in reStructuredText format (see http://docutils.sf.net/). in: http://docs.python.org/dist/meta-data.html I incorrectly concluded that the the bdist_wininst installer would provide visual markup for long_description specified in restructured text. According to Thomas Heller, that is not the case. I wish to suggest adding this clarification to the distutils documentation perhaps in one or both of the following documents: http://docs.python.org/dist/postinstallation-script.html http://docs.python.org/dist/meta-data.html Thanks, -- jv ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682403&group_id=5470 From noreply at sourceforge.net Fri Mar 16 21:44:27 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 13:44:27 -0700 Subject: [ python-Bugs-1650090 ] doctest doesn't find nested functions Message-ID: Bugs item #1650090, was opened at 2007-02-01 21:20 Message generated for change (Comment added) made by pjdelport You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650090&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel Brown (danb37) Assigned to: Tim Peters (tim_one) Summary: doctest doesn't find nested functions Initial Comment: If a nested function has doctests, they won't be run: {{{ def f(): ''' >>> 'a' 'a' ''' def g(): ''' >>> 'a' 'b' ''' pass pass }}} DocTestFinder will only find f's doctest and won't recurse to find g's, surprising the programmer when they (hopefully) discover that their inner doctest is incorrect! ---------------------------------------------------------------------- Comment By: Piet Delport (pjdelport) Date: 2007-03-16 22:44 Message: Logged In: YES user_id=1607528 Originator: NO DocTestFinder uses object inspection to find docstrings, which doesn't really allow this kind of thing: g isn't created until f is actually run. Making this possible would probably require implementing an alternate doctest finder based on source code inspection (via the new _ast module?). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650090&group_id=5470 From noreply at sourceforge.net Sat Mar 17 01:37:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 17:37:16 -0700 Subject: [ python-Bugs-1650090 ] doctest doesn't find nested functions Message-ID: Bugs item #1650090, was opened at 2007-02-01 20:20 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650090&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel Brown (danb37) Assigned to: Tim Peters (tim_one) Summary: doctest doesn't find nested functions Initial Comment: If a nested function has doctests, they won't be run: {{{ def f(): ''' >>> 'a' 'a' ''' def g(): ''' >>> 'a' 'b' ''' pass pass }}} DocTestFinder will only find f's doctest and won't recurse to find g's, surprising the programmer when they (hopefully) discover that their inner doctest is incorrect! ---------------------------------------------------------------------- >Comment By: ?iga Seilnacht (zseil) Date: 2007-03-17 01:37 Message: Logged In: YES user_id=1326842 Originator: NO Here is a patch that implements this new functionality. I don't know how desireable this feature is, I just wanted to see if it could be done. File Added: doctest_nested_functions.diff ---------------------------------------------------------------------- Comment By: Piet Delport (pjdelport) Date: 2007-03-16 21:44 Message: Logged In: YES user_id=1607528 Originator: NO DocTestFinder uses object inspection to find docstrings, which doesn't really allow this kind of thing: g isn't created until f is actually run. Making this possible would probably require implementing an alternate doctest finder based on source code inspection (via the new _ast module?). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650090&group_id=5470 From noreply at sourceforge.net Sat Mar 17 09:20:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Mar 2007 01:20:32 -0700 Subject: [ python-Bugs-1681671 ] Python and Indeterminate Forms (Math) Message-ID: Bugs item #1681671, was opened at 2007-03-15 12:28 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681671&group_id=5470 Please note that this 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 Private: No Submitted By: jehahn (jehahn) Assigned to: Nobody/Anonymous (nobody) Summary: Python and Indeterminate Forms (Math) Initial Comment: Primary example: Python 2.3.5 (#1, Mar 20 2005, 20:38:20) [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> 0 ** 0 1 Per http://mathworld.wolfram.com/Indeterminate.html, 0 ** 0 is an indeterminate form. 0 ** 0 should probably return NaN and NOT 1. Other examples include: Python 2.3.5 (#1, Mar 20 2005, 20:38:20) [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> inf = float("infinity") >>> inf ** 0 1.0 >>> 1 ** inf 1.0 For a few others, Python provides an arguably correct answer of NaN. Examples: Python 2.3.5 (#1, Mar 20 2005, 20:38:20) [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> inf = float("infinity") >>> inf * 0 nan >>> inf / inf nan >>> inf - inf nan And, of course, for the most obvious indeterminate form (0/0) Python does precisely the right thing: Python 2.3.5 (#1, Mar 20 2005, 20:38:20) [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> 0/0 Traceback (most recent call last): File "", line 1, in ? ZeroDivisionError: integer division or modulo by zero It could be argued that the correct thing to do here is to throw an exception - mathematically speaking these forms are about as meaningful as division by zero which Python handles by throwing an exception. (unlike Java and IEEE 754, which do arguably evil things here by returning +/- infinity for the quantity k/0 for all k != 0) Unfortunately, some people doing numerical work may have gotten used to the current Python behavior so the change isn't without risk. And some of the current values are common "conventions" used to simplify certain common issues. (e.g. 0 ** 0 == 1) Moreover, I don't know if this is dependent on platform (having only tried it on a couple of the boxes I have handy.) However, from a mathematical purist's standpoint, Python is doing the wrong thing on these counts. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-17 01:20 Message: Logged In: YES user_id=341410 Originator: NO Python's behavior with respect to floating point arithmetic is left to the platform's C floating point libraries. For example, on my Windows machine running Python 2.3.5, float("infinity") raises a ValueError. I would also point out that 0/0 is integer division in Python 2.3.5 . For other examples of platform-specific behavior: Python 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> inf*0 -1.#IND >>> inf**0 1.0 >>> 1**inf Traceback (most recent call last): File "", line 1, in ? ValueError: (33, 'Domain error') >>> inf*0 -1.#IND >>> inf/inf -1.#IND >>> inf-inf -1.#IND >>> So yeah. If you don't like how Python does math, complain to your vendor (Apple) or compile a version of Python with a C floating point library that works the way you want it to. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681671&group_id=5470 From noreply at sourceforge.net Sat Mar 17 15:03:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Mar 2007 07:03:34 -0700 Subject: [ python-Bugs-1682729 ] Documentation error (section 3.4.1) Message-ID: Bugs item #1682729, was opened at 2007-03-17 15:03 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=1682729&group_id=5470 Please note that this 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 Private: No Submitted By: emlyn (emlyncorrin) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation error (section 3.4.1) Initial Comment: In the documentation section 3.4.1 Basic customization (url: http://docs.python.org/ref/customization.html) it states: There are no reflected (swapped-argument) versions of these methods (to be used when the left argument does not support the operation but the right argument does); rather, __lt__() and __gt__() are each other's reflection, __le__() and __ge__() are each other's reflection, and __eq__() and __ne__() are their own reflection. Surely that should be __lt__() and __ge__() are each other's reflection, and __le__() and __gt__(). I assume this is just a typo, but I haven't checked that Python itself gets it right. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682729&group_id=5470 From noreply at sourceforge.net Sat Mar 17 16:06:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Mar 2007 08:06:52 -0700 Subject: [ python-Bugs-1682749 ] next method assignment is ignored in new-style classes Message-ID: Bugs item #1682749, was opened at 2007-03-17 15:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682749&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Albert Weichselbraun (albert2611) Assigned to: Nobody/Anonymous (nobody) Summary: next method assignment is ignored in new-style classes Initial Comment: in old-style classes the next method of an iterator-superclass can be "overwritten" using self.next = self.new_next_method when new-style classes are used the assignment is ignored and instead of new_next_method the next method of the superclass is called when the class is used as iterator (tested for python2.3-2.5 under debian/linux). - if the next() method is called directly, the assigned method is used (see attached code example). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682749&group_id=5470 From noreply at sourceforge.net Sat Mar 17 16:40:35 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Mar 2007 08:40:35 -0700 Subject: [ python-Bugs-1682729 ] Documentation error (section 3.4.1) Message-ID: Bugs item #1682729, was opened at 2007-03-17 15:03 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682729&group_id=5470 Please note that this 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: Invalid Priority: 5 Private: No Submitted By: emlyn (emlyncorrin) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation error (section 3.4.1) Initial Comment: In the documentation section 3.4.1 Basic customization (url: http://docs.python.org/ref/customization.html) it states: There are no reflected (swapped-argument) versions of these methods (to be used when the left argument does not support the operation but the right argument does); rather, __lt__() and __gt__() are each other's reflection, __le__() and __ge__() are each other's reflection, and __eq__() and __ne__() are their own reflection. Surely that should be __lt__() and __ge__() are each other's reflection, and __le__() and __gt__(). I assume this is just a typo, but I haven't checked that Python itself gets it right. ---------------------------------------------------------------------- >Comment By: ?iga Seilnacht (zseil) Date: 2007-03-17 16:40 Message: Logged In: YES user_id=1326842 Originator: NO No, the documentation is correct (as well as Python's behaviour). For example, you have a left_five and right_five, which are int like objects with value 5, and left_five is missing a __lt__ method. If you do a left_five < right_five comparison, you want right_five's __gt__ method called, because right_five's __ge__ method would return True, since their values are equal. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682729&group_id=5470 From noreply at sourceforge.net Sat Mar 17 16:52:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Mar 2007 08:52:47 -0700 Subject: [ python-Bugs-1682749 ] next method assignment is ignored in new-style classes Message-ID: Bugs item #1682749, was opened at 2007-03-17 15:06 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682749&group_id=5470 Please note that this 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.5 >Status: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: Albert Weichselbraun (albert2611) >Assigned to: Neal Norwitz (nnorwitz) Summary: next method assignment is ignored in new-style classes Initial Comment: in old-style classes the next method of an iterator-superclass can be "overwritten" using self.next = self.new_next_method when new-style classes are used the assignment is ignored and instead of new_next_method the next method of the superclass is called when the class is used as iterator (tested for python2.3-2.5 under debian/linux). - if the next() method is called directly, the assigned method is used (see attached code example). ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-17 15:52 Message: Logged In: YES user_id=849994 Originator: NO This is another incarnation of __methods__ being looked up on the type, not the instance, except that next() is not a __method__ yet. For new-style classes, this behavior is considered correct. Neal? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682749&group_id=5470 From noreply at sourceforge.net Sat Mar 17 17:27:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Mar 2007 09:27:03 -0700 Subject: [ python-Bugs-1682749 ] next method assignment is ignored in new-style classes Message-ID: Bugs item #1682749, was opened at 2007-03-17 15:06 Message generated for change (Comment added) made by albert2611 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682749&group_id=5470 Please note that this 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.5 >Status: Open Resolution: Invalid Priority: 5 Private: No Submitted By: Albert Weichselbraun (albert2611) Assigned to: Neal Norwitz (nnorwitz) Summary: next method assignment is ignored in new-style classes Initial Comment: in old-style classes the next method of an iterator-superclass can be "overwritten" using self.next = self.new_next_method when new-style classes are used the assignment is ignored and instead of new_next_method the next method of the superclass is called when the class is used as iterator (tested for python2.3-2.5 under debian/linux). - if the next() method is called directly, the assigned method is used (see attached code example). ---------------------------------------------------------------------- >Comment By: Albert Weichselbraun (albert2611) Date: 2007-03-17 16:27 Message: Logged In: YES user_id=806170 Originator: YES i only experienced this behavior for the next method in iterator classes. overwriting methods with other names using an assignment works as expected. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-17 15:52 Message: Logged In: YES user_id=849994 Originator: NO This is another incarnation of __methods__ being looked up on the type, not the instance, except that next() is not a __method__ yet. For new-style classes, this behavior is considered correct. Neal? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682749&group_id=5470 From noreply at sourceforge.net Sun Mar 18 03:42:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Mar 2007 19:42:58 -0700 Subject: [ python-Bugs-1682940 ] os.walk should traverse outward symlinks Message-ID: Bugs item #1682940, was opened at 2007-03-18 02:42 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=1682940&group_id=5470 Please note that this 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 Private: No Submitted By: Tasci Synx (synx13) Assigned to: Nobody/Anonymous (nobody) Summary: os.walk should traverse outward symlinks Initial Comment: To my dismay, I discovered that os.walk will ignore all symlinks, even symlinks that link to somewhere outside of the directory being walked. So I made a little patch to os.py, I hope you apply it, or some figment thereof. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682940&group_id=5470 From noreply at sourceforge.net Sun Mar 18 04:42:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Mar 2007 20:42:37 -0700 Subject: [ python-Bugs-1679498 ] Lib/io.py open uses unset "bs" Message-ID: Bugs item #1679498, was opened at 2007-03-12 22:28 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1679498&group_id=5470 Please note that this 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 3000 Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Jim Jewett (jimjjewett) >Assigned to: Guido van Rossum (gvanrossum) Summary: Lib/io.py open uses unset "bs" Initial Comment: Within the open function, it says """ try: bs = os.fstat(raw.fileno()).st_blksize except (os.error, AttributeError): if bs > 1: buffering = bs """ Since this is the first use of name "bs", I wouldn't expect it to have any value after an Exception. If this is actually correct, it at least deserves a comment. ----------------- (second issue) _PyFileIO sets self._writable but doesn't use it (even in writable()) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-17 23:42 Message: Logged In: YES user_id=6380 Originator: NO Thanks for reporting this! First issue: Committed revision 54424. Second issue: Committed revision 54425. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1679498&group_id=5470 From noreply at sourceforge.net Sun Mar 18 04:42:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Mar 2007 20:42:58 -0700 Subject: [ python-Bugs-1679498 ] Lib/io.py open uses unset "bs" Message-ID: Bugs item #1679498, was opened at 2007-03-12 22:28 Message generated for change (Settings changed) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1679498&group_id=5470 Please note that this 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 3000 >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Guido van Rossum (gvanrossum) Summary: Lib/io.py open uses unset "bs" Initial Comment: Within the open function, it says """ try: bs = os.fstat(raw.fileno()).st_blksize except (os.error, AttributeError): if bs > 1: buffering = bs """ Since this is the first use of name "bs", I wouldn't expect it to have any value after an Exception. If this is actually correct, it at least deserves a comment. ----------------- (second issue) _PyFileIO sets self._writable but doesn't use it (even in writable()) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-17 23:42 Message: Logged In: YES user_id=6380 Originator: NO Thanks for reporting this! First issue: Committed revision 54424. Second issue: Committed revision 54425. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1679498&group_id=5470 From noreply at sourceforge.net Sun Mar 18 04:50:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Mar 2007 20:50:44 -0700 Subject: [ python-Bugs-1628906 ] clarify 80-char limit Message-ID: Bugs item #1628906, was opened at 2007-01-05 11:45 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1628906&group_id=5470 Please note that this 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 3000 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Jim Jewett (jimjjewett) >Assigned to: Guido van Rossum (gvanrossum) Summary: clarify 80-char limit Initial Comment: PEP 3099 says: """ Coding style ============ * The (recommended) maximum line width will remain 80 characters, for both C and Python code. Thread: "C style guide", http://mail.python.org/pipermail/python-3000/2006-March/000131.html """ It should be clarified that this really means 72-79 characters, perhaps by adding the following sentence: Note that according to PEP 8, this actually means no more than 79 characters in a line, and no more than about 72 in docstrings or comments. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-17 23:50 Message: Logged In: YES user_id=6380 Originator: NO IMO it's excessive to explain this. If you really want the words changed, just email me a patch directly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1628906&group_id=5470 From noreply at sourceforge.net Sun Mar 18 04:55:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Mar 2007 20:55:15 -0700 Subject: [ python-Bugs-1650903 ] PyFloat_FromString deprecated form Message-ID: Bugs item #1650903, was opened at 2007-02-02 14:41 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650903&group_id=5470 Please note that this 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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: PyFloat_FromString deprecated form Initial Comment: PyFloat_FromString takes two arguments, and the only purpose of the second is to avoid changing the API. Extracts from Tim's 2000 comment: Since we can't change the interface of a public API function, pend is still supported but now *officially* useless: if pend is not NULL, *pend is set to NULL. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-17 23:55 Message: Logged In: YES user_id=6380 Originator: NO I think I should relax that statement a bit. IMO it's OK to change the signature (for Py3k) since the compiler will report an error if you call it with the old signature. What's *not* OK is to keep the signature (or to keep it compatible anyway) but change the *behavior*, as that would cause bugs that are only caught (if at all) at runtime, and will hence be hard to debug. Examples of bad changes would be changing the reference count behavior of an API, changing the type of object returned (if a specific type was previously documented) or making it possible to return NULL where this was previous not possible. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-03-06 19:06 Message: Logged In: YES user_id=764593 Originator: YES I didn't realize that a decision had been made about the C API stability. I would indeed propose changing it, but probably not if it the rest of the API (even for strings and unicode?) is supposed to stay stable. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 13:54 Message: Logged In: YES user_id=849994 Originator: NO (cont'd) C API functions shouldn't even change signature in Py 3000. Therefore, a new name would be needed... ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 13:53 Message: Logged In: YES user_id=849994 Originator: NO What do you propose to do? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650903&group_id=5470 From noreply at sourceforge.net Sun Mar 18 04:58:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Mar 2007 20:58:32 -0700 Subject: [ python-Bugs-1673757 ] string and unicode formatting are missing a test for "G" Message-ID: Bugs item #1673757, was opened at 2007-03-04 21:34 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eric V. Smith (ericvsmith) Assigned to: Nobody/Anonymous (nobody) Summary: string and unicode formatting are missing a test for "G" Initial Comment: In stringobject.c and unicodeobject.c, the formatting codes for 'e', 'E', 'f', 'F', 'g', and 'G' all get routed to formatfloat(). formatfloat() is essentially identical in stringobject.c and unicodeobject.c. 'F' is mapped to 'f'. There is a test for excess precision for 'f' and 'g', but not one for 'G'. The "type == 'g'" test should be "(type == 'g' || type == 'G')". I assume this bug is in 2.5 and 2.6 as well, although I haven't verified that, yet. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-17 23:58 Message: Logged In: YES user_id=6380 Originator: NO Changing the group to 2.5; see the patch (http://python.org/sf/1673759) for an explanation. ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-06 06:10 Message: Logged In: YES user_id=411198 Originator: YES The patch was corrected, and tests added. ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-06 05:57 Message: Logged In: YES user_id=411198 Originator: YES Yes, my bad on not having tests and the diff being fubar. I've already started writing the tests, I should be done in the next 30 minutes. Expect a new patch. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2007-03-06 05:55 Message: Logged In: YES user_id=1038590 Originator: NO Behaviour is definitely present in the current 2.6 trunk, so I expect it to be present in the 2.5 maintenance branch too. On platforms which provide a correct implementation of vsnprintf, this won't cause a buffer overflow (but can give an incorrect result). As far as I can tell, the limited precision of C doubles saves you on platforms without vsnprintf (then again, I may not be abusing it correctly after forcing my dev tree to use the vsnprintf emulation, or else the behaviour of the emulation may vary with platform vagaries in vsprintf implementations). The patch doesn't currently apply cleanly - it needs to be regenerated using svn diff from the main python directory so that the filenames are correct. We also need a test case to make sure the problem never comes back (the string tests are a little confusing though, since the same tests are used for str, unicode & UserString). ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-04 21:47 Message: Logged In: YES user_id=411198 Originator: YES Patch for 3.0 is at http://python.org/sf/1673759 This should be checked in 2.5 and 2.6, but I don't have an environment to compile those. ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-04 21:42 Message: Logged In: YES user_id=411198 Originator: YES This is the correct behavior: >>> '%200.200g' % 1.0 Traceback (most recent call last): File "", line 1, in ? OverflowError: formatted float is too long (precision too large?) But 'G' is handled differently: >>> '%200.200G' % 1.0 ' 1' 'G' should give the same OverflowError as 'g'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&group_id=5470 From noreply at sourceforge.net Sun Mar 18 09:19:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Mar 2007 01:19:25 -0700 Subject: [ python-Bugs-1682940 ] os.walk should traverse outward symlinks Message-ID: Bugs item #1682940, was opened at 2007-03-18 02:42 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682940&group_id=5470 Please note that this 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: Out of Date Priority: 5 Private: No Submitted By: Tasci Synx (synx13) Assigned to: Nobody/Anonymous (nobody) Summary: os.walk should traverse outward symlinks Initial Comment: To my dismay, I discovered that os.walk will ignore all symlinks, even symlinks that link to somewhere outside of the directory being walked. So I made a little patch to os.py, I hope you apply it, or some figment thereof. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-18 08:19 Message: Logged In: YES user_id=849994 Originator: NO The detection of "outward" symlinks is unreliable because there may be a link there which links "back" into the walked hierarchy. For 2.6, os.walk already has a "followlinks" keyword argument, which will follow *all* symlinks. You can easily restrict them by removing them from the "dirs" list yielded to the caller. Closing as outdated. IMO, the one thing that could be improved is to have a cache of visited directories, and to not visit one if it's in the cache. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682940&group_id=5470 From noreply at sourceforge.net Sun Mar 18 17:43:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Mar 2007 09:43:51 -0700 Subject: [ python-Bugs-1663329 ] subprocess/popen close_fds perform poor if SC_OPEN_MAX is hi Message-ID: Bugs item #1663329, was opened at 2007-02-19 12:17 Message generated for change (Comment added) made by pjdelport You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1663329&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Performance Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: H. von Bargen (hvbargen) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess/popen close_fds perform poor if SC_OPEN_MAX is hi Initial Comment: If the value of sysconf("SC_OPEN_MAX") is high and you try to start a subprocess with subprocess.py or os.popen2 with close_fds=True, then starting the other process is very slow. This boils down to the following code in subprocess.py: def _close_fds(self, but): for i in xrange(3, MAXFD): if i == but: continue try: os.close(i) except: pass resp. the similar code in popen2.py: def _run_child(self, cmd): if isinstance(cmd, basestring): cmd = ['/bin/sh', '-c', cmd] for i in xrange(3, MAXFD): try: os.close(i) except OSError: pass There has been an optimization already (range has been replaced by xrange to reduce memory impact), but I think the problem is that for high values of MAXFD, usually a high percentage of the os.close statements will fail, raising an exception (which is an "expensive" operation). It has been suggested already to add a C implementation called "rclose" or "close_range" that tries to close all FDs in a given range (min, max) without the overhead of Python exception handling. I'd like emphasize that this is not a theoretical, but a real world problem: We have a Python application in a production environment on Sun Solaris. Some other software running on the same server needed a high value of 260000 for SC_OPEN_MAX (set with ulimit -n XXX or in some /etc/-file (don't know which one). Suddenly calling any other process with subprocess.Popen (..., close_fds=True) now took 14 seconds (!) instead of some microseconds. This caused a huge performance degradation, since the subprocess itself only needs only a few seconds. See also: Patches item #1607087 "popen() slow on AIX due to large FOPEN_MAX value". This contains a fix, but only for AIX - and I think the patch does not support the "but" argument used in subprocess.py. The correct solution should be coded in C, and should do the same as the _close_fds routine in subprocess.py. It could be optimized to make use of (operating-specific) system calls to close all handles from (but+1) to MAX_FD with "closefrom" or "fcntl" as proposed in the patch. ---------------------------------------------------------------------- Comment By: Piet Delport (pjdelport) Date: 2007-03-18 18:43 Message: Logged In: YES user_id=1607528 Originator: NO I've been bitten by this too: close_fds turns my a trivial little monitoring daemon (that reads the output of another status-reporting command once a second or so) into a monster that hogs the entire server. As H. von Bargen says, this kind of degradation should at least come with a warning (or, better, be fixed by C/Pyrex-ifying close_fds). ---------------------------------------------------------------------- Comment By: H. von Bargen (hvbargen) Date: 2007-02-22 22:16 Message: Logged In: YES user_id=1008979 Originator: YES Of course I am already closing any files as soon as possible. I know that I could use FD_CLOEXEC. But this would require that I do it explicitly for each descriptor that I use in my program. But this would be a tedious work and require platform-specific coding all around the program. And the whole bunch of python library functions (i.e. the logging module) do not use FD_CLOEXEC as well. Right now, more or less the only platform specific code in the program is where I call subprocesses, and I like to keep it that way. The same is true for the socket module. All sockets are by default inherited to child processes. So, the only way to prevent unwanted handles from inheriting to child processes, is in fact to specify close_fds=True in subprocess.py. If you think that a performance patch similar to the patch #16078087 makes no sense, then the close_fds argument should either be marked as deprecated or at least the documentation should mention that the implementation is slow for large values of SC_OPEN_MAX. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-02-21 20:18 Message: Logged In: YES user_id=21627 Originator: NO I understand you don't want the subprocess to inherit "incorrect" file descriptors. However, there are other ways to prevent that from happening: - you should close file descriptors as soon as you are done with the files - you should set the FD_CLOEXEC flag on all file descriptors you don't want to be inherited, using fnctl(fd, F_SETFD, 1) I understand that there are cases where neither these strategy is not practical, but if you follow it, the performance will be much better, as the closing of unused file descriptor is done in the exec(2) implementation of the operating system. ---------------------------------------------------------------------- Comment By: H. von Bargen (hvbargen) Date: 2007-02-21 17:42 Message: Logged In: YES user_id=1008979 Originator: YES No, I have to use close_fds=True, because I don't want to have the subprocess to inherit each and every file descriptor. This is for two reasons: i) Security - why should the subproces be able to work with all the parent processes' files? ii) Sometimes, for whatever reason, the subprocess (Oracle Reports in this case) seems to hang. And because it inherited all of the parent's log file handles, the paraent can not close and remove its log files correctly. This is the reason why I stumbled about close_fds at all. BTW on MS Windows, a similar (but not equivalent) solution was to create the log files as non-inheritable. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-02-21 01:45 Message: Logged In: YES user_id=21627 Originator: NO Wouldn't it be simpler for you to just don't pass close_fds=True to popen? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1663329&group_id=5470 From noreply at sourceforge.net Sun Mar 18 18:20:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Mar 2007 10:20:38 -0700 Subject: [ python-Bugs-1581906 ] test_sqlite fails on OSX G5 arch if test_ctypes is run Message-ID: Bugs item #1581906, was opened at 2006-10-21 13:02 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Skip Montanaro (montanaro) >Assigned to: Thomas Heller (theller) Summary: test_sqlite fails on OSX G5 arch if test_ctypes is run Initial Comment: I noticed a test_sqlite test failure on my Mac G5 the other day while trying to set up a buildbot for sqlalchemy. Everything runs fine on my G4 powerbook. Both machines run Mac OSX 10.4.8 with Apple's gcc 4.0.0, build 5026. I whittled the problem down to just having test_ctypes and test_sqlite enabled, then further whittled it down to just having Lib/ctypes/test/ test_find.py available (all other ctypes tests eliminated). More detailed problem descriptions are in these two postings to python-dev: http://article.gmane.org/gmane.comp.python.devel/84478 http://article.gmane.org/gmane.comp.python.devel/84481 Skip ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2007-03-18 12:20 Message: Logged In: YES user_id=44345 Originator: YES Thomas, I assigned this to you simply so you can cast your eye on the problem and see if you think there might be anything ctypes-related in the problem I've reported. I've ignored it up 'til now, but I bumped up against it again trying to get the Pybots SQLAlchemy test suite running on my Mac. During my previous encounter with this problem Ronald Oussouren reported on a possible connection with GLUT: http://mail.python.org/pipermail/python-dev/2006-October/069523.html Assuming there is no obvious ctypes connection you can determine (it's not clear to me that there is any current directory funny business going on) just assign it back to me and I'll try to find a pysqlite expert to take a look. Thx, Skip ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-10-21 13:04 Message: Logged In: YES user_id=44345 Another article here: http://article.gmane.org/gmane.comp.python.devel/84487 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470 From noreply at sourceforge.net Sun Mar 18 19:35:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Mar 2007 11:35:28 -0700 Subject: [ python-Bugs-1650903 ] PyFloat_FromString deprecated form Message-ID: Bugs item #1650903, was opened at 2007-02-02 19:41 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650903&group_id=5470 Please note that this 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 3000 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: PyFloat_FromString deprecated form Initial Comment: PyFloat_FromString takes two arguments, and the only purpose of the second is to avoid changing the API. Extracts from Tim's 2000 comment: Since we can't change the interface of a public API function, pend is still supported but now *officially* useless: if pend is not NULL, *pend is set to NULL. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-18 18:35 Message: Logged In: YES user_id=849994 Originator: NO Okay, I fixed this case in rev. 54433. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-18 03:55 Message: Logged In: YES user_id=6380 Originator: NO I think I should relax that statement a bit. IMO it's OK to change the signature (for Py3k) since the compiler will report an error if you call it with the old signature. What's *not* OK is to keep the signature (or to keep it compatible anyway) but change the *behavior*, as that would cause bugs that are only caught (if at all) at runtime, and will hence be hard to debug. Examples of bad changes would be changing the reference count behavior of an API, changing the type of object returned (if a specific type was previously documented) or making it possible to return NULL where this was previous not possible. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-03-07 00:06 Message: Logged In: YES user_id=764593 Originator: YES I didn't realize that a decision had been made about the C API stability. I would indeed propose changing it, but probably not if it the rest of the API (even for strings and unicode?) is supposed to stay stable. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 18:54 Message: Logged In: YES user_id=849994 Originator: NO (cont'd) C API functions shouldn't even change signature in Py 3000. Therefore, a new name would be needed... ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 18:53 Message: Logged In: YES user_id=849994 Originator: NO What do you propose to do? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650903&group_id=5470 From noreply at sourceforge.net Sun Mar 18 19:36:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Mar 2007 11:36:07 -0700 Subject: [ python-Feature Requests-1527705 ] optparse should support arbitrary number of arguments Message-ID: Feature Requests item #1527705, was opened at 2006-07-24 12:03 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1527705&group_id=5470 Please note that this 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: Invalid Priority: 5 Private: No Submitted By: Ritesh Raj Sarraf (riteshsarraf) Assigned to: Greg Ward (gward) Summary: optparse should support arbitrary number of arguments Initial Comment: Currently, the number of arguments an option can/should have, needs be defined. This is done using "nagrs". parser.add_option("", "--my-option", nargs=3) The problem is that at times it isn't predictable how many arguments you'll be receiving. I request the implementation of this feature in optparse, where the following could be possible. parser.add_option("", "--my-option", nargs=*) Thanks, Ritesh ---------------------------------------------------------------------- Comment By: Ritesh Raj Sarraf (riteshsarraf) Date: 2007-03-16 09:18 Message: Logged In: YES user_id=382018 Originator: YES Thanks for clarifying Neal. I've filed a bug with optik, #1681933 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-16 07:47 Message: Logged In: YES user_id=33168 Originator: NO I encourage you to file a feature request with optik if it's important to you. While it may not be the nicest way, it's the only way we can get anything done. I pointed you to optik so you can file the feature request if it's important to you. What has happened in the past is that this report would be left open forever. That is worse. If you think this is wrong, you can fix the problem by helping us resolve all the issues in python. Otherwise, there's no hope of us managing it. ---------------------------------------------------------------------- Comment By: Ritesh Raj Sarraf (riteshsarraf) Date: 2007-03-16 07:37 Message: Logged In: YES user_id=382018 Originator: YES I don't think this is the correct way of resolving a bug. You mark it as "Close" with a resolution "Invalid" when the bug was filed against "Python Library", of which optparse is one. Python ships optparse as part of its libraries. If internally, it is a separate project, you could file one there and link to it. But why just plain close it ? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-16 06:44 Message: Logged In: YES user_id=33168 Originator: NO Optik is maintained separately. Please file a feature request there: http://sourceforge.net/projects/optik ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-24 13:31 Message: Logged In: YES user_id=849994 I share effbot's view on that, but leaving to Greg to decide. In any case, this is a feature request. ---------------------------------------------------------------------- Comment By: Ritesh Raj Sarraf (riteshsarraf) Date: 2006-07-24 13:21 Message: Logged In: YES user_id=382018 Can you please go through the following link and give your comments ? http://groups.google.com/group/comp.lang.python/browse_thre ad/thread/277522927334b8d8 I feel its a valid feature request. Ritesh ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-24 12:57 Message: Logged In: YES user_id=849994 I don't know of any program that uses command line switches with a variable number of args, partly because you then cannot distinguish between option arguments and normal arguments. I you still need this, you can implement a custom callback, I think. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1527705&group_id=5470 From noreply at sourceforge.net Sun Mar 18 23:48:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Mar 2007 15:48:39 -0700 Subject: [ python-Bugs-1683288 ] xreload.py won't update class docstrings Message-ID: Bugs item #1683288, was opened at 2007-03-18 18: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=1683288&group_id=5470 Please note that this 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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: xreload.py won't update class docstrings Initial Comment: """ def _update_class(oldclass, newclass): ... for name in oldnames & newnames - {"__dict__", "__doc__"}: setattr(oldclass, name, _update(olddict[name], newdict[name])) return oldclass """ I assume __doc__ is skipped because a string can't be updated in place. But since oldclass is returned, __doc__ should still be replaced with the updated documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683288&group_id=5470 From noreply at sourceforge.net Mon Mar 19 00:49:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Mar 2007 16:49:32 -0700 Subject: [ python-Bugs-1666807 ] Incorrect file path reported by inspect.getabsfile() Message-ID: Bugs item #1666807, was opened at 2007-02-23 07:08 Message generated for change (Comment added) made by fer_perez You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666807&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Fernando P?rez (fer_perez) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect file path reported by inspect.getabsfile() Initial Comment: The following code demonstrates the problem succinctly: ### import inspect,sys print 'Version info:',sys.version_info print f1 = inspect.getabsfile(inspect) f2 = inspect.getabsfile(inspect.iscode) print 'File for `inspect` :',f1 print 'File for `inspect.iscode`:',f2 print 'Do these match?',f1==f2 if f1==f2: print 'OK' else: print 'BUG - this is a bug in this version of Python' ### EOF Running this on my system (Linux, Ubuntu Edgy) with 2.3, 2.4 and 2.5 produces: tlon[bin]> ./python2.3 ~/code/python/inspect_bug.py Version info: (2, 3, 6, 'final', 0) File for `inspect` : /home/fperez/tmp/local/lib/python2.3/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/lib/python2.3/inspect.py Do these match? True OK tlon[bin]> python2.4 ~/code/python/inspect_bug.py Version info: (2, 4, 4, 'candidate', 1) File for `inspect` : /usr/lib/python2.4/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/bin/inspect.py Do these match? False BUG - this is a bug in this version of Python tlon[bin]> python2.5 ~/code/python/inspect_bug.py Version info: (2, 5, 0, 'final', 0) File for `inspect` : /usr/lib/python2.5/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/bin/inspect.py Do these match? False BUG - this is a bug in this version of Python ### The problem arises in the fact that inspect relies, for functions (at least), on the func_code.co_filename attribute to contain a complete path. This changed between 2.3 and 2.4, but the inspect module was never updated. This code: ### import inspect,sys print 'Python version info:',sys.version_info print 'File info for `inspect.iscode function`:' print ' ',inspect.iscode.func_code.co_filename print ### EOF shows the problem: tlon[bin]> ./python2.3 ~/code/python/inspect_bug_details.py Python version info: (2, 3, 6, 'final', 0) File info for `inspect.iscode function`: /home/fperez/tmp/local//lib/python2.3/inspect.py tlon[bin]> python2.5 ~/code/python/inspect_bug_details.py Python version info: (2, 5, 0, 'final', 0) File info for `inspect.iscode function`: inspect.py ### (2.4 has the same issue). Basically, if the func_code.co_filename attribute now stores only the final filename without the full path, then the logic in the inspect module needs to be changed to accomodate this so that correct paths are reported to the user like they were in the 2.3 days. ---------------------------------------------------------------------- >Comment By: Fernando P?rez (fer_perez) Date: 2007-03-18 23:49 Message: Logged In: YES user_id=395388 Originator: YES Yes, though at least in this report we seem to have narrowed down the problem a little better. I'm perfectly willing to believe that Ubuntu is somehow mis-building their shipped Python, but it would be great if the Python build itself could be hardened against this being possible in the first place. Unfortunately I don't know how to better track the problem, but I'll be glad to provide info from my local system upon request. ---------------------------------------------------------------------- Comment By: ??iga Seilnacht (zseil) Date: 2007-03-16 14:06 Message: Logged In: YES user_id=1326842 Originator: NO It looks like this is a bug in Ubuntu build process. The logging package had the same problem: http://www.python.org/sf/1669498 http://www.python.org/sf/1633605 http://www.python.org/sf/1616422 ---------------------------------------------------------------------- Comment By: Fernando P?rez (fer_perez) Date: 2007-03-09 02:00 Message: Logged In: YES user_id=395388 Originator: YES As I mentioned, on hand-built Pythons I don't get the bug at all. So it may be a problem with how Ubuntu builds its Python, since I can reproduce the problem with both 2.4 and 2.5, but only with the default ones provided by Ubuntu Edgy. I don't know enough about their packaging system to know how to retrieve build info. There may be something odd in their build, but it would be nice if this simply couldn't happen at all. If anyone knows how to retrieve the relevant info from an ubuntu build, I'll be happy to try and provide it. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-09 00:04 Message: Logged In: YES user_id=1344176 Originator: NO I haven't been able to reproduce this with Python 2.3.5, 2.4.4, 2.5.0 or SVN HEAD (all hand-built on Slackware Linux). What options are you providing to ./configure? ---------------------------------------------------------------------- Comment By: Fernando P?rez (fer_perez) Date: 2007-02-24 07:22 Message: Logged In: YES user_id=395388 Originator: YES No, in my case the original tests with 2.4 and 2.5 were done with the Ubuntu-provided (Edgy) versions, unmodified from their apt-get install state. But your comments are interesting. I just rebuilt 2.5 by hand from source on the same system, and this is what I get: tlon[bin]> ./python2.5 ~/code/python/inspect_bug.py Version info: (2, 5, 0, 'final', 0) File for `inspect` : /home/fperez/tmp/local/lib/python2.5/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/lib/python2.5/inspect.py Do these match? True OK tlon[bin]> ./python2.5 ~/code/python/inspect_bug_details.py Python version info: (2, 5, 0, 'final', 0) File info for `inspect.iscode function`: /home/fperez/tmp/local//lib/python2.5/inspect.py So basically it seems that there's a difference in the value of the func_code.co_filename object attribute depending on how the build was made. At this point I'm not really sure if this should be considered a Python bug or an Ubuntu one... Perhaps the Python build process can be made more robust, I simply don't know. But the end-user behavior /is/ a bug, so it would be nice to know how to fix it. Thanks for your info! ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-02-24 06:51 Message: Logged In: YES user_id=1727609 Originator: NO Hi, On a custom-compiled Python 2.5 on Ubuntu Dapper, I get: yello at outback:~/code/python $ python bug_1666807.py Version info: (2, 5, 0, 'final', 0) File for `inspect` : /usr/local/lib/python2.5/inspect.py File for `inspect.iscode`: /usr/local/lib/python2.5/inspect.py Do these match? True OK On a system python 2.4.3 on another Ubuntu Dapper system, I get: yello at adelaide:~/code/python $ python bug_1666807.py Version info: (2, 4, 3, 'final', 0) File for `inspect` : /usr/lib/python2.4/inspect.py File for `inspect.iscode`: /usr/lib/python2.4/inspect.py Do these match? True OK However, I can recreate this issue on another system (CentOS4) with a custom install where a symlink is involved. I get: [prompt goes here python]$ python bug_1666807.py Version info: (2, 2, 3, 'final', 0) File for `inspect` : /xxx/yyyy/PythonHome/lib/python2.2/inspect.py File for `inspect.iscode`: /xxx/yyyy/Python-2.2/lib/python2.2/inspect.py Do these match? 0 BUG - this is a bug in this version of Python Is a symlink involved on the system where you saw this behaviour? ---------------------------------------------------------------------- Comment By: Fernando P?rez (fer_perez) Date: 2007-02-23 16:57 Message: Logged In: YES user_id=395388 Originator: YES Note: a colleague just tested this under Python 2.4 for Mac OSX (intel), and the problem didn't show up there: import inspect print 'File for `code` :',inspect.getabsfile(code) print 'File for `code.interact`:',inspect.getabsfile(code.interact) Gives: File for `code` : /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/code.py File for `code.interact`: /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/code.py My original tests were done under Ubuntu Edgy Eft, using the Ubuntu-provided 2.4 and 2.5, and a hand-compiled 2.3.6 from the source download at python.org. HTH, f ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666807&group_id=5470 From noreply at sourceforge.net Mon Mar 19 01:34:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Mar 2007 17:34:18 -0700 Subject: [ python-Bugs-1683316 ] select.select() injecting spurious text in stdout Message-ID: Bugs item #1683316, was opened at 2007-03-19 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=1683316&group_id=5470 Please note that this 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 Private: No Submitted By: Peter Williams (peter_ono) Assigned to: Nobody/Anonymous (nobody) Summary: select.select() injecting spurious text in stdout Initial Comment: I'm using a function (see attachment) similar to that described on Page 386 (Section 9.12) of the Python Cookbook (Second Edition) to capture the stdout and stderr streams of programs run with popen2.Popen3. This involves using select.select() to detect the availability of data on the two streams. Sometimes, what looks like a debugging message: "EXCEPTION IN SAFE SELECT 9\n" gets injected into the stdout stream. As far as I can tell this has only started occuring after updating to version 2.4.4. No exception occurs and the string just silently appears in stdout. Apart from the bogus text in stdout everything seems to be working correctly and I'm able to work around the problem by looking for the string and removing whenever it occurs. It looks to me like a debugging message that somebody forgot to remove. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683316&group_id=5470 From noreply at sourceforge.net Mon Mar 19 02:51:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Mar 2007 18:51:45 -0700 Subject: [ python-Bugs-1528074 ] difflib.SequenceMatcher.find_longest_match() wrong result Message-ID: Bugs item #1528074, was opened at 2006-07-24 19:59 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528074&group_id=5470 Please note that this 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 Private: No Submitted By: John Machin (sjmachin) Assigned to: Tim Peters (tim_one) Summary: difflib.SequenceMatcher.find_longest_match() wrong result Initial Comment: A short example script is attached. Two strings, each 500 bytes long. Longest match is the first 32 bytes of each string. Result produced is a 10-byte match later in the string. If one byte is chopped off the end of each string (len now 499 each), the correct result is produced. Other observations, none of which may be relevant: 1. Problem may be in the heuristic for "popular" elements in the __chain_b method. In this particular example, the character '0' (which has frequency of 6 in the "b" string) is not "popular" with a len of 500 but is "popular" with a len of 499. 2. '0' is the last byte of the correct longest match. 3. The correct longest match is at the start of the each of the strings. 4. Disabling the "popular" heuristic (like below) appears to make the problem go away: if 0: # if n >= 200 and len(indices) * 100 > n: populardict[elt] = 1 del indices[:] else: indices.append(i) 5. The callable self.isbpopular is created but appears to be unused. 6. The determination of "popular" doesn't accord with the comments, which say 1%. However with len==500, takes 6 to be popular. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-03-18 21:51 Message: Logged In: YES user_id=764593 Originator: NO I think the bug is documentation only. According to the comments (but not the docstring) find_longest_match returns the longest _interesting_ match. A single element appearing too often is likely to cause spurious matches, and is therefore not interesting. I do agree that this should be noted more prominently, so people don't try things like comparing text strings letter-by-letter (where 1% is far too low a threshhold for a 26-character alphabest). And yes, the comments on popular are correct -- it ignores elements which constitute *more* than 1%. I recommend closing this set of tracker items. If you could submit changes to the documentation (docstrings and/or help files; maybe even the comments), I would recommend applying them. ---------------------------------------------------------------------- Comment By: Denys Rtveliashvili (rtvd) Date: 2007-03-14 16:11 Message: Logged In: YES user_id=1416496 Originator: NO By the way, I found that the implementation should better be changed completely. The current one has a O(n^2) computational complexity, while the one, based on suffix trees using Ukkonen's algorithm would use only O(n) ---------------------------------------------------------------------- Comment By: Denys Rtveliashvili (rtvd) Date: 2007-03-11 11:29 Message: Logged In: YES user_id=1416496 Originator: NO I have sent a testcase for this bug into the SourceForge. The ID is #1678339. Also I have submitted a fix for this bug (ID #1678345), but the fix reduces the performance significantly. ---------------------------------------------------------------------- Comment By: Denys Rtveliashvili (rtvd) Date: 2007-03-10 12:24 Message: Logged In: YES user_id=1416496 Originator: NO The quick test for this bug is: for i in xrange(190, 200): text1 = "a" + "b"*i text2 = "b"*i + "c" m = difflib.SequenceMatcher(None, text1, text2) (aptr,bptr,l) = m.find_longest_match(0, len(text1), 0, len(text2)) print "i:", i, " l:", l, " aptr:", aptr, " bptr:", bptr assert l == i The assertion will fail when i==199 (the length of the texts will be 200). And yes, the bug is clearly "populardict"-related. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528074&group_id=5470 From noreply at sourceforge.net Mon Mar 19 03:00:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Mar 2007 19:00:41 -0700 Subject: [ python-Bugs-1681984 ] unittest documentation is incomplete Message-ID: Bugs item #1681984, was opened at 2007-03-16 11:17 Message generated for change (Comment added) made by haypo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681984&group_id=5470 Please note that this 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 Private: No Submitted By: STINNER Victor (haypo) Assigned to: Nobody/Anonymous (nobody) Summary: unittest documentation is incomplete Initial Comment: When I tried to write a test suite using many test cases, I read the documentation (docs.python.org) but it does work because I was unable to run my test suite. Using Google I realised that documentation is incomplete! In Python binding of gstreamer, I found a "TextTestRunner"! So, would it be possible to update the doc? ---------------------------------------------------------------------- >Comment By: STINNER Victor (haypo) Date: 2007-03-19 03:00 Message: Logged In: YES user_id=365388 Originator: YES "Could you please state what exactly is missing from the documentation, in your opinion?" Well, when I ready Python documentation I expect to have the full list of "builtin" modules, functions and classes. But if you check unittest module, documentation only list TestCase, TestSuite, TestResult and TestLoader. Whereas dir(unittest) gives TestCase, TestLoader, *TestProgram*, TestResult, TestSuite, *TextTestRunner*. So information about TestProgram and TextTestRunner is missing. I also expect a small example showing how to use a test runner and a test suite. I'm using: ------------------------------ 8< ----------------------- from unittest import TestSuite, TestLoader, TextTestRunner from sys import exit def loadTests(loader): """Generator listing all test cases""" ... def main(): loader = TestLoader() suite = TestSuite() for test in loadTests(loader.loadTestsFromTestCase): suite.addTests(test) runner = TextTestRunner(descriptions=2, verbosity=2) result = runner.run(suite) if result.failures or result.errors: exit(1) ------------------------------ 8< ----------------------- ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 14:02 Message: Logged In: YES user_id=849994 Originator: NO Could you please state what exactly is missing from the documentation, in your opinion? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681984&group_id=5470 From noreply at sourceforge.net Mon Mar 19 04:32:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Mar 2007 20:32:33 -0700 Subject: [ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds Message-ID: Bugs item #1683368, was opened at 2007-03-18 20: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=1683368&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Nobody/Anonymous (nobody) Summary: object.__init__ shouldn't allow args/kwds Initial Comment: object.__init__ currently allows any amount of args and keywords even though they're ignored. This is inconsistent with other built-ins, like list, that are stricter about what they'll accept. It's also inconsistent with object.__new__, which does throw if any are provided (if the default __init__ is to be used). To reproduce: object.__init__(object(), foo, bar=3) This is a slight irritation when using cooperative super calling. I'd like each class' __init__ to cherry-pick keyword params it accepts and pass the remaining ones up the chain, but right now I can't rely on object.__init__ to throw if there are remaining keywords by that point. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 From noreply at sourceforge.net Mon Mar 19 09:56:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 01:56:43 -0700 Subject: [ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds Message-ID: Bugs item #1683368, was opened at 2007-03-19 03:32 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) >Assigned to: Neal Norwitz (nnorwitz) Summary: object.__init__ shouldn't allow args/kwds Initial Comment: object.__init__ currently allows any amount of args and keywords even though they're ignored. This is inconsistent with other built-ins, like list, that are stricter about what they'll accept. It's also inconsistent with object.__new__, which does throw if any are provided (if the default __init__ is to be used). To reproduce: object.__init__(object(), foo, bar=3) This is a slight irritation when using cooperative super calling. I'd like each class' __init__ to cherry-pick keyword params it accepts and pass the remaining ones up the chain, but right now I can't rely on object.__init__ to throw if there are remaining keywords by that point. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-19 08:56 Message: Logged In: YES user_id=849994 Originator: NO I don't really understand either why object_new() checks the arguments, not object_init(): """ static int object_init(PyObject *self, PyObject *args, PyObject *kwds) { return 0; } /* If we don't have a tp_new for a new-style class, new will use this one. Therefore this should take no arguments/keywords. However, this new may also be inherited by objects that define a tp_init but no tp_new. These objects WILL pass argumets to tp_new, because it gets the same args as tp_init. So only allow arguments if we aren't using the default init, in which case we expect init to handle argument parsing. */ static PyObject * object_new(PyTypeObject *type, PyObject *args, PyObject *kwds) { if (type->tp_init == object_init && (PyTuple_GET_SIZE(args) || (kwds && PyDict_Check(kwds) && PyDict_Size(kwds)))) { PyErr_SetString(PyExc_TypeError, "default __new__ takes no parameters"); return NULL; } return type->tp_alloc(type, 0); } """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 From noreply at sourceforge.net Mon Mar 19 10:12:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 02:12:16 -0700 Subject: [ python-Bugs-1683316 ] select.select() injecting spurious text in stdout Message-ID: Bugs item #1683316, was opened at 2007-03-19 00:34 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683316&group_id=5470 Please note that this 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: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: Peter Williams (peter_ono) Assigned to: Nobody/Anonymous (nobody) Summary: select.select() injecting spurious text in stdout Initial Comment: I'm using a function (see attachment) similar to that described on Page 386 (Section 9.12) of the Python Cookbook (Second Edition) to capture the stdout and stderr streams of programs run with popen2.Popen3. This involves using select.select() to detect the availability of data on the two streams. Sometimes, what looks like a debugging message: "EXCEPTION IN SAFE SELECT 9\n" gets injected into the stdout stream. As far as I can tell this has only started occuring after updating to version 2.4.4. No exception occurs and the string just silently appears in stdout. Apart from the bogus text in stdout everything seems to be working correctly and I'm able to work around the problem by looking for the string and removing whenever it occurs. It looks to me like a debugging message that somebody forgot to remove. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-19 09:12 Message: Logged In: YES user_id=849994 Originator: NO I can find no occurrence of the message or parts of it in the current 2.5 or 2.6 branches. Please make sure that it is Python that emits that message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683316&group_id=5470 From noreply at sourceforge.net Mon Mar 19 10:12:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 02:12:56 -0700 Subject: [ python-Bugs-1683288 ] xreload.py won't update class docstrings Message-ID: Bugs item #1683288, was opened at 2007-03-18 22:48 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683288&group_id=5470 Please note that this 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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jim Jewett (jimjjewett) >Assigned to: Guido van Rossum (gvanrossum) Summary: xreload.py won't update class docstrings Initial Comment: """ def _update_class(oldclass, newclass): ... for name in oldnames & newnames - {"__dict__", "__doc__"}: setattr(oldclass, name, _update(olddict[name], newdict[name])) return oldclass """ I assume __doc__ is skipped because a string can't be updated in place. But since oldclass is returned, __doc__ should still be replaced with the updated documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683288&group_id=5470 From noreply at sourceforge.net Mon Mar 19 14:24:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 06:24:20 -0700 Subject: [ python-Bugs-1378305 ] Import value 1e400 from pyc fails Message-ID: Bugs item #1378305, was opened at 2005-12-11 21:09 Message generated for change (Comment added) made by sean_gillespie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378305&group_id=5470 Please note that this 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 Private: No Submitted By: Guenter Jantzen (gjantzen) Assigned to: Nobody/Anonymous (nobody) Summary: Import value 1e400 from pyc fails Initial Comment: ------------------------------------------- #file: bug.py #sys.version_info (2, 4, 2, 'final', 0) #Platform is Windows XP import sys, bug infinity = 1e400 if __name__ == "__main__": import bug print "Infinity is", bug.infinity ------------------------------------------ This code behaves correct using bug.py - when bug.pyc is not up to date / not exists: Infinity is 1.#INF and behaves wrong using bug.pyc - when bug.pyc is up to date: Infinity is 1.0 ---------------------------------------------------------------------- Comment By: Sean Gillespie (sean_gillespie) Date: 2007-03-19 13:24 Message: Logged In: YES user_id=1744567 Originator: NO This does indeed seem to be fixed in Python2.5. I was able to reproduce this with Python2.4 with similar results (Windows XP again). However, in Python2.5, the results are as expected. Python24: > python.exe bug.pyc Infinity is 1.0 Python25: > python.exe bug.pyc Infinity is 1.#INF ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-14 06:10 Message: Logged In: YES user_id=341410 This is a known bug with Python and floating point infinity literals. You can use: infinity = 1e155 * 1e155 I believe this is fixed in the latest Python 2.5 SVN. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378305&group_id=5470 From noreply at sourceforge.net Mon Mar 19 17:30:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 09:30:52 -0700 Subject: [ python-Bugs-1378305 ] Import value 1e400 from pyc fails Message-ID: Bugs item #1378305, was opened at 2005-12-11 21:09 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378305&group_id=5470 Please note that this 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: Fixed Priority: 5 Private: No Submitted By: Guenter Jantzen (gjantzen) Assigned to: Nobody/Anonymous (nobody) Summary: Import value 1e400 from pyc fails Initial Comment: ------------------------------------------- #file: bug.py #sys.version_info (2, 4, 2, 'final', 0) #Platform is Windows XP import sys, bug infinity = 1e400 if __name__ == "__main__": import bug print "Infinity is", bug.infinity ------------------------------------------ This code behaves correct using bug.py - when bug.pyc is not up to date / not exists: Infinity is 1.#INF and behaves wrong using bug.pyc - when bug.pyc is up to date: Infinity is 1.0 ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-19 16:30 Message: Logged In: YES user_id=849994 Originator: NO Fixed, then. ---------------------------------------------------------------------- Comment By: Sean Gillespie (sean_gillespie) Date: 2007-03-19 13:24 Message: Logged In: YES user_id=1744567 Originator: NO This does indeed seem to be fixed in Python2.5. I was able to reproduce this with Python2.4 with similar results (Windows XP again). However, in Python2.5, the results are as expected. Python24: > python.exe bug.pyc Infinity is 1.0 Python25: > python.exe bug.pyc Infinity is 1.#INF ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-14 06:10 Message: Logged In: YES user_id=341410 This is a known bug with Python and floating point infinity literals. You can use: infinity = 1e155 * 1e155 I believe this is fixed in the latest Python 2.5 SVN. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378305&group_id=5470 From noreply at sourceforge.net Mon Mar 19 18:15:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 10:15:02 -0700 Subject: [ python-Bugs-1681984 ] unittest documentation is incomplete Message-ID: Bugs item #1681984, was opened at 2007-03-16 06:17 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681984&group_id=5470 Please note that this 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 Private: No Submitted By: STINNER Victor (haypo) >Assigned to: Collin Winter (collinwinter) Summary: unittest documentation is incomplete Initial Comment: When I tried to write a test suite using many test cases, I read the documentation (docs.python.org) but it does work because I was unable to run my test suite. Using Google I realised that documentation is incomplete! In Python binding of gstreamer, I found a "TextTestRunner"! So, would it be possible to update the doc? ---------------------------------------------------------------------- Comment By: STINNER Victor (haypo) Date: 2007-03-18 22:00 Message: Logged In: YES user_id=365388 Originator: YES "Could you please state what exactly is missing from the documentation, in your opinion?" Well, when I ready Python documentation I expect to have the full list of "builtin" modules, functions and classes. But if you check unittest module, documentation only list TestCase, TestSuite, TestResult and TestLoader. Whereas dir(unittest) gives TestCase, TestLoader, *TestProgram*, TestResult, TestSuite, *TextTestRunner*. So information about TestProgram and TextTestRunner is missing. I also expect a small example showing how to use a test runner and a test suite. I'm using: ------------------------------ 8< ----------------------- from unittest import TestSuite, TestLoader, TextTestRunner from sys import exit def loadTests(loader): """Generator listing all test cases""" ... def main(): loader = TestLoader() suite = TestSuite() for test in loadTests(loader.loadTestsFromTestCase): suite.addTests(test) runner = TextTestRunner(descriptions=2, verbosity=2) result = runner.run(suite) if result.failures or result.errors: exit(1) ------------------------------ 8< ----------------------- ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 09:02 Message: Logged In: YES user_id=849994 Originator: NO Could you please state what exactly is missing from the documentation, in your opinion? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681984&group_id=5470 From noreply at sourceforge.net Mon Mar 19 18:16:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 10:16:42 -0700 Subject: [ python-Bugs-1675967 ] Python2.5 can't read a (complex) pickle build by python2.4 Message-ID: Bugs item #1675967, was opened at 2007-03-07 13:16 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675967&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michael Vogt (mvo) >Assigned to: ?iga Seilnacht (zseil) Summary: Python2.5 can't read a (complex) pickle build by python2.4 Initial Comment: Part of gnome-app-install in ubuntu is a pickle data structure cache. If I create this pickle with python 2.4 and read it later with 2.5. I get the following error: $ python2.5 -c 'import pickle; pickle.load(open("/var/cache/app-install/menu.p"))' /usr/lib/python2.5/pickle.py:1124: DeprecationWarning: The sre module is deprecated, please import re. __import__(module) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/pickle.py", line 1370, in load return Unpickler(file).load() File "/usr/lib/python2.5/pickle.py", line 858, in load dispatch[key](self) File "/usr/lib/python2.5/pickle.py", line 1090, in load_global klass = self.find_class(module, name) File "/usr/lib/python2.5/pickle.py", line 1126, in find_class klass = getattr(mod, name) AttributeError: 'module' object has no attribute '_compile' With: $ python2.4 -c 'import pickle; pickle.load(open("/var/cache/app-install/menu.p"))' egon at top ~ $ It loads just fine. The test pickle can be found here: http://people.ubuntu.com/~mvo/gnome-app-install/menu.p.gz Cheers, Michael ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-11 11:40 Message: Logged In: YES user_id=1326842 Originator: NO Attaching the patch with a test here. Unpickling old patterns with this patch works, but it still issues a DeprecationWarning. The test itself is a bit obscure, but the other option is to add a binary file to the test suite. File Added: sre_pickle_compatibility.diff ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-07 14:43 Message: Logged In: YES user_id=1326842 Originator: NO This happens because of SRE_Pattern objects in jour pickle. The sre module was renamed to re in Python 2.5, but the old pickles still expect the _compile function in sre module. I posted the patch here: http://freeweb.siol.net/chollus/ Could you try if it fixes the problem for you and in that case, attach it to this report? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675967&group_id=5470 From noreply at sourceforge.net Mon Mar 19 18:22:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 10:22:28 -0700 Subject: [ python-Bugs-1673403 ] date-datetime comparison doesn't work Message-ID: Bugs item #1673403, was opened at 2007-03-04 06:51 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673403&group_id=5470 Please note that this 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.5 >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Jon Ribbens (jribbens) Assigned to: Tim Peters (tim_one) Summary: date-datetime comparison doesn't work Initial Comment: Summary: bug #1028306 was not a bug, but the fix for it introduced one Comparing a date to a datetime currently throws an exception. This makes no sense. In what way is: datetime(2006, 1, 1, 0, 0, 0) < date(2007, 1, 1) not a perfectly reasonable and well-defined comparison? Throwing an exception here violates the "Principle of Least Surprise" to a considerable degree. Obviously some slight ambiguity arises if the date and the datetime differ only in the time part. There are two sensible responses in this situation that I can see: Treat dates as if they have a time-part of midnight. This is my preferred solution, and it is already what the datetime module does, for example, when subtracting two dates. Treat dates as if they refer to the entire day, i.e. if the date and datetime differ only in the time part then they are equal. This is consistent but becomes confusing in other situations such as when subtracting dates. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-19 13:22 Message: Logged In: YES user_id=1344176 Originator: NO Quoting from http://mail.python.org/pipermail/python-ideas/2007-March/000331.html: """refusing to compare dates and datetimes is the right thing to do""". Closing. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2007-03-08 16:09 Message: Logged In: YES user_id=80475 Originator: NO Tim, any thoughts? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-08 15:55 Message: Logged In: YES user_id=1344176 Originator: NO I think this warrants discussion on python-dev (http://mail.python.org/mailman/listinfo/python-dev) as to which of the two date interpretations to pick. Please post a description of the problem there and ask for suggestions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673403&group_id=5470 From noreply at sourceforge.net Mon Mar 19 19:53:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 11:53:30 -0700 Subject: [ python-Feature Requests-415692 ] smarter temporary file object Message-ID: Feature Requests item #415692, was opened at 2001-04-12 11:37 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=415692&group_id=5470 Please note that this 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: Accepted Priority: 5 Private: No Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: smarter temporary file object Initial Comment: Jim Fulton suggested the following: I wonder if it would be a good idea to have a new kind of temporary file that stored data in memory unless: - The data exceeds some size, or - Somebody asks for a fileno. Then the cgi module (and other apps) could use this thing in a uniform way. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-19 14:53 Message: Logged In: YES user_id=1344176 Originator: NO Patch #1630118 checked in as r54439. ---------------------------------------------------------------------- Comment By: Dustin J. Mitchell (djmitche) Date: 2007-01-07 15:36 Message: Logged In: YES user_id=7446 Originator: NO Patch is at http://python.org/sf/1630118 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-01-02 23:52 Message: Logged In: YES user_id=6380 Originator: YES I've reopened the issue for you. Do try to interest some other core developer in reviewing your code, or it will take a long time... Thanks for remembering! ---------------------------------------------------------------------- Comment By: Dustin J. Mitchell (djmitche) Date: 2007-01-02 23:30 Message: Logged In: YES user_id=7446 Originator: NO I have a potential implementation for this, intended to be included in Lib/tempfile.py. Because the issue is closed, I can't attach it. Let's see if posting to the issue will open that option up. Dustin ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 12:51 Message: Logged In: YES user_id=6380 Thank you. I've moved this feature request to PEP 42, "Feature Requests". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=415692&group_id=5470 From noreply at sourceforge.net Mon Mar 19 19:54:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 11:54:02 -0700 Subject: [ python-Bugs-1683872 ] module-ctypes should show platform availability Message-ID: Bugs item #1683872, was opened at 2007-03-19 11:54 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=1683872&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Noah Spurrier (noah) Assigned to: Nobody/Anonymous (nobody) Summary: module-ctypes should show platform availability Initial Comment: It is not clear that ctypes is only for Microsoft Windows. Many other module documentation pages have a line similar to this: Availability: Unix. This was even more confusing because ctypes is listed under "Generic Operating System Services". http://docs.python.org/lib/module-ctypes.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683872&group_id=5470 From noreply at sourceforge.net Mon Mar 19 20:05:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 12:05:13 -0700 Subject: [ python-Feature Requests-1673203 ] add identity function Message-ID: Feature Requests item #1673203, was opened at 2007-03-03 19:21 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 Please note that this 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 Private: No Submitted By: paul rubin (phr) Assigned to: Raymond Hettinger (rhettinger) Summary: add identity function Initial Comment: Requested and assigned to Raymond at his suggestion: http://groups.google.com/group/comp.lang.python/msg/603870361743c85c There should be an identify function identity(x)=x. I suggest it also take and ignore an optional second arg: identity(x1,x2)=x1. The second arg can be useful in some generator expressions: foo = (x for x in bar if condition(x) and identity(True, memoize(x)) That allows calling memoize (or some other function) on the selected elements in the genexp, and disposing of the returned value. It's sort of like the const function (K combinator) to go along with the identity function's I combinator. OK, the above is not really in the functional spirit, but it's been useful. There could conceivably be also an actual const function const(k)=partial(identity,k) but I can't remember needing that in Python code. The two-arg identity function (uncurried version of const) is probably enough. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-19 15:05 Message: Logged In: YES user_id=1344176 Originator: NO I can see adding the 1-argument form to operator or functools (as it's useful in functional programming), but the 2-argument form you've suggested is right out. If you really feel the need to torture a "for" loop into a genexp/listcomp like that, foo = (x for x in bar if condition(x) and [memoize(x)]) does the same thing using today's capabilities. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-12 16:06 Message: Logged In: YES user_id=341410 Originator: NO Not all x line functions should be built into Python. Further, Python's standard syntax offers an infix operator that does the same thing (though in slightly different order as described below, you can reorder with minimal effort). identity(X, Y) -> (Y and False) or X Also, the only use-case that you are provided and that I can imagine, are examples like you provide where one is changing state within a statement (if, elif, while, etc.) or expression (generator, list comprehension, conditional, etc.). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 09:21 Message: Logged In: YES user_id=835142 Originator: NO 1. If this proposal is accepted, it will make sense to deprecate the use of None as an identity function in map: >>> map(None, range(10)) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] 2. Some other languages have an dyadic identity function that returns the *second* argument. For example, K has : primitive: identity:(:) identity[1;2] 2 The rationale in K is that it is useful in an ammed function that replaces entries of an an array with a result of a dyadic function applied to the old and the supplied value and it is natural to have old value first: @[1 2 3;1;-;20] 1 -18 3 @[1 2 3;1;:;20] 1 20 3 This rationale does not apply to Python, but in the absence of other reasons to choose the order of arguments, Python may as well follow the precedent. Does anyone know a less exotic language that has a dyadic identity? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 From noreply at sourceforge.net Mon Mar 19 20:07:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 12:07:31 -0700 Subject: [ python-Feature Requests-1506122 ] Add "compose" function to the functools Message-ID: Feature Requests item #1506122, was opened at 2006-06-14 11:12 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506122&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gregory Petrosyan (gregory_p) Assigned to: Nobody/Anonymous (nobody) Summary: Add "compose" function to the functools Initial Comment: I think it would be very usefull to have something similar to Haskell's "dot" operator in Python, IMO it should be something like this (untested): def compose(f, g): return lambda *args, **kws: f(g(*args, **kws)) but C-coded. So, _functools can be a good place for it. -- Regards, Gregory. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-19 15:07 Message: Logged In: YES user_id=1344176 Originator: NO If there's interest in this, I already have an implementation in my functional package (http://cheeseshop.python.org/pypi/functional). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506122&group_id=5470 From noreply at sourceforge.net Mon Mar 19 20:11:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 12:11:56 -0700 Subject: [ python-Bugs-1683872 ] module-ctypes should show platform availability Message-ID: Bugs item #1683872, was opened at 2007-03-19 18:54 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683872&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Noah Spurrier (noah) Assigned to: Nobody/Anonymous (nobody) Summary: module-ctypes should show platform availability Initial Comment: It is not clear that ctypes is only for Microsoft Windows. Many other module documentation pages have a line similar to this: Availability: Unix. This was even more confusing because ctypes is listed under "Generic Operating System Services". http://docs.python.org/lib/module-ctypes.html ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-19 19:11 Message: Logged In: YES user_id=849994 Originator: NO Why do you think ctypes is for Windows only? The first tutorial page already covers Windows and Linux. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683872&group_id=5470 From noreply at sourceforge.net Mon Mar 19 20:57:24 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 12:57:24 -0700 Subject: [ python-Feature Requests-1673203 ] add identity function Message-ID: Feature Requests item #1673203, was opened at 2007-03-03 19:21 Message generated for change (Comment added) made by belopolsky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 Please note that this 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 Private: No Submitted By: paul rubin (phr) Assigned to: Raymond Hettinger (rhettinger) Summary: add identity function Initial Comment: Requested and assigned to Raymond at his suggestion: http://groups.google.com/group/comp.lang.python/msg/603870361743c85c There should be an identify function identity(x)=x. I suggest it also take and ignore an optional second arg: identity(x1,x2)=x1. The second arg can be useful in some generator expressions: foo = (x for x in bar if condition(x) and identity(True, memoize(x)) That allows calling memoize (or some other function) on the selected elements in the genexp, and disposing of the returned value. It's sort of like the const function (K combinator) to go along with the identity function's I combinator. OK, the above is not really in the functional spirit, but it's been useful. There could conceivably be also an actual const function const(k)=partial(identity,k) but I can't remember needing that in Python code. The two-arg identity function (uncurried version of const) is probably enough. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-19 15:57 Message: Logged In: YES user_id=835142 Originator: NO I have just realized that the requested functionality is known in C as the comma operator. I often find myself writing "return Py_INCREF(o),o;" in my C code, but I cannot really defend that idiom against "Py_INCREF(o); return o;" alternative. My personal reason is entirely C-specific, if followed an if(), the first form does not require curly braces. In any case, comma operator can be emulated in python as exp1,expr2,expr3 -> (exp1,expr2,expr3)[-1] Since multi-argument "identity" is likely to be rejected, my proposal to alter the order of arguments is moot. My other suggestion that with identity, map(None, ..) should be deprecated in favor of map(identity, ..) is probably an arument against the identity proposal now. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-19 15:05 Message: Logged In: YES user_id=1344176 Originator: NO I can see adding the 1-argument form to operator or functools (as it's useful in functional programming), but the 2-argument form you've suggested is right out. If you really feel the need to torture a "for" loop into a genexp/listcomp like that, foo = (x for x in bar if condition(x) and [memoize(x)]) does the same thing using today's capabilities. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-12 16:06 Message: Logged In: YES user_id=341410 Originator: NO Not all x line functions should be built into Python. Further, Python's standard syntax offers an infix operator that does the same thing (though in slightly different order as described below, you can reorder with minimal effort). identity(X, Y) -> (Y and False) or X Also, the only use-case that you are provided and that I can imagine, are examples like you provide where one is changing state within a statement (if, elif, while, etc.) or expression (generator, list comprehension, conditional, etc.). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 09:21 Message: Logged In: YES user_id=835142 Originator: NO 1. If this proposal is accepted, it will make sense to deprecate the use of None as an identity function in map: >>> map(None, range(10)) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] 2. Some other languages have an dyadic identity function that returns the *second* argument. For example, K has : primitive: identity:(:) identity[1;2] 2 The rationale in K is that it is useful in an ammed function that replaces entries of an an array with a result of a dyadic function applied to the old and the supplied value and it is natural to have old value first: @[1 2 3;1;-;20] 1 -18 3 @[1 2 3;1;:;20] 1 20 3 This rationale does not apply to Python, but in the absence of other reasons to choose the order of arguments, Python may as well follow the precedent. Does anyone know a less exotic language that has a dyadic identity? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 From noreply at sourceforge.net Mon Mar 19 21:01:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 13:01:43 -0700 Subject: [ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds Message-ID: Bugs item #1683368, was opened at 2007-03-18 23:32 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) >Assigned to: Guido van Rossum (gvanrossum) Summary: object.__init__ shouldn't allow args/kwds Initial Comment: object.__init__ currently allows any amount of args and keywords even though they're ignored. This is inconsistent with other built-ins, like list, that are stricter about what they'll accept. It's also inconsistent with object.__new__, which does throw if any are provided (if the default __init__ is to be used). To reproduce: object.__init__(object(), foo, bar=3) This is a slight irritation when using cooperative super calling. I'd like each class' __init__ to cherry-pick keyword params it accepts and pass the remaining ones up the chain, but right now I can't rely on object.__init__ to throw if there are remaining keywords by that point. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 16:01 Message: Logged In: YES user_id=6380 Originator: NO I'll try to explain why I did it this way. I was considering the single inheritance case implementing an Immutable object, which overrides __new__ but has no need to override __init__ (since it's too late to do anything in __init__ for an Immutable object). Since the __init__ still gets called it would be annoying to have to override it just to make the error go away if there was a check in __init__. The other case is overriding __init__ without overriding __new__, which is the most common way of doing Mutable objects; here you wouldn't want __new__ to complain about extra args. So the only time when you'd want complaints is if both __new__ and __init__ are the defaults, in which case it doesn't really matter whether you implement this in __init__ or in __new__, so I arbitrarily chose __new__. I wasn't thinking of your use case at the time though (cooperative super calls to __init__, which still isn't something I engage in on a day-to-day basis). I wonder if the right thing to do wouldn't be to implement the same check both in __init__ and in __new__. Am I makign sense? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-19 04:56 Message: Logged In: YES user_id=849994 Originator: NO I don't really understand either why object_new() checks the arguments, not object_init(): """ static int object_init(PyObject *self, PyObject *args, PyObject *kwds) { return 0; } /* If we don't have a tp_new for a new-style class, new will use this one. Therefore this should take no arguments/keywords. However, this new may also be inherited by objects that define a tp_init but no tp_new. These objects WILL pass argumets to tp_new, because it gets the same args as tp_init. So only allow arguments if we aren't using the default init, in which case we expect init to handle argument parsing. */ static PyObject * object_new(PyTypeObject *type, PyObject *args, PyObject *kwds) { if (type->tp_init == object_init && (PyTuple_GET_SIZE(args) || (kwds && PyDict_Check(kwds) && PyDict_Size(kwds)))) { PyErr_SetString(PyExc_TypeError, "default __new__ takes no parameters"); return NULL; } return type->tp_alloc(type, 0); } """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 From noreply at sourceforge.net Mon Mar 19 23:45:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 15:45:57 -0700 Subject: [ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds Message-ID: Bugs item #1683368, was opened at 2007-03-18 20:32 Message generated for change (Comment added) made by blakeross You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Guido van Rossum (gvanrossum) Summary: object.__init__ shouldn't allow args/kwds Initial Comment: object.__init__ currently allows any amount of args and keywords even though they're ignored. This is inconsistent with other built-ins, like list, that are stricter about what they'll accept. It's also inconsistent with object.__new__, which does throw if any are provided (if the default __init__ is to be used). To reproduce: object.__init__(object(), foo, bar=3) This is a slight irritation when using cooperative super calling. I'd like each class' __init__ to cherry-pick keyword params it accepts and pass the remaining ones up the chain, but right now I can't rely on object.__init__ to throw if there are remaining keywords by that point. ---------------------------------------------------------------------- >Comment By: Blake Ross (blakeross) Date: 2007-03-19 15:45 Message: Logged In: YES user_id=1747060 Originator: YES Makes sense. I don't think we can ever be completely correct here since we're inferring intent from the presence of __init__/__new__ that's liable to be wrong in some cases, but it's likely correct often enough that it's worth doing. If I understand correctly, we want to be more forgiving iff one of the two methods is used, so it seems like we should be complaining if both are used *or* if neither is used. After all, I could add a __new__ to my coop use case and I'd still want object to complain. If that's the case, both object_new and object_init should be complaining if ((tp->tp_new == object_new && tp->tp_init == object_init) || (tp->tp_new != object_new && tp->tp_init != object_init)). Of course, for the paranoid, there's always the risk that __new__ will modify these class functions and change the outcome :) For instance, if a class had a __new__ and no __init__ and its __new__ changed __new__ back to object.__new__, object_init on that run would be fooled into thinking it's using the defaults for both and would complain. I think this could only be fixed in type_call, which is rather ugly...but then, this *is* a special case of the "call __init__ after __new__" behavior, and we're trying to solve it within the methods themselves. Perhaps this last point is academic enough to be ignored...I don't know why anyone would do this, although the language makes it possible. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 13:01 Message: Logged In: YES user_id=6380 Originator: NO I'll try to explain why I did it this way. I was considering the single inheritance case implementing an Immutable object, which overrides __new__ but has no need to override __init__ (since it's too late to do anything in __init__ for an Immutable object). Since the __init__ still gets called it would be annoying to have to override it just to make the error go away if there was a check in __init__. The other case is overriding __init__ without overriding __new__, which is the most common way of doing Mutable objects; here you wouldn't want __new__ to complain about extra args. So the only time when you'd want complaints is if both __new__ and __init__ are the defaults, in which case it doesn't really matter whether you implement this in __init__ or in __new__, so I arbitrarily chose __new__. I wasn't thinking of your use case at the time though (cooperative super calls to __init__, which still isn't something I engage in on a day-to-day basis). I wonder if the right thing to do wouldn't be to implement the same check both in __init__ and in __new__. Am I makign sense? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-19 01:56 Message: Logged In: YES user_id=849994 Originator: NO I don't really understand either why object_new() checks the arguments, not object_init(): """ static int object_init(PyObject *self, PyObject *args, PyObject *kwds) { return 0; } /* If we don't have a tp_new for a new-style class, new will use this one. Therefore this should take no arguments/keywords. However, this new may also be inherited by objects that define a tp_init but no tp_new. These objects WILL pass argumets to tp_new, because it gets the same args as tp_init. So only allow arguments if we aren't using the default init, in which case we expect init to handle argument parsing. */ static PyObject * object_new(PyTypeObject *type, PyObject *args, PyObject *kwds) { if (type->tp_init == object_init && (PyTuple_GET_SIZE(args) || (kwds && PyDict_Check(kwds) && PyDict_Size(kwds)))) { PyErr_SetString(PyExc_TypeError, "default __new__ takes no parameters"); return NULL; } return type->tp_alloc(type, 0); } """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 From noreply at sourceforge.net Tue Mar 20 00:31:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 16:31:58 -0700 Subject: [ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds Message-ID: Bugs item #1683368, was opened at 2007-03-18 23:32 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Guido van Rossum (gvanrossum) Summary: object.__init__ shouldn't allow args/kwds Initial Comment: object.__init__ currently allows any amount of args and keywords even though they're ignored. This is inconsistent with other built-ins, like list, that are stricter about what they'll accept. It's also inconsistent with object.__new__, which does throw if any are provided (if the default __init__ is to be used). To reproduce: object.__init__(object(), foo, bar=3) This is a slight irritation when using cooperative super calling. I'd like each class' __init__ to cherry-pick keyword params it accepts and pass the remaining ones up the chain, but right now I can't rely on object.__init__ to throw if there are remaining keywords by that point. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 19:31 Message: Logged In: YES user_id=6380 Originator: NO Attached is a patch that implements this proposal, adding copious commentary. It doesn't seem to break anything in the test suite. I wonder if we should even make the check more rigid: check the argument list if either the current method *is* overridden or the other one *is not* overridden. This would make super calls check the arguments even if the other method is overridden. What do you think? File Added: new_init.patch ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-19 18:45 Message: Logged In: YES user_id=1747060 Originator: YES Makes sense. I don't think we can ever be completely correct here since we're inferring intent from the presence of __init__/__new__ that's liable to be wrong in some cases, but it's likely correct often enough that it's worth doing. If I understand correctly, we want to be more forgiving iff one of the two methods is used, so it seems like we should be complaining if both are used *or* if neither is used. After all, I could add a __new__ to my coop use case and I'd still want object to complain. If that's the case, both object_new and object_init should be complaining if ((tp->tp_new == object_new && tp->tp_init == object_init) || (tp->tp_new != object_new && tp->tp_init != object_init)). Of course, for the paranoid, there's always the risk that __new__ will modify these class functions and change the outcome :) For instance, if a class had a __new__ and no __init__ and its __new__ changed __new__ back to object.__new__, object_init on that run would be fooled into thinking it's using the defaults for both and would complain. I think this could only be fixed in type_call, which is rather ugly...but then, this *is* a special case of the "call __init__ after __new__" behavior, and we're trying to solve it within the methods themselves. Perhaps this last point is academic enough to be ignored...I don't know why anyone would do this, although the language makes it possible. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 16:01 Message: Logged In: YES user_id=6380 Originator: NO I'll try to explain why I did it this way. I was considering the single inheritance case implementing an Immutable object, which overrides __new__ but has no need to override __init__ (since it's too late to do anything in __init__ for an Immutable object). Since the __init__ still gets called it would be annoying to have to override it just to make the error go away if there was a check in __init__. The other case is overriding __init__ without overriding __new__, which is the most common way of doing Mutable objects; here you wouldn't want __new__ to complain about extra args. So the only time when you'd want complaints is if both __new__ and __init__ are the defaults, in which case it doesn't really matter whether you implement this in __init__ or in __new__, so I arbitrarily chose __new__. I wasn't thinking of your use case at the time though (cooperative super calls to __init__, which still isn't something I engage in on a day-to-day basis). I wonder if the right thing to do wouldn't be to implement the same check both in __init__ and in __new__. Am I makign sense? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-19 04:56 Message: Logged In: YES user_id=849994 Originator: NO I don't really understand either why object_new() checks the arguments, not object_init(): """ static int object_init(PyObject *self, PyObject *args, PyObject *kwds) { return 0; } /* If we don't have a tp_new for a new-style class, new will use this one. Therefore this should take no arguments/keywords. However, this new may also be inherited by objects that define a tp_init but no tp_new. These objects WILL pass argumets to tp_new, because it gets the same args as tp_init. So only allow arguments if we aren't using the default init, in which case we expect init to handle argument parsing. */ static PyObject * object_new(PyTypeObject *type, PyObject *args, PyObject *kwds) { if (type->tp_init == object_init && (PyTuple_GET_SIZE(args) || (kwds && PyDict_Check(kwds) && PyDict_Size(kwds)))) { PyErr_SetString(PyExc_TypeError, "default __new__ takes no parameters"); return NULL; } return type->tp_alloc(type, 0); } """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 From noreply at sourceforge.net Tue Mar 20 00:35:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 16:35:32 -0700 Subject: [ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds Message-ID: Bugs item #1683368, was opened at 2007-03-18 23:32 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Guido van Rossum (gvanrossum) Summary: object.__init__ shouldn't allow args/kwds Initial Comment: object.__init__ currently allows any amount of args and keywords even though they're ignored. This is inconsistent with other built-ins, like list, that are stricter about what they'll accept. It's also inconsistent with object.__new__, which does throw if any are provided (if the default __init__ is to be used). To reproduce: object.__init__(object(), foo, bar=3) This is a slight irritation when using cooperative super calling. I'd like each class' __init__ to cherry-pick keyword params it accepts and pass the remaining ones up the chain, but right now I can't rely on object.__init__ to throw if there are remaining keywords by that point. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 19:35 Message: Logged In: YES user_id=6380 Originator: NO This smells enough like a new feature that it couldn't go into 2.5. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 19:31 Message: Logged In: YES user_id=6380 Originator: NO Attached is a patch that implements this proposal, adding copious commentary. It doesn't seem to break anything in the test suite. I wonder if we should even make the check more rigid: check the argument list if either the current method *is* overridden or the other one *is not* overridden. This would make super calls check the arguments even if the other method is overridden. What do you think? File Added: new_init.patch ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-19 18:45 Message: Logged In: YES user_id=1747060 Originator: YES Makes sense. I don't think we can ever be completely correct here since we're inferring intent from the presence of __init__/__new__ that's liable to be wrong in some cases, but it's likely correct often enough that it's worth doing. If I understand correctly, we want to be more forgiving iff one of the two methods is used, so it seems like we should be complaining if both are used *or* if neither is used. After all, I could add a __new__ to my coop use case and I'd still want object to complain. If that's the case, both object_new and object_init should be complaining if ((tp->tp_new == object_new && tp->tp_init == object_init) || (tp->tp_new != object_new && tp->tp_init != object_init)). Of course, for the paranoid, there's always the risk that __new__ will modify these class functions and change the outcome :) For instance, if a class had a __new__ and no __init__ and its __new__ changed __new__ back to object.__new__, object_init on that run would be fooled into thinking it's using the defaults for both and would complain. I think this could only be fixed in type_call, which is rather ugly...but then, this *is* a special case of the "call __init__ after __new__" behavior, and we're trying to solve it within the methods themselves. Perhaps this last point is academic enough to be ignored...I don't know why anyone would do this, although the language makes it possible. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 16:01 Message: Logged In: YES user_id=6380 Originator: NO I'll try to explain why I did it this way. I was considering the single inheritance case implementing an Immutable object, which overrides __new__ but has no need to override __init__ (since it's too late to do anything in __init__ for an Immutable object). Since the __init__ still gets called it would be annoying to have to override it just to make the error go away if there was a check in __init__. The other case is overriding __init__ without overriding __new__, which is the most common way of doing Mutable objects; here you wouldn't want __new__ to complain about extra args. So the only time when you'd want complaints is if both __new__ and __init__ are the defaults, in which case it doesn't really matter whether you implement this in __init__ or in __new__, so I arbitrarily chose __new__. I wasn't thinking of your use case at the time though (cooperative super calls to __init__, which still isn't something I engage in on a day-to-day basis). I wonder if the right thing to do wouldn't be to implement the same check both in __init__ and in __new__. Am I makign sense? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-19 04:56 Message: Logged In: YES user_id=849994 Originator: NO I don't really understand either why object_new() checks the arguments, not object_init(): """ static int object_init(PyObject *self, PyObject *args, PyObject *kwds) { return 0; } /* If we don't have a tp_new for a new-style class, new will use this one. Therefore this should take no arguments/keywords. However, this new may also be inherited by objects that define a tp_init but no tp_new. These objects WILL pass argumets to tp_new, because it gets the same args as tp_init. So only allow arguments if we aren't using the default init, in which case we expect init to handle argument parsing. */ static PyObject * object_new(PyTypeObject *type, PyObject *args, PyObject *kwds) { if (type->tp_init == object_init && (PyTuple_GET_SIZE(args) || (kwds && PyDict_Check(kwds) && PyDict_Size(kwds)))) { PyErr_SetString(PyExc_TypeError, "default __new__ takes no parameters"); return NULL; } return type->tp_alloc(type, 0); } """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 From noreply at sourceforge.net Tue Mar 20 02:27:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 18:27:25 -0700 Subject: [ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds Message-ID: Bugs item #1683368, was opened at 2007-03-18 20:32 Message generated for change (Comment added) made by blakeross You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Guido van Rossum (gvanrossum) Summary: object.__init__ shouldn't allow args/kwds Initial Comment: object.__init__ currently allows any amount of args and keywords even though they're ignored. This is inconsistent with other built-ins, like list, that are stricter about what they'll accept. It's also inconsistent with object.__new__, which does throw if any are provided (if the default __init__ is to be used). To reproduce: object.__init__(object(), foo, bar=3) This is a slight irritation when using cooperative super calling. I'd like each class' __init__ to cherry-pick keyword params it accepts and pass the remaining ones up the chain, but right now I can't rely on object.__init__ to throw if there are remaining keywords by that point. ---------------------------------------------------------------------- >Comment By: Blake Ross (blakeross) Date: 2007-03-19 18:27 Message: Logged In: YES user_id=1747060 Originator: YES I think making the check more rigid is a good idea, since this should throw: class a(object): def __init__(self, foo): super(a, self).__init__(foo) def __new__(cls, foo): return object.__new__(cls) a(1) (minor typo in the patch: "solution it" -> "solution is") ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 16:35 Message: Logged In: YES user_id=6380 Originator: NO This smells enough like a new feature that it couldn't go into 2.5. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 16:31 Message: Logged In: YES user_id=6380 Originator: NO Attached is a patch that implements this proposal, adding copious commentary. It doesn't seem to break anything in the test suite. I wonder if we should even make the check more rigid: check the argument list if either the current method *is* overridden or the other one *is not* overridden. This would make super calls check the arguments even if the other method is overridden. What do you think? File Added: new_init.patch ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-19 15:45 Message: Logged In: YES user_id=1747060 Originator: YES Makes sense. I don't think we can ever be completely correct here since we're inferring intent from the presence of __init__/__new__ that's liable to be wrong in some cases, but it's likely correct often enough that it's worth doing. If I understand correctly, we want to be more forgiving iff one of the two methods is used, so it seems like we should be complaining if both are used *or* if neither is used. After all, I could add a __new__ to my coop use case and I'd still want object to complain. If that's the case, both object_new and object_init should be complaining if ((tp->tp_new == object_new && tp->tp_init == object_init) || (tp->tp_new != object_new && tp->tp_init != object_init)). Of course, for the paranoid, there's always the risk that __new__ will modify these class functions and change the outcome :) For instance, if a class had a __new__ and no __init__ and its __new__ changed __new__ back to object.__new__, object_init on that run would be fooled into thinking it's using the defaults for both and would complain. I think this could only be fixed in type_call, which is rather ugly...but then, this *is* a special case of the "call __init__ after __new__" behavior, and we're trying to solve it within the methods themselves. Perhaps this last point is academic enough to be ignored...I don't know why anyone would do this, although the language makes it possible. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 13:01 Message: Logged In: YES user_id=6380 Originator: NO I'll try to explain why I did it this way. I was considering the single inheritance case implementing an Immutable object, which overrides __new__ but has no need to override __init__ (since it's too late to do anything in __init__ for an Immutable object). Since the __init__ still gets called it would be annoying to have to override it just to make the error go away if there was a check in __init__. The other case is overriding __init__ without overriding __new__, which is the most common way of doing Mutable objects; here you wouldn't want __new__ to complain about extra args. So the only time when you'd want complaints is if both __new__ and __init__ are the defaults, in which case it doesn't really matter whether you implement this in __init__ or in __new__, so I arbitrarily chose __new__. I wasn't thinking of your use case at the time though (cooperative super calls to __init__, which still isn't something I engage in on a day-to-day basis). I wonder if the right thing to do wouldn't be to implement the same check both in __init__ and in __new__. Am I makign sense? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-19 01:56 Message: Logged In: YES user_id=849994 Originator: NO I don't really understand either why object_new() checks the arguments, not object_init(): """ static int object_init(PyObject *self, PyObject *args, PyObject *kwds) { return 0; } /* If we don't have a tp_new for a new-style class, new will use this one. Therefore this should take no arguments/keywords. However, this new may also be inherited by objects that define a tp_init but no tp_new. These objects WILL pass argumets to tp_new, because it gets the same args as tp_init. So only allow arguments if we aren't using the default init, in which case we expect init to handle argument parsing. */ static PyObject * object_new(PyTypeObject *type, PyObject *args, PyObject *kwds) { if (type->tp_init == object_init && (PyTuple_GET_SIZE(args) || (kwds && PyDict_Check(kwds) && PyDict_Size(kwds)))) { PyErr_SetString(PyExc_TypeError, "default __new__ takes no parameters"); return NULL; } return type->tp_alloc(type, 0); } """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 From noreply at sourceforge.net Tue Mar 20 03:43:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 19:43:23 -0700 Subject: [ python-Bugs-1682241 ] Problems with urllib2 read() Message-ID: Bugs item #1682241, was opened at 2007-03-16 12:00 Message generated for change (Comment added) made by maenpaa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682241&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lucas Malor (lucas_malor) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with urllib2 read() Initial Comment: urllib2 objects opened with urlopen() does not have the method seek() as file objects. So reading only some bytes from opened urls is pratically forbidden. An example: I tried to open an url and check if it's a gzip file. If IOError is raised I read the file (to do this I applied the #1675951 patch: https://sourceforge.net/tracker/index.php?func=detail&aid=1675951&group_id=5470&atid=305470 ) But after I tried to open the file as gzip, if it's not a gzip file the current position in the urllib object is on the second byte. So read() returns the data from the 3rd to the last byte. You can't check the header of the file before storing it on hd. Well, so what is urlopen() for? If I must store the file by url on hd and reload it, I can use urlretrieve() ... ---------------------------------------------------------------------- Comment By: Zacherates (maenpaa) Date: 2007-03-19 22:43 Message: Logged In: YES user_id=1421845 Originator: NO I'd contend that this is not a bug: * If you need to seek, you can wrap the file-like object in a StringIO (which is what urllib would have to do internally, thus incurring the StringIO overhead for all clients, even those that don't need the functionality). * You can check the type of the response content before you try to uncompress it via the Content-Encoding header of the response. The meta-data is there for a reason. Check http://www.diveintopython.org/http_web_services/gzip_compression.html for a rather complete treatment of your use-case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682241&group_id=5470 From noreply at sourceforge.net Tue Mar 20 07:32:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 23:32:29 -0700 Subject: [ python-Feature Requests-967161 ] pty.spawn() enhancements Message-ID: Feature Requests item #967161, was opened at 2004-06-06 00:29 Message generated for change (Comment added) made by jhenstridge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=967161&group_id=5470 Please note that this 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 Private: No Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: pty.spawn() enhancements Initial Comment: (Originally suggested by James Henstridge in bug #897935) There are also a few changes that would be nice to see in pty.spawn: 1) get the exit status of the child. Could be fixed by adding the following to the end of the function: pid, status = os.waitpid(pid, 0) return status 2) set master_fd to non-blocking mode, so that the output is printed to the screen at the speed it is produced by the child. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2007-03-20 15:32 Message: Logged In: YES user_id=146903 Originator: NO #2 was an old misunderstanding by me about file.read() vs. os.read() w.r.t pipes, so is not needed. As for returning the status code vs the pid, it looks like spawn() is designed to return only when it can't read/write to the subprocess. You could return the pid at this point, but the process has most likely finished running at this point so the only thing you'd be likely to do is call waitpid() on it (and it is necessary to call waitpid() for the child process to be cleaned up properly). That's why I suggested that pty.spawn() get the child status itself. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-16 15:08 Message: Logged In: YES user_id=33168 Originator: NO Wouldn't it be better to just return the pid. The caller can get the status if they want or do anything else with the pid. I'm guessing #2 is no longer requested? ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2004-06-09 22:16 Message: Logged In: YES user_id=146903 Since filing the original bug report, I got reports that simply setting the fds to non-blocking caused problems under Solaris. Some details are available in this bug report: http://bugzilla.gnome.org/show_bug.cgi?id=139168 The _copy() function never raised an IOError or OSError, so it never exited. I'd imagine that EOF could be detected by getting back then empty string when reading from the fd when select() says it is ready for reading, but I haven't checked whether this works. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=967161&group_id=5470 From noreply at sourceforge.net Tue Mar 20 09:07:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 01:07:05 -0700 Subject: [ python-Bugs-1681762 ] too long string causes segmentation fault Message-ID: Bugs item #1681762, was opened at 2007-03-15 23:12 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681762&group_id=5470 Please note that this 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 Private: No Submitted By: L (llukas11) Assigned to: Martin v. L?wis (loewis) Summary: too long string causes segmentation fault Initial Comment: consider running this on machine with 16GB of ram: line = "x" for i in range(40): line = line + line print len(line) and it's output: 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 65536 131072 262144 524288 1048576 2097152 4194304 8388608 16777216 33554432 67108864 134217728 268435456 536870912 1073741824 -2147483648 Segmentation fault [lligo at kwaw-b1 0.1.x]$ python Python 2.4.4 (#1, Oct 23 2006, 13:58:18) [GCC 4.1.1 20061011 (Red Hat 4.1.1-30)] on linux2 I'll can try to chceck if it fails with python 2.5 but I need to compile one. I have stumlbed on this bug when reading line by line 3GB file and forgetting to clear string after I processed data. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-16 11:17 Message: Logged In: YES user_id=1326842 Originator: NO This looks like a duplicate of bug #1526585: http://www.python.org/sf/1526585 That bug was fixed in Python 2.5, but it didn't get backported to the 2.4 branch (string_concatenate() in ceval.c is still missing an overflow check). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 08:30 Message: Logged In: YES user_id=849994 Originator: NO Martin, do you think the Py_ssize_t changes prevent this in Py2.5? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681762&group_id=5470 From noreply at sourceforge.net Tue Mar 20 09:59:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 01:59:48 -0700 Subject: [ python-Bugs-1682241 ] Problems with urllib2 read() Message-ID: Bugs item #1682241, was opened at 2007-03-16 17:00 Message generated for change (Comment added) made by lucas_malor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682241&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lucas Malor (lucas_malor) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with urllib2 read() Initial Comment: urllib2 objects opened with urlopen() does not have the method seek() as file objects. So reading only some bytes from opened urls is pratically forbidden. An example: I tried to open an url and check if it's a gzip file. If IOError is raised I read the file (to do this I applied the #1675951 patch: https://sourceforge.net/tracker/index.php?func=detail&aid=1675951&group_id=5470&atid=305470 ) But after I tried to open the file as gzip, if it's not a gzip file the current position in the urllib object is on the second byte. So read() returns the data from the 3rd to the last byte. You can't check the header of the file before storing it on hd. Well, so what is urlopen() for? If I must store the file by url on hd and reload it, I can use urlretrieve() ... ---------------------------------------------------------------------- >Comment By: Lucas Malor (lucas_malor) Date: 2007-03-20 09:59 Message: Logged In: YES user_id=1403274 Originator: YES > If you need to seek, you can wrap the file-like object in a > StringIO (which is what urllib would have to do internally > [...] ) I think it's really a bug, or at least a non-pythonic method. I use the method you wrote, but this must be done manually, and I don't know why. Actually without this "trick" you can't handle url and file objects together as they don't work in the same manner. I think it's not too complicated using the internal StringIO object in urllib class when I must seek() or use other file-like methods. > You can check the type of the response content before you try > to uncompress it via the Content-Encoding header of the > response It's not a generic solution (thanks anyway for suggested solutions :) ) ---------------------------------------------------------------------- Comment By: Zacherates (maenpaa) Date: 2007-03-20 03:43 Message: Logged In: YES user_id=1421845 Originator: NO I'd contend that this is not a bug: * If you need to seek, you can wrap the file-like object in a StringIO (which is what urllib would have to do internally, thus incurring the StringIO overhead for all clients, even those that don't need the functionality). * You can check the type of the response content before you try to uncompress it via the Content-Encoding header of the response. The meta-data is there for a reason. Check http://www.diveintopython.org/http_web_services/gzip_compression.html for a rather complete treatment of your use-case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682241&group_id=5470 From noreply at sourceforge.net Tue Mar 20 12:09:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 04:09:15 -0700 Subject: [ python-Bugs-1684254 ] regression in webbrowser command line parsing Message-ID: Bugs item #1684254, was opened at 2007-03-20 12:09 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=1684254&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lukas Lalinsky (luks) Assigned to: Nobody/Anonymous (nobody) Summary: regression in webbrowser command line parsing Initial Comment: With Python 2.4 it was common to use BROWSER environment variables like: BROWSER="firefox '%s' &" to launch a browser. The apostrophes around %s are required to escape special characters in the URL (because the command is launched using os.system, which uses a shell), and & at the end is required to not block GUI applications. However, in Python 2.5 it uses the subprocess module, and the example above doesn't work. It tries to open `firefox 'URL' &` literally, which causes Firefox to open URIs like file:///path/to/current/directory/'URL'. Attached a patch that fixes the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684254&group_id=5470 From noreply at sourceforge.net Tue Mar 20 18:59:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 10:59:36 -0700 Subject: [ python-Feature Requests-1684603 ] Add tail recursion Message-ID: Feature Requests item #1684603, was opened at 2007-03-20 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=355470&aid=1684603&group_id=5470 Please note that this 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 Private: No Submitted By: Tommy Nordgren (unclezeb) Assigned to: Nobody/Anonymous (nobody) Summary: Add tail recursion Initial Comment: Consider the following code: def fac(m): def iter(acc,n): if n <= 0 : return acc else: return iter(acc * n, n - 1) return iter(1,m) #When called wtih a large parameter, you get exceed the recursion limit fac(10000) In a future release, I suggest updating the interpreter and byte code compiler to handle tail recursion properly as in scheme. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1684603&group_id=5470 From noreply at sourceforge.net Tue Mar 20 20:05:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 12:05:09 -0700 Subject: [ python-Feature Requests-1684603 ] Add tail recursion Message-ID: Feature Requests item #1684603, was opened at 2007-03-20 12:59 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1684603&group_id=5470 Please note that this 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.6 >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Tommy Nordgren (unclezeb) Assigned to: Nobody/Anonymous (nobody) Summary: Add tail recursion Initial Comment: Consider the following code: def fac(m): def iter(acc,n): if n <= 0 : return acc else: return iter(acc * n, n - 1) return iter(1,m) #When called wtih a large parameter, you get exceed the recursion limit fac(10000) In a future release, I suggest updating the interpreter and byte code compiler to handle tail recursion properly as in scheme. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-03-20 14:05 Message: Logged In: YES user_id=80475 Originator: NO This sort of optimization is one of the many that aren't possible without changing the semantics of the language. Recursive calls use a LOAD_GLOBAL in the function to reference itself. The value of that global is subject to change outside the body of the function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1684603&group_id=5470 From noreply at sourceforge.net Tue Mar 20 20:08:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 12:08:04 -0700 Subject: [ python-Feature Requests-1656538 ] dict(key,values) initializer Message-ID: Feature Requests item #1656538, was opened at 2007-02-09 21:05 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1656538&group_id=5470 Please note that this 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.6 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: George Sakkis (gsakkis) Assigned to: Nobody/Anonymous (nobody) Summary: dict(key,values) initializer Initial Comment: Far too often I use the idiom dict(zip(keys,values)), or the same with izip. How does letting dict take two positional arguments sound ? Pros: - Pretty obvious semantics, no mental overhead to learn and remember it. - More concise (especially if one imports itertools just to use izip). - At least as efficient (and probably more) as the current alternatives. - Backwards compatible. George ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-03-20 14:08 Message: Logged In: YES user_id=80475 Originator: NO Sorry, the number of options for the dict constructor is already at its outer limit. No need to further complicate the situation in order to save just five or six characters in the invocation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1656538&group_id=5470 From noreply at sourceforge.net Tue Mar 20 21:54:35 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 13:54:35 -0700 Subject: [ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds Message-ID: Bugs item #1683368, was opened at 2007-03-18 23:32 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Guido van Rossum (gvanrossum) Summary: object.__init__ shouldn't allow args/kwds Initial Comment: object.__init__ currently allows any amount of args and keywords even though they're ignored. This is inconsistent with other built-ins, like list, that are stricter about what they'll accept. It's also inconsistent with object.__new__, which does throw if any are provided (if the default __init__ is to be used). To reproduce: object.__init__(object(), foo, bar=3) This is a slight irritation when using cooperative super calling. I'd like each class' __init__ to cherry-pick keyword params it accepts and pass the remaining ones up the chain, but right now I can't rely on object.__init__ to throw if there are remaining keywords by that point. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-20 16:54 Message: Logged In: YES user_id=6380 Originator: NO Here's a stricter version. Unfortunately it breaks a couple of standard modules; this is a confirmation of my doubts whether the style of cooperative super calling of __init__ that you use is really the most common or "best practice". So far I have only fixed string.py (which would otherwise prevent extensions from being built); I haven't looked into why the other tests fail: test_array, test_cpickle, test_descr, test_pickle (and maybe more?). My conclusion: this would probably break too much code to be worth it. So I'll have to revert to the previous version. But anyway, here it is for your perusal. File Added: new_init_strict.patch ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-19 21:27 Message: Logged In: YES user_id=1747060 Originator: YES I think making the check more rigid is a good idea, since this should throw: class a(object): def __init__(self, foo): super(a, self).__init__(foo) def __new__(cls, foo): return object.__new__(cls) a(1) (minor typo in the patch: "solution it" -> "solution is") ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 19:35 Message: Logged In: YES user_id=6380 Originator: NO This smells enough like a new feature that it couldn't go into 2.5. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 19:31 Message: Logged In: YES user_id=6380 Originator: NO Attached is a patch that implements this proposal, adding copious commentary. It doesn't seem to break anything in the test suite. I wonder if we should even make the check more rigid: check the argument list if either the current method *is* overridden or the other one *is not* overridden. This would make super calls check the arguments even if the other method is overridden. What do you think? File Added: new_init.patch ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-19 18:45 Message: Logged In: YES user_id=1747060 Originator: YES Makes sense. I don't think we can ever be completely correct here since we're inferring intent from the presence of __init__/__new__ that's liable to be wrong in some cases, but it's likely correct often enough that it's worth doing. If I understand correctly, we want to be more forgiving iff one of the two methods is used, so it seems like we should be complaining if both are used *or* if neither is used. After all, I could add a __new__ to my coop use case and I'd still want object to complain. If that's the case, both object_new and object_init should be complaining if ((tp->tp_new == object_new && tp->tp_init == object_init) || (tp->tp_new != object_new && tp->tp_init != object_init)). Of course, for the paranoid, there's always the risk that __new__ will modify these class functions and change the outcome :) For instance, if a class had a __new__ and no __init__ and its __new__ changed __new__ back to object.__new__, object_init on that run would be fooled into thinking it's using the defaults for both and would complain. I think this could only be fixed in type_call, which is rather ugly...but then, this *is* a special case of the "call __init__ after __new__" behavior, and we're trying to solve it within the methods themselves. Perhaps this last point is academic enough to be ignored...I don't know why anyone would do this, although the language makes it possible. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 16:01 Message: Logged In: YES user_id=6380 Originator: NO I'll try to explain why I did it this way. I was considering the single inheritance case implementing an Immutable object, which overrides __new__ but has no need to override __init__ (since it's too late to do anything in __init__ for an Immutable object). Since the __init__ still gets called it would be annoying to have to override it just to make the error go away if there was a check in __init__. The other case is overriding __init__ without overriding __new__, which is the most common way of doing Mutable objects; here you wouldn't want __new__ to complain about extra args. So the only time when you'd want complaints is if both __new__ and __init__ are the defaults, in which case it doesn't really matter whether you implement this in __init__ or in __new__, so I arbitrarily chose __new__. I wasn't thinking of your use case at the time though (cooperative super calls to __init__, which still isn't something I engage in on a day-to-day basis). I wonder if the right thing to do wouldn't be to implement the same check both in __init__ and in __new__. Am I makign sense? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-19 04:56 Message: Logged In: YES user_id=849994 Originator: NO I don't really understand either why object_new() checks the arguments, not object_init(): """ static int object_init(PyObject *self, PyObject *args, PyObject *kwds) { return 0; } /* If we don't have a tp_new for a new-style class, new will use this one. Therefore this should take no arguments/keywords. However, this new may also be inherited by objects that define a tp_init but no tp_new. These objects WILL pass argumets to tp_new, because it gets the same args as tp_init. So only allow arguments if we aren't using the default init, in which case we expect init to handle argument parsing. */ static PyObject * object_new(PyTypeObject *type, PyObject *args, PyObject *kwds) { if (type->tp_init == object_init && (PyTuple_GET_SIZE(args) || (kwds && PyDict_Check(kwds) && PyDict_Size(kwds)))) { PyErr_SetString(PyExc_TypeError, "default __new__ takes no parameters"); return NULL; } return type->tp_alloc(type, 0); } """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 From noreply at sourceforge.net Tue Mar 20 22:24:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 14:24:34 -0700 Subject: [ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds Message-ID: Bugs item #1683368, was opened at 2007-03-18 23:32 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Guido van Rossum (gvanrossum) Summary: object.__init__ shouldn't allow args/kwds Initial Comment: object.__init__ currently allows any amount of args and keywords even though they're ignored. This is inconsistent with other built-ins, like list, that are stricter about what they'll accept. It's also inconsistent with object.__new__, which does throw if any are provided (if the default __init__ is to be used). To reproduce: object.__init__(object(), foo, bar=3) This is a slight irritation when using cooperative super calling. I'd like each class' __init__ to cherry-pick keyword params it accepts and pass the remaining ones up the chain, but right now I can't rely on object.__init__ to throw if there are remaining keywords by that point. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-20 17:24 Message: Logged In: YES user_id=6380 Originator: NO I should mention that if we can't get the strict version of this in 2.6, we should be able to get it into 3.0. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-20 16:54 Message: Logged In: YES user_id=6380 Originator: NO Here's a stricter version. Unfortunately it breaks a couple of standard modules; this is a confirmation of my doubts whether the style of cooperative super calling of __init__ that you use is really the most common or "best practice". So far I have only fixed string.py (which would otherwise prevent extensions from being built); I haven't looked into why the other tests fail: test_array, test_cpickle, test_descr, test_pickle (and maybe more?). My conclusion: this would probably break too much code to be worth it. So I'll have to revert to the previous version. But anyway, here it is for your perusal. File Added: new_init_strict.patch ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-19 21:27 Message: Logged In: YES user_id=1747060 Originator: YES I think making the check more rigid is a good idea, since this should throw: class a(object): def __init__(self, foo): super(a, self).__init__(foo) def __new__(cls, foo): return object.__new__(cls) a(1) (minor typo in the patch: "solution it" -> "solution is") ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 19:35 Message: Logged In: YES user_id=6380 Originator: NO This smells enough like a new feature that it couldn't go into 2.5. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 19:31 Message: Logged In: YES user_id=6380 Originator: NO Attached is a patch that implements this proposal, adding copious commentary. It doesn't seem to break anything in the test suite. I wonder if we should even make the check more rigid: check the argument list if either the current method *is* overridden or the other one *is not* overridden. This would make super calls check the arguments even if the other method is overridden. What do you think? File Added: new_init.patch ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-19 18:45 Message: Logged In: YES user_id=1747060 Originator: YES Makes sense. I don't think we can ever be completely correct here since we're inferring intent from the presence of __init__/__new__ that's liable to be wrong in some cases, but it's likely correct often enough that it's worth doing. If I understand correctly, we want to be more forgiving iff one of the two methods is used, so it seems like we should be complaining if both are used *or* if neither is used. After all, I could add a __new__ to my coop use case and I'd still want object to complain. If that's the case, both object_new and object_init should be complaining if ((tp->tp_new == object_new && tp->tp_init == object_init) || (tp->tp_new != object_new && tp->tp_init != object_init)). Of course, for the paranoid, there's always the risk that __new__ will modify these class functions and change the outcome :) For instance, if a class had a __new__ and no __init__ and its __new__ changed __new__ back to object.__new__, object_init on that run would be fooled into thinking it's using the defaults for both and would complain. I think this could only be fixed in type_call, which is rather ugly...but then, this *is* a special case of the "call __init__ after __new__" behavior, and we're trying to solve it within the methods themselves. Perhaps this last point is academic enough to be ignored...I don't know why anyone would do this, although the language makes it possible. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 16:01 Message: Logged In: YES user_id=6380 Originator: NO I'll try to explain why I did it this way. I was considering the single inheritance case implementing an Immutable object, which overrides __new__ but has no need to override __init__ (since it's too late to do anything in __init__ for an Immutable object). Since the __init__ still gets called it would be annoying to have to override it just to make the error go away if there was a check in __init__. The other case is overriding __init__ without overriding __new__, which is the most common way of doing Mutable objects; here you wouldn't want __new__ to complain about extra args. So the only time when you'd want complaints is if both __new__ and __init__ are the defaults, in which case it doesn't really matter whether you implement this in __init__ or in __new__, so I arbitrarily chose __new__. I wasn't thinking of your use case at the time though (cooperative super calls to __init__, which still isn't something I engage in on a day-to-day basis). I wonder if the right thing to do wouldn't be to implement the same check both in __init__ and in __new__. Am I makign sense? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-19 04:56 Message: Logged In: YES user_id=849994 Originator: NO I don't really understand either why object_new() checks the arguments, not object_init(): """ static int object_init(PyObject *self, PyObject *args, PyObject *kwds) { return 0; } /* If we don't have a tp_new for a new-style class, new will use this one. Therefore this should take no arguments/keywords. However, this new may also be inherited by objects that define a tp_init but no tp_new. These objects WILL pass argumets to tp_new, because it gets the same args as tp_init. So only allow arguments if we aren't using the default init, in which case we expect init to handle argument parsing. */ static PyObject * object_new(PyTypeObject *type, PyObject *args, PyObject *kwds) { if (type->tp_init == object_init && (PyTuple_GET_SIZE(args) || (kwds && PyDict_Check(kwds) && PyDict_Size(kwds)))) { PyErr_SetString(PyExc_TypeError, "default __new__ takes no parameters"); return NULL; } return type->tp_alloc(type, 0); } """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 From noreply at sourceforge.net Tue Mar 20 23:05:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 15:05:22 -0700 Subject: [ python-Bugs-471432 ] __cdecl / __stdcall unspecified in *.h Message-ID: Bugs item #471432, was opened at 2001-10-15 12:18 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=471432&group_id=5470 Please note that this 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: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Frederic Giacometti (giacometti) Assigned to: Mark Hammond (mhammond) Summary: __cdecl / __stdcall unspecified in *.h Initial Comment: Currently, the win32 function call convention (__stdcall vs __cdecl) is never specified in the function prototypes contained in the .h header files. The call convention is therefore left up to the configuration of the compiler incluing the header files (__cdecl by default on VC++). However, there are situations in which the compiler default call convention must be set to __stdcall (/Gz option on VC++'s cl.exe), and this makes the link fail; until __cdecl keywords are manually insterted in the Python.h function prototypes required for linking. [For instance, /Gz is required when using typedef definitions on function pointers, later passed as arguments on __stdcall functions (the default on Microsoft/commercial libraries)]. Besides, Microsoft recommands, it the VC++ documentation, that the __stdcall convention be used by default for function with fixed numbers of arguments (smaller code size and better performances); __cdecl being limited for use with functions with variable number of args ('...'). A solution would consist in defining: #ifdef _MS_VER #define FIXARGCALL __stdcall #define VARARGCALL __cdecl #else ... #endif and sticking FIXARGCALL / VARARGCALL in front of all DLL_IMPORT(), macro calls associated to a an exported function prototype, across all Python .h files. Frederic Giacometti ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2007-03-20 15:05 Message: Logged In: YES user_id=357491 Originator: NO This is a rather old bug. =) If no one cares to fix this then it should be closed. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-10-16 10:19 Message: Logged In: YES user_id=93657 The fault is not in the other libraries. In MS Windows, 'well-behaved' libraries define explicitely the calling conventions for each function in their header file. This is all. There's nobody's guts loosely hanging out in this ;). FG ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-15 20:00 Message: Logged In: YES user_id=31435 I guess my first question is, if library X needs something other than the default, why isn't it X's responsibility to force *their* non-default behavior where needed? After all, they're the oddballs. Some days I get real tired of cleaing up after everyone else's loose bowels <0.9 wink>. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2001-10-15 18:45 Message: Logged In: YES user_id=14198 This does make sense to me, and I have even been bitten by it. There are some strange libraries out there that need to be compiled with a different calling convention than the default. Trying to extend Python with such a library can be difficult. Having the calling convention specified in the prototypes would solve the problem. I have never been brave enough to do it, given the small number of times it has been reported as a problem. However, I would be happy to help come up with a reasonable scheme. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-10-15 12:46 Message: Logged In: YES user_id=93657 As far as MS Windows / dll stuff is concerned, you're already swimming in non-C-ANSI fishtank anyway (e.g. DLL_IMPORT() macros...). Just try to keep the right fishes in the tank :)) FG ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-15 12:34 Message: Logged In: YES user_id=31435 Mark, does this make sense to you? Any notion that we *have* to add non-standard decorations seems inherently fishy to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=471432&group_id=5470 From noreply at sourceforge.net Wed Mar 21 00:14:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 16:14:08 -0700 Subject: [ python-Bugs-1684811 ] modindex.html builds incorrectly in Python 3 Message-ID: Bugs item #1684811, was opened at 2007-03-20 19:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684811&group_id=5470 Please note that this 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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: modindex.html builds incorrectly in Python 3 Initial Comment: Running "make distclean; make" in Python 3's Doc/ directory (as of r54467) leaves me with a content-less modindex.html. The header and footer are present, but there's no list of modules. The same steps on trunk/ (SVN HEAD) produce the expected module list. The mkmodindex step reports "0 index nodes". Watching the lines that mkmodindex:main() parses, none of them are related to modules (in the correct format or otherwise). I've attached a copy of the bad modindex.html that "make" generated. Also attached is a patch that allows Doc/tools/ to work with Python 3 (which it doesn't as of r54467). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684811&group_id=5470 From noreply at sourceforge.net Wed Mar 21 00:15:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 16:15:45 -0700 Subject: [ python-Bugs-1684811 ] modindex.html builds incorrectly in Python 3 Message-ID: Bugs item #1684811, was opened at 2007-03-20 19:14 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684811&group_id=5470 Please note that this 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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: modindex.html builds incorrectly in Python 3 Initial Comment: Running "make distclean; make" in Python 3's Doc/ directory (as of r54467) leaves me with a content-less modindex.html. The header and footer are present, but there's no list of modules. The same steps on trunk/ (SVN HEAD) produce the expected module list. The mkmodindex step reports "0 index nodes". Watching the lines that mkmodindex:main() parses, none of them are related to modules (in the correct format or otherwise). I've attached a copy of the bad modindex.html that "make" generated. Also attached is a patch that allows Doc/tools/ to work with Python 3 (which it doesn't as of r54467). ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-20 19:15 Message: Logged In: YES user_id=1344176 Originator: YES File Added: doc_tools.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684811&group_id=5470 From noreply at sourceforge.net Wed Mar 21 01:21:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 17:21:44 -0700 Subject: [ python-Bugs-578180 ] Explain how to subclass Exception Message-ID: Bugs item #578180, was opened at 2002-07-06 11:58 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=578180&group_id=5470 Please note that this 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: Out of Date Priority: 5 Private: No Submitted By: Jeremy Hylton (jhylton) Assigned to: Jeremy Hylton (jhylton) Summary: Explain how to subclass Exception Initial Comment: The contract of subclasses wrt __init__() and self.args is undocumented. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2007-03-20 17:21 Message: Logged In: YES user_id=357491 Originator: NO The docs for the 'exception' module covers this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=578180&group_id=5470 From noreply at sourceforge.net Wed Mar 21 01:23:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 17:23:34 -0700 Subject: [ python-Bugs-546196 ] extend namespace docs to cover LOAD_NAME Message-ID: Bugs item #546196, was opened at 2002-04-19 09:40 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=546196&group_id=5470 Please note that this 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: Out of Date Priority: 5 Private: No Submitted By: Jeremy Hylton (jhylton) Assigned to: Jeremy Hylton (jhylton) Summary: extend namespace docs to cover LOAD_NAME Initial Comment: Assuming that Python continues to use LOAD_NAME, then the reference manual ought to describe this strange beast. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2007-03-20 17:23 Message: Logged In: YES user_id=357491 Originator: NO 'dis' modules bytecode docs covers LOAD_NAME. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=546196&group_id=5470 From noreply at sourceforge.net Wed Mar 21 01:24:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 17:24:59 -0700 Subject: [ python-Bugs-586680 ] -S hides standard dynamic modules Message-ID: Bugs item #586680, was opened at 2002-07-25 12:59 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=586680&group_id=5470 Please note that this 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: Platform-specific >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Nobody/Anonymous (nobody) Summary: -S hides standard dynamic modules Initial Comment: This only applies when os.name == 'posix'. Running an un-installed build of Python with the -S option causes the directory containing the standard dynamically-built modules not to be placed on sys.path. The build/lib.<platform>-<version>/ directory containing those modules is added to sys.path by site.py rather than getpath.c, even though those modules are needed. This includes many modules on most Unix systems: array dbm math regex termios audioop dl md5 resource _testcapi binascii errno mmap rgbimg time bsddb fcntl mpz rotor timing cmath fpectl nis select _tkinter _codecs gdbm operator sha unicodedata cPickle grp parser _socket _weakref crypt _hotshot pcre _ssl xreadlines cStringIO _hotshot pwd strop zlib _curses_panel linuxaudiodev pyexpat struct _curses _locale readline syslog Perhaps the best way to fix this is to add the equivalent code to getpath.c. The relevant stanza in site.py is headed by a comment saying "especially for Guido". ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2007-03-20 17:24 Message: Logged In: YES user_id=357491 Originator: NO We have lived this long without changing this that I don't think this needs fixing. Requiring the use of site.py when running from a build from a repository checkout seems totally reasonable to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=586680&group_id=5470 From noreply at sourceforge.net Wed Mar 21 01:26:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 17:26:45 -0700 Subject: [ python-Bugs-587011 ] IBCarbon module Message-ID: Bugs item #587011, was opened at 2002-07-26 06:41 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=587011&group_id=5470 Please note that this 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: Feature Request >Status: Closed >Resolution: Out of Date Priority: 3 Private: No Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: IBCarbon module Initial Comment: Donovan Preston donated an IBCarbon module, that allows Interface Builder (in Carbon mode) to be used for creating GUIs for Python scripts. This module should be incorporated in the Carbon package. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2007-03-20 17:26 Message: Logged In: YES user_id=357491 Originator: NO The coercion didn't work. =) Plus no IBCarbon module is even listed in the module index. Closing as "out of date". ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-08-05 15:10 Message: Logged In: YES user_id=45365 It is included now. I'm keeping this open because I want to coerce someone to provide an example of its use. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=587011&group_id=5470 From noreply at sourceforge.net Wed Mar 21 01:44:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 17:44:26 -0700 Subject: [ python-Bugs-1569057 ] Using .next() on file open in write mode writes junk to file Message-ID: Bugs item #1569057, was opened at 2006-10-01 21:49 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569057&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: andrei kulakov (rainy) >Assigned to: Brett Cannon (bcannon) Summary: Using .next() on file open in write mode writes junk to file Initial Comment: When you open a file in write mode and use .next(), it prints an error and writes many lines of junk to file. I tested on windows and python 2.5: >>> f = open('test', 'w') >>> f.fileno() 4 >>> f.write('1\n') >>> f.write('2\n3\n4\n') >>> f.next() Traceback (most recent call last): File "", line 1, in f.next() IOError: [Errno 9] Bad file descriptor >>> f.close() >>> f = open('test') >>> f.next() '1\n' >>> f.next() '2\n' >>> f.next() '3\n' >>> f.next() '4\n' >>> f.next() '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x 00\x00\x00\x00\x00\x? 00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00\x00\x00\x00\? x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00\x00 ...many more lines of junk...' ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2007-03-20 17:44 Message: Logged In: YES user_id=357491 Originator: NO I think the docs should just say switching is undefined and leave it at that. Calling 'next' on a file open for writing just makes no sense anyway. And who knows what the OS will do if you try to misuse a file descriptor. Other option is to raise an exception when 'next' is called on a file opened for writing (TypeError?). I think that makes more sense. Unfortunately having to check the mode every time you call 'next' might be considered unacceptable. Anyone have an opinion? Either way I will go with one of the two solutions. ---------------------------------------------------------------------- Comment By: andrei kulakov (rainy) Date: 2006-10-07 09:04 Message: Logged In: YES user_id=511010 I tried it on win2k sp4 running python 2.5 and right now tried it on winXP running python 2.4 - same error. Also, at least one user on python newsgroup tried it and got a slightly different result: he did not get the error on .next() but the junk was written to the file. I paste my latest attempt right out of IDLE, without any modification (my first paste was also straight from idle). Except that I trim the junk characters, because there's more than a screen of 'em. IDLE 1.1.2 >>> f = open('test', 'w') >>> f.write('1\n') >>> f.next() Traceback (most recent call last): File "", line 1, in -toplevel- f.next() IOError: [Errno 9] Bad file descriptor >>> f.close() >>> f = open('test') >>> f.next() '1\n' >>> f.next() "\x95\x00\xc8\xe ......." Please let me know if you need to know anything else... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-10-07 03:38 Message: Logged In: YES user_id=44345 Works for me. (Nearly current build from SVN.) I find it implausible that your explanation of failing to flush the file is the cause of the problem since closing the file will cause it to be flushed. You didn't open the file for "w+" so there's no opportunity to switch between writing and reading. What platform are you using? ---------------------------------------------------------------------- Comment By: andrei kulakov (rainy) Date: 2006-10-03 18:23 Message: Logged In: YES user_id=511010 Python newsgroup folks said that this is normal because when switching between write/read modes without doing flush() first, result is undefined. There was a suggestion from Terry Ready to add this to documentation on file methods: "When switching from reading or writing (or vice versa), call flush(), or the result will be undefined." thx, -andrei ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569057&group_id=5470 From noreply at sourceforge.net Wed Mar 21 02:39:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 18:39:53 -0700 Subject: [ python-Bugs-1682241 ] Problems with urllib2 read() Message-ID: Bugs item #1682241, was opened at 2007-03-16 12:00 Message generated for change (Comment added) made by maenpaa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682241&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lucas Malor (lucas_malor) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with urllib2 read() Initial Comment: urllib2 objects opened with urlopen() does not have the method seek() as file objects. So reading only some bytes from opened urls is pratically forbidden. An example: I tried to open an url and check if it's a gzip file. If IOError is raised I read the file (to do this I applied the #1675951 patch: https://sourceforge.net/tracker/index.php?func=detail&aid=1675951&group_id=5470&atid=305470 ) But after I tried to open the file as gzip, if it's not a gzip file the current position in the urllib object is on the second byte. So read() returns the data from the 3rd to the last byte. You can't check the header of the file before storing it on hd. Well, so what is urlopen() for? If I must store the file by url on hd and reload it, I can use urlretrieve() ... ---------------------------------------------------------------------- Comment By: Zacherates (maenpaa) Date: 2007-03-20 21:39 Message: Logged In: YES user_id=1421845 Originator: NO > I use the method you wrote, but this must be done manually, > and I don't know why. read() is a stream processing method, whereas seek() is a random access processing method. HTTP resources are in essence streams so they implement read() but not seek(). Trying to shoehorn a stream to act like a random access file has some rather important technical implications. For example: what happens when an HTTP resource is larger than available memory and we try to maintain a full featured seek() implementation? > so what is urlopen() for? Fetching a webpage or RSS feed and feeding it to a parser, for example. StringIO is a class that was designed to implement feature complete, random access, file-like object behavior that can be wrapped around a stream. StringIO can and should be used as an adapter for when you have a stream that you need random access to. This allows designers the freedom to simply implement a good read() implementation and let clients wrap the output in a StringIO if needed. If in your application you always want random access and you don't have to deal with large files: def my_urlopen(*args, **kwargs): return StringIO.StringIO(urllib2.urlopen(*args, **kwargs).read()) Python makes delegation trivially easy. In essence, urlfiles (the result of urllib2.urlopen()) and regular files (the result of open()) behave differently because they implement different interfaces. If you use the common interface (read), then you can treat them equally. If you use the specialized interface (seek, tell, etc.) you'll have trouble. The solution is wrap the general objects in a specialized object that implements the desired interface, StringIO. ---------------------------------------------------------------------- Comment By: Lucas Malor (lucas_malor) Date: 2007-03-20 04:59 Message: Logged In: YES user_id=1403274 Originator: YES > If you need to seek, you can wrap the file-like object in a > StringIO (which is what urllib would have to do internally > [...] ) I think it's really a bug, or at least a non-pythonic method. I use the method you wrote, but this must be done manually, and I don't know why. Actually without this "trick" you can't handle url and file objects together as they don't work in the same manner. I think it's not too complicated using the internal StringIO object in urllib class when I must seek() or use other file-like methods. > You can check the type of the response content before you try > to uncompress it via the Content-Encoding header of the > response It's not a generic solution (thanks anyway for suggested solutions :) ) ---------------------------------------------------------------------- Comment By: Zacherates (maenpaa) Date: 2007-03-19 22:43 Message: Logged In: YES user_id=1421845 Originator: NO I'd contend that this is not a bug: * If you need to seek, you can wrap the file-like object in a StringIO (which is what urllib would have to do internally, thus incurring the StringIO overhead for all clients, even those that don't need the functionality). * You can check the type of the response content before you try to uncompress it via the Content-Encoding header of the response. The meta-data is there for a reason. Check http://www.diveintopython.org/http_web_services/gzip_compression.html for a rather complete treatment of your use-case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682241&group_id=5470 From noreply at sourceforge.net Wed Mar 21 03:00:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 19:00:43 -0700 Subject: [ python-Bugs-1684811 ] modindex.html builds incorrectly in Python 3 Message-ID: Bugs item #1684811, was opened at 2007-03-20 19:14 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684811&group_id=5470 Please note that this 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 3000 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: modindex.html builds incorrectly in Python 3 Initial Comment: Running "make distclean; make" in Python 3's Doc/ directory (as of r54467) leaves me with a content-less modindex.html. The header and footer are present, but there's no list of modules. The same steps on trunk/ (SVN HEAD) produce the expected module list. The mkmodindex step reports "0 index nodes". Watching the lines that mkmodindex:main() parses, none of them are related to modules (in the correct format or otherwise). I've attached a copy of the bad modindex.html that "make" generated. Also attached is a patch that allows Doc/tools/ to work with Python 3 (which it doesn't as of r54467). ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-20 22:00 Message: Logged In: YES user_id=1344176 Originator: YES I'm not sure what which change I've made in Doc/tools/ did it, but modindex.html now builds correctly after "make distclean". I'll check in the changes soon. Closing. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-20 19:15 Message: Logged In: YES user_id=1344176 Originator: YES File Added: doc_tools.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684811&group_id=5470 From noreply at sourceforge.net Wed Mar 21 07:50:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 23:50:18 -0700 Subject: [ python-Bugs-1684943 ] Keyword arguments to __init__() of a subclass of set Message-ID: Bugs item #1684943, was opened at 2007-03-21 07: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=1684943&group_id=5470 Please note that this 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 Private: No Submitted By: J?rgen Fr?jk Kj?rsgaard (jfroejk) Assigned to: Nobody/Anonymous (nobody) Summary: Keyword arguments to __init__() of a subclass of set Initial Comment: Passing a keyword argument to a subclass of the built-in class "set" causes a TypeError in Python 2.4.2 and newer but not in 2.4.0. Example: class Test(set): def __init__(self, a=0): self.add(a) t = Test(a=0) In Python 2.4.0 it works as expected whereas in 2.4.2 and 2.4.4, it yields: Traceback (most recent call last): File "", line 1, in ? TypeError: set() does not take keyword arguments I don't pass a keyword argument to set.__init__() but to its subclass! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684943&group_id=5470 From noreply at sourceforge.net Wed Mar 21 07:59:35 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 23:59:35 -0700 Subject: [ python-Bugs-1684943 ] Keyword arguments to __init__() of a subclass of set Message-ID: Bugs item #1684943, was opened at 2007-03-20 23:50 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684943&group_id=5470 Please note that this 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: Duplicate Priority: 5 Private: No Submitted By: J?rgen Fr?jk Kj?rsgaard (jfroejk) >Assigned to: Neal Norwitz (nnorwitz) Summary: Keyword arguments to __init__() of a subclass of set Initial Comment: Passing a keyword argument to a subclass of the built-in class "set" causes a TypeError in Python 2.4.2 and newer but not in 2.4.0. Example: class Test(set): def __init__(self, a=0): self.add(a) t = Test(a=0) In Python 2.4.0 it works as expected whereas in 2.4.2 and 2.4.4, it yields: Traceback (most recent call last): File "", line 1, in ? TypeError: set() does not take keyword arguments I don't pass a keyword argument to set.__init__() but to its subclass! ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-20 23:59 Message: Logged In: YES user_id=33168 Originator: NO 2.4 is no longer supported. This has been fixed in 2.5. I don't have the original bug report #. You can find the fix in SVN if you would like to build your own patched version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684943&group_id=5470 From noreply at sourceforge.net Wed Mar 21 08:02:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 00:02:20 -0700 Subject: [ python-Bugs-1682749 ] next method assignment is ignored in new-style classes Message-ID: Bugs item #1682749, was opened at 2007-03-17 08:06 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682749&group_id=5470 Please note that this 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.5 Status: Open Resolution: Invalid Priority: 5 Private: No Submitted By: Albert Weichselbraun (albert2611) Assigned to: Neal Norwitz (nnorwitz) Summary: next method assignment is ignored in new-style classes Initial Comment: in old-style classes the next method of an iterator-superclass can be "overwritten" using self.next = self.new_next_method when new-style classes are used the assignment is ignored and instead of new_next_method the next method of the superclass is called when the class is used as iterator (tested for python2.3-2.5 under debian/linux). - if the next() method is called directly, the assigned method is used (see attached code example). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-21 00:02 Message: Logged In: YES user_id=33168 Originator: NO Yup, based on mail thread this behaviour seems correct. Unfortunately, I don't think it's properly documented or consistent either. :-( ---------------------------------------------------------------------- Comment By: Albert Weichselbraun (albert2611) Date: 2007-03-17 09:27 Message: Logged In: YES user_id=806170 Originator: YES i only experienced this behavior for the next method in iterator classes. overwriting methods with other names using an assignment works as expected. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-17 08:52 Message: Logged In: YES user_id=849994 Originator: NO This is another incarnation of __methods__ being looked up on the type, not the instance, except that next() is not a __method__ yet. For new-style classes, this behavior is considered correct. Neal? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682749&group_id=5470 From noreply at sourceforge.net Wed Mar 21 09:53:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 01:53:45 -0700 Subject: [ python-Bugs-1684991 ] Explain __method__ lookup semantics for new-style classes Message-ID: Bugs item #1684991, was opened at 2007-03-21 08: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=1684991&group_id=5470 Please note that this 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 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: Explain __method__ lookup semantics for new-style classes Initial Comment: __method__s (and next) are looked up on the type, not the instance. This isn't documented properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684991&group_id=5470 From noreply at sourceforge.net Wed Mar 21 09:54:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 01:54:30 -0700 Subject: [ python-Bugs-1682749 ] next method assignment is ignored in new-style classes Message-ID: Bugs item #1682749, was opened at 2007-03-17 15:06 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682749&group_id=5470 Please note that this 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.5 >Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Albert Weichselbraun (albert2611) Assigned to: Neal Norwitz (nnorwitz) Summary: next method assignment is ignored in new-style classes Initial Comment: in old-style classes the next method of an iterator-superclass can be "overwritten" using self.next = self.new_next_method when new-style classes are used the assignment is ignored and instead of new_next_method the next method of the superclass is called when the class is used as iterator (tested for python2.3-2.5 under debian/linux). - if the next() method is called directly, the assigned method is used (see attached code example). ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-21 08:54 Message: Logged In: YES user_id=849994 Originator: NO Closing this then, I have opened a new bug (#1684991) for the documentation issue. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-21 07:02 Message: Logged In: YES user_id=33168 Originator: NO Yup, based on mail thread this behaviour seems correct. Unfortunately, I don't think it's properly documented or consistent either. :-( ---------------------------------------------------------------------- Comment By: Albert Weichselbraun (albert2611) Date: 2007-03-17 16:27 Message: Logged In: YES user_id=806170 Originator: YES i only experienced this behavior for the next method in iterator classes. overwriting methods with other names using an assignment works as expected. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-17 15:52 Message: Logged In: YES user_id=849994 Originator: NO This is another incarnation of __methods__ being looked up on the type, not the instance, except that next() is not a __method__ yet. For new-style classes, this behavior is considered correct. Neal? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682749&group_id=5470 From noreply at sourceforge.net Wed Mar 21 10:15:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 02:15:49 -0700 Subject: [ python-Bugs-1685000 ] DoS asyncore vulnerability Message-ID: Bugs item #1685000, was opened at 2007-03-21 10: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=1685000&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: billiejoex (billiejoex) Assigned to: Nobody/Anonymous (nobody) Summary: DoS asyncore vulnerability Initial Comment: DoS asyncore vulnerability asyncore, independently if used with select() or poll(), suffers a DoS-type vulnerability when a high number of simultaneous connections to handle simultaneously is reached. The number of maximum connections is system-dependent as well as the type of error raised. I attached two simple Proof of Concept scripts demonstrating such bug. If you want to try the behaviours listed below run the attached "asyncore_server.py" and "asyncore_client.py" scripts on your local workstation. On my Windows XP system (Python 2.5), independently if asyncore has been used to develop a server or a client, the error is raised by select() inside asyncore's "poll" function when 512 (socket_map's elements) simultaneous connections are reached. Here's the traceback I get: [...] connections: 510 connections: 511 connections: 512 Traceback (most recent call last): File "C:\scripts\asyncore_server.py", line 38, in asyncore.loop() File "C:\Python25\lib\asyncore.py", line 191, in loop poll_fun(timeout, map) File "C:\Python25\lib\asyncore.py", line 121, in poll r, w, e = select.select(r, w, e, timeout) ValueError: too many file descriptors in select() On my Linux Ubuntu 6.10 (kernel 2.6.17-10, Python 2.5) different type of errors are raised depending on the application (client or server). In an asyncore-based client the error is raised by socket module (dispatcher's "self.socket" attribute) inside 'connect' method of 'dispatcher' class: [...] connections: 1018 connections: 1019 connections: 1020 connections: 1021 Traceback (most recent call last): File "asyncore_client.py", line 31, in File "asyncore.py", line 191, in loop File "asyncore.py", line 138, in poll File "asyncore.py", line 80, in write File "asyncore.py", line 76, in write File "asyncore.py", line 395, in handle_write_event File "asyncore_client.py", line 24, in handle_connect File "asyncore_client.py", line 9, in __init__ File "asyncore.py", line 257, in create_socket File "socket.py", line 156, in __init__ socket.error: (24, 'Too many open files') On an asyncore-based server the error is raised by socket module (dispatcher's "self.socket" attribute) inside 'accept' method of 'dispatcher' class: [...] connections: 1019 connections: 1020 connections: 1021 Traceback (most recent call last): File "asyncore_server.py", line 38, in File "asyncore.py", line 191, in loop File "asyncore.py", line 132, in poll File "asyncore.py", line 72, in read File "asyncore.py", line 68, in read File "asyncore.py", line 384, in handle_read_event File "asyncore_server.py", line 16, in handle_accept File "asyncore.py", line 321, in accept File "socket.py", line 170, in accept socket.error: (24, 'Too many open files') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685000&group_id=5470 From noreply at sourceforge.net Wed Mar 21 10:43:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 02:43:23 -0700 Subject: [ python-Bugs-1675967 ] Python2.5 can't read a (complex) pickle build by python2.4 Message-ID: Bugs item #1675967, was opened at 2007-03-07 18:16 Message generated for change (Comment added) made by mvo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675967&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michael Vogt (mvo) Assigned to: ?iga Seilnacht (zseil) Summary: Python2.5 can't read a (complex) pickle build by python2.4 Initial Comment: Part of gnome-app-install in ubuntu is a pickle data structure cache. If I create this pickle with python 2.4 and read it later with 2.5. I get the following error: $ python2.5 -c 'import pickle; pickle.load(open("/var/cache/app-install/menu.p"))' /usr/lib/python2.5/pickle.py:1124: DeprecationWarning: The sre module is deprecated, please import re. __import__(module) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/pickle.py", line 1370, in load return Unpickler(file).load() File "/usr/lib/python2.5/pickle.py", line 858, in load dispatch[key](self) File "/usr/lib/python2.5/pickle.py", line 1090, in load_global klass = self.find_class(module, name) File "/usr/lib/python2.5/pickle.py", line 1126, in find_class klass = getattr(mod, name) AttributeError: 'module' object has no attribute '_compile' With: $ python2.4 -c 'import pickle; pickle.load(open("/var/cache/app-install/menu.p"))' egon at top ~ $ It loads just fine. The test pickle can be found here: http://people.ubuntu.com/~mvo/gnome-app-install/menu.p.gz Cheers, Michael ---------------------------------------------------------------------- >Comment By: Michael Vogt (mvo) Date: 2007-03-21 09:43 Message: Logged In: YES user_id=3206 Originator: YES Thanks a lot for the patch. It works fine here with the patch. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-11 15:40 Message: Logged In: YES user_id=1326842 Originator: NO Attaching the patch with a test here. Unpickling old patterns with this patch works, but it still issues a DeprecationWarning. The test itself is a bit obscure, but the other option is to add a binary file to the test suite. File Added: sre_pickle_compatibility.diff ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-07 19:43 Message: Logged In: YES user_id=1326842 Originator: NO This happens because of SRE_Pattern objects in jour pickle. The sre module was renamed to re in Python 2.5, but the old pickles still expect the _compile function in sre module. I posted the patch here: http://freeweb.siol.net/chollus/ Could you try if it fixes the problem for you and in that case, attach it to this report? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675967&group_id=5470 From noreply at sourceforge.net Wed Mar 21 12:26:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 04:26:23 -0700 Subject: [ python-Bugs-1669349 ] make install fails if no previous Python installation Message-ID: Bugs item #1669349, was opened at 2007-02-26 19:22 Message generated for change (Comment added) made by percivall You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669349&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias S. Benkmann (mbenkmann) Assigned to: Nobody/Anonymous (nobody) Summary: make install fails if no previous Python installation Initial Comment: When installing Python 2.5 on a completely Python-less system 'make install' failed. The error that caused the failure was Compiling /usr/lib/python2.5/test/test_multibytecodec.py ... Sorry: UnicodeError: ("\\N escapes not supported (can't load unicodedata module)",) [snip] Compiling /usr/lib/python2.5/zipfile.py ... make: *** [libinstall] Error 1 'find -name unicodedata.so' showed me that the library did not exist in the build tree. However, after a 'make -i install' to force make to continue despite the error, unicodedata.so was there. So apparently the library is not built until a later stage of make install. And indeed, subsequent 'make install' calls without -i were successful. It is important to note that if you have a previous Python installation (at least of the same version), 'make install' will go through, because it'll load the library from there. So if you want to reproduce the issue you will have to install from a freshly unpacked tarball on a system with no Python installation. ---------------------------------------------------------------------- Comment By: Simon Percivall (percivall) Date: 2007-03-21 12:26 Message: Logged In: YES user_id=329382 Originator: NO It shouldn't be a problem changing the Makefile to do sharedinstall before libinstall in the altinstall target. I'm guessing that would solve the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669349&group_id=5470 From noreply at sourceforge.net Wed Mar 21 12:42:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 04:42:09 -0700 Subject: [ python-Bugs-1681974 ] mkdtemp fails on Windows if username has non-ASCII character Message-ID: Bugs item #1681974, was opened at 2007-03-16 10:03 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681974&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Markus Niemist? (niemisto) Assigned to: Nobody/Anonymous (nobody) Summary: mkdtemp fails on Windows if username has non-ASCII character Initial Comment: mkdtemp fails miserably on Windows if Windows user name has any non-ASCII characters, like ?? or ??, in it. mkdtemp throws an encoding error. This seems to be because the default temp dir in Windows is "c:\documents and settings\\local settings\temp". Now if the user name has non-ASCII characters ASCII decoder cannot handle it and creating temp directories won't work. As a work around I have used the following code: tempdir = unicode(tempfile.gettempdir(), 'mbcs') mkdtemp(suffix='foo', dir=tempdir) This applies for both Python 2.4 and Python 2.5. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-21 11:42 Message: Logged In: YES user_id=849994 Originator: NO Could you indicate where exactly what error is raised? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681974&group_id=5470 From noreply at sourceforge.net Wed Mar 21 12:53:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 04:53:07 -0700 Subject: [ python-Bugs-1684254 ] regression in webbrowser command line parsing Message-ID: Bugs item #1684254, was opened at 2007-03-20 11:09 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684254&group_id=5470 Please note that this 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.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Lukas Lalinsky (luks) Assigned to: Nobody/Anonymous (nobody) Summary: regression in webbrowser command line parsing Initial Comment: With Python 2.4 it was common to use BROWSER environment variables like: BROWSER="firefox '%s' &" to launch a browser. The apostrophes around %s are required to escape special characters in the URL (because the command is launched using os.system, which uses a shell), and & at the end is required to not block GUI applications. However, in Python 2.5 it uses the subprocess module, and the example above doesn't work. It tries to open `firefox 'URL' &` literally, which causes Firefox to open URIs like file:///path/to/current/directory/'URL'. Attached a patch that fixes the problem. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-21 11:53 Message: Logged In: YES user_id=849994 Originator: NO Thanks for the report, fixed it using shlex in rev. 54485, 54486 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684254&group_id=5470 From noreply at sourceforge.net Wed Mar 21 12:57:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 04:57:03 -0700 Subject: [ python-Bugs-1684254 ] regression in webbrowser command line parsing Message-ID: Bugs item #1684254, was opened at 2007-03-20 12:09 Message generated for change (Comment added) made by luks You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684254&group_id=5470 Please note that this 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.5 Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Lukas Lalinsky (luks) Assigned to: Nobody/Anonymous (nobody) Summary: regression in webbrowser command line parsing Initial Comment: With Python 2.4 it was common to use BROWSER environment variables like: BROWSER="firefox '%s' &" to launch a browser. The apostrophes around %s are required to escape special characters in the URL (because the command is launched using os.system, which uses a shell), and & at the end is required to not block GUI applications. However, in Python 2.5 it uses the subprocess module, and the example above doesn't work. It tries to open `firefox 'URL' &` literally, which causes Firefox to open URIs like file:///path/to/current/directory/'URL'. Attached a patch that fixes the problem. ---------------------------------------------------------------------- >Comment By: Lukas Lalinsky (luks) Date: 2007-03-21 12:57 Message: Logged In: YES user_id=587716 Originator: YES Oh, I didn't know about shlex.split. Thanks. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-21 12:53 Message: Logged In: YES user_id=849994 Originator: NO Thanks for the report, fixed it using shlex in rev. 54485, 54486 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684254&group_id=5470 From noreply at sourceforge.net Wed Mar 21 16:11:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 08:11:15 -0700 Subject: [ python-Bugs-515751 ] Missing docs for module imputil Message-ID: Bugs item #515751, was opened at 2002-02-11 00:55 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=515751&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 6 Private: No Submitted By: David Abrahams (david_abrahams) >Assigned to: Nobody/Anonymous (nobody) Summary: Missing docs for module imputil Initial Comment: The summary says it all. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-03-12 15:29 Message: Logged In: YES user_id=3066 Greg -- please write documentation for this module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=515751&group_id=5470 From noreply at sourceforge.net Wed Mar 21 18:18:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 10:18:50 -0700 Subject: [ python-Bugs-692884 ] python always searches python23.zip Message-ID: Bugs item #692884, was opened at 2003-02-25 08:43 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=692884&group_id=5470 Please note that this 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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Just van Rossum (jvr) Summary: python always searches python23.zip Initial Comment: In trying to figure out why startup of the spambayes hammiefilter seems so slow, I ran it under the control of ktrace (also known as strace or truss on other systems). I noticed that even though it's not in sys.path, the interpreter is always searching for modules in $prefix/python23.zip. Why's that? Here's a little ktrace/kdump output: 2361 python CALL stat(0xbfffe1d0,0xbfffe5e0) 2361 python NAMI "/Users/skip/local/lib/python23.zip" 2361 python RET stat -1 errno 2 No such file or directory 2361 python CALL stat(0xbfffe1d0,0xbfffe5e0) 2361 python NAMI "/Users/skip/local/lib" 2361 python RET stat 0 2361 python CALL stat(0xbfffece0,0xbfffe7d0) 2361 python NAMI "/Users/skip/local/lib/python23.zip/warnings" 2361 python RET stat -1 errno 2 No such file or directory 2361 python CALL open(0xbfffece0,0,0x1b6) 2361 python NAMI "/Users/skip/local/lib/python23.zip/warnings.py" 2361 python RET open -1 errno 2 No such file or directory 2361 python CALL open(0xbfffece0,0,0x1b6) 2361 python NAMI "/Users/skip/local/lib/python23.zip/warnings.pyc" 2361 python RET open -1 errno 2 No such file or directory 2361 python CALL open(0xbfffece0,0,0x1b6) 2361 python NAMI "/Users/skip/local/lib/python23.zip/warnings.so" 2361 python RET open -1 errno 2 No such file or directory 2361 python CALL open(0xbfffece0,0,0x1b6) 2361 python NAMI "/Users/skip/local/lib/python23.zip/warningsmodule.so" 2361 python RET open -1 errno 2 No such file or directory What's particularly odd is that even though the search for python23.zip fails, it continues to march along looking for files within the nonexistent zip file. Searching for modules in something not in sys.path seems like a bug to me. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-21 13:18 Message: Logged In: YES user_id=1344176 Originator: NO "python -vv" tells me this was fixed some time between Python 2.4.4 and Python 2.5.0. Closing as "fixed". ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-25 10:32 Message: Logged In: YES user_id=92689 I think it would cause more confusion to have the .pyo's in an earlier location than the .pyc's and .py's. Also, this would cause the .pyo's to always be used, even when not using -O. The solution is what I said: phase two of PEP 302. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-02-25 10:15 Message: Logged In: YES user_id=44345 If $prefix/python23.zip must always be present and is always going to be searched (and searched ahead of $prefix/python2.3, why not have the installation process create it with the .pyo contents of $prefix/python2.3? (Hammiefilter doesn't import any Mac modules, so the problem Jack fixed shouldn't affect this case.) ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-25 10:07 Message: Logged In: YES user_id=92689 (You probably could have found this with python -vv ;-) Since Python 2.3a1, site.py no longer removes sys.path items that don't exist on the file system, because it may be (eg.) a URL, handled by a custom importer. PEP 273 explains why a standard zip entry must be on sys.path. The problem is that the PEP 302 mechanism doesn't make a difference between "no importer found for this sys.path entry" and "use the builtin path importer". This will be fixed in "phase 2" of PEP 302, which consits of adding an explicit importer object on sys.meta_path representing the builtin path importer. (I should really do this before 2.3b1, this report should serve as a reminder for me.) That said, Jack _yesterday_ fixed a problem on OSX which caused importing Mac modules to be extremely slow (a delay of *seconds*). If spambayes happens to import a Mac module on OSX this would have affected you. Rebuilding from current CVS would help then. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=692884&group_id=5470 From noreply at sourceforge.net Wed Mar 21 18:38:24 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 10:38:24 -0700 Subject: [ python-Bugs-696206 ] Move modules out of Carbon Message-ID: Bugs item #696206, was opened at 2003-03-02 16:26 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696206&group_id=5470 Please note that this 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 Private: No Submitted By: Jack Jansen (jackjansen) >Assigned to: Brett Cannon (bcannon) Summary: Move modules out of Carbon Initial Comment: Some modules that are in the Carbon package for historical reasons need to move to other places (with a compaitbility module in Carbon, for 2.3). Definitely CG, CF and Qt, and for Qd and AE there's a point to be made too (but there are some technical difficulties there). ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-21 13:38 Message: Logged In: YES user_id=1344176 Originator: NO I don't understand how having these modules in Carbon is a bug. Why should they be moved out? Assigning to Brett since this seems like something that would fall under his PEP 3108. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696206&group_id=5470 From noreply at sourceforge.net Wed Mar 21 18:49:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 10:49:23 -0700 Subject: [ python-Bugs-214033 ] re incompatibility in sre Message-ID: Bugs item #214033, was opened at 2000-09-11 04:24 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=214033&group_id=5470 Please note that this 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: Accepted Priority: 5 Private: No Submitted By: Martin v. L?wis (loewis) Assigned to: Fredrik Lundh (effbot) Summary: re incompatibility in sre Initial Comment: [submitted by Adam Sampson] Under Python 1.5.2, I had a script containing the following line: m = re.match(r"[a-z0-9]*://[^/]+/.*\.([^.#\?/]*)([#\?]?.*)?", url) Under 1.6, this fails with: [...] File "/usr/local/lib/python1.6/sre.py", line 44, in match return _compile(pattern, flags).match(string) File "/usr/local/lib/python1.6/sre.py", line 102, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeat I can narrow it down to: >>> m = re.match(r"(x?)?", url) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/local/lib/python1.6/sre.py", line 44, in match return _compile(pattern, flags).match(string) File "/usr/local/lib/python1.6/sre.py", line 102, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeat whereas: >>> m = re.match(r"(x?.)?", url) works fine. Is this correct behaviour for SRE, or am I just being stupid? "(x?)?" looks like a perfectly reasonable Perl-style regexp to me (and Perl too)... ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-21 13:49 Message: Logged In: YES user_id=1344176 Originator: NO The original bug no longer applies to Python 2.5.0 or 2.6a0. Trent's bug still exists in Python 2.5.0 and 2.6a0 (where 2.6a0 == SVN r54478). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-06-01 09:45 Message: Logged In: YES user_id=849994 #1456280 is a duplicate of this. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2006-04-10 19:11 Message: Logged In: YES user_id=34892 I've run into another incarnation of this (it breaks in Python 2.3.5 and Python 2.4.3): >>> import sre >>> sre.compile("(a*)?") Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\Lib\sre.py", line 180, in compile return _compile(pattern, flags) File "C:\Python24\Lib\sre.py", line 227, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeat Now granted that the '?' here is redundant for the '*' quantifier on 'a', but compiling this regex works with Python 2.3's "pre" and it works in Perl. The actual use case I've hit here is trying to compile all the regex's in Fedora Core 5's SELinux config files (/etc/selinux/targeted/contexts/files/file_contexts*). The first such regex that broke was: '/usr/share/selinux-policy([^/]*)?/html(/.*)?' ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2000-10-01 14:13 Message: Yes, it is still broken in 2.0b2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-10-01 00:33 Message: Martin, is this still broken in 2.0? Fredrik, any idea? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=214033&group_id=5470 From noreply at sourceforge.net Wed Mar 21 19:39:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 11:39:03 -0700 Subject: [ python-Bugs-1685453 ] email package should work better with unicode Message-ID: Bugs item #1685453, was opened at 2007-03-21 14:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685453&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email package should work better with unicode Initial Comment: This is a catch-all issue for improving the email package's handling of unicode. For now, please add issues/problems you find with email & unicode to this tracker item. For example: MIMEText()'s first argument should accept a unicode if _charset is also given. It should not be necessary to manually encode the first argument into an 8-bit string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685453&group_id=5470 From noreply at sourceforge.net Wed Mar 21 20:45:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 12:45:34 -0700 Subject: [ python-Bugs-882297 ] socket's makefile file object doesn't work with timeouts. Message-ID: Bugs item #882297, was opened at 2004-01-22 15:36 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=882297&group_id=5470 Please note that this 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: Fixed Priority: 5 Private: No Submitted By: Jeremy Fincher (jemfinch) Assigned to: Facundo Batista (facundobatista) Summary: socket's makefile file object doesn't work with timeouts. Initial Comment: Ok, here's what I did: >>> import socket >>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) >>> s.bind(('', 9009)) >>> s.listen(5) >>> s.accept() Now, I opened a second Python interpreter in which I typed this: >>> import socket >>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) >>> s.connect(('localhost', 9009)) In the first interpreter I did this: >>> s.accept() (, ('127.0.0.1', 33059)) >>> s1 = _[0] >>> s1.settimeout(3) >>> fd = s1.makefile() Then I tested that the timeout worked correctly. Still in the first interpreter: >>> fd.readline() Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/socket.py", line 338, in readline data = self._sock.recv(self._rbufsize) socket.timeout: timed out >>> fd.readline() Now, while that was blocking, I did this in the second interpreter: >>> s.send('foo') 3 Which caused this in the first interpreter (as expected, since I didn't send a newline): Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/socket.py", line 338, in readline data = self._sock.recv(self._rbufsize) socket.timeout: timed out >>> fd.readline() While that was blocking, I did this in the second interpreter: >>> s.send('bar\n') 4 Finally sending a newline. But lo and behold! In the first interpreter I got this: >>> fd.readline() 'bar\n' Alas, my 'foo' has been lost! Anyway, the documentation does explicitly state that the socket should be in blocking mode, *implying* that it does no buffering, but it doesn't say anything about timeouts. Ideally, the file object would buffer enough data until the readline could return meaningfully, but failing that, the documentation should probably be updated to mention that timeouts shouldn't be used with readline on the returned file object. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2007-03-21 16:45 Message: Logged In: YES user_id=752496 Originator: NO >From the makefile documentation: "The socket must be in blocking mode". If the socket is in blocking mode, it can NOT have a timeout. I fixed the docs, and made that explicit. Regards, ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-03-11 15:46 Message: Logged In: YES user_id=44345 Originator: NO Okay, this is the socket.makefile/timeout bug report. Sorry about the previous blip. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-17 09:10 Message: Logged In: YES user_id=1188172 If this is a bug, it hasn't been fixed. I reproduced it here. Assigning to Skip since he worked on "makefile" as it seems. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-02-01 16:38 Message: Logged In: YES user_id=261020 I believe this was fixed in socket.py in rev 32056, closing bug 707074. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=882297&group_id=5470 From noreply at sourceforge.net Wed Mar 21 21:41:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 13:41:09 -0700 Subject: [ python-Bugs-1675967 ] Python2.5 can't read a (complex) pickle build by python2.4 Message-ID: Bugs item #1675967, was opened at 2007-03-07 19:16 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675967&group_id=5470 Please note that this 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.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Michael Vogt (mvo) Assigned to: ?iga Seilnacht (zseil) Summary: Python2.5 can't read a (complex) pickle build by python2.4 Initial Comment: Part of gnome-app-install in ubuntu is a pickle data structure cache. If I create this pickle with python 2.4 and read it later with 2.5. I get the following error: $ python2.5 -c 'import pickle; pickle.load(open("/var/cache/app-install/menu.p"))' /usr/lib/python2.5/pickle.py:1124: DeprecationWarning: The sre module is deprecated, please import re. __import__(module) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/pickle.py", line 1370, in load return Unpickler(file).load() File "/usr/lib/python2.5/pickle.py", line 858, in load dispatch[key](self) File "/usr/lib/python2.5/pickle.py", line 1090, in load_global klass = self.find_class(module, name) File "/usr/lib/python2.5/pickle.py", line 1126, in find_class klass = getattr(mod, name) AttributeError: 'module' object has no attribute '_compile' With: $ python2.4 -c 'import pickle; pickle.load(open("/var/cache/app-install/menu.p"))' egon at top ~ $ It loads just fine. The test pickle can be found here: http://people.ubuntu.com/~mvo/gnome-app-install/menu.p.gz Cheers, Michael ---------------------------------------------------------------------- >Comment By: ?iga Seilnacht (zseil) Date: 2007-03-21 21:41 Message: Logged In: YES user_id=1326842 Originator: NO The patch was commited as revision 54492, 54497 (2.5). ---------------------------------------------------------------------- Comment By: Michael Vogt (mvo) Date: 2007-03-21 10:43 Message: Logged In: YES user_id=3206 Originator: YES Thanks a lot for the patch. It works fine here with the patch. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-11 16:40 Message: Logged In: YES user_id=1326842 Originator: NO Attaching the patch with a test here. Unpickling old patterns with this patch works, but it still issues a DeprecationWarning. The test itself is a bit obscure, but the other option is to add a binary file to the test suite. File Added: sre_pickle_compatibility.diff ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-07 20:43 Message: Logged In: YES user_id=1326842 Originator: NO This happens because of SRE_Pattern objects in jour pickle. The sre module was renamed to re in Python 2.5, but the old pickles still expect the _compile function in sre module. I posted the patch here: http://freeweb.siol.net/chollus/ Could you try if it fixes the problem for you and in that case, attach it to this report? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675967&group_id=5470 From noreply at sourceforge.net Wed Mar 21 22:02:21 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 14:02:21 -0700 Subject: [ python-Bugs-696206 ] Move modules out of Carbon Message-ID: Bugs item #696206, was opened at 2003-03-02 22:26 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696206&group_id=5470 Please note that this 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 Private: No Submitted By: Jack Jansen (jackjansen) Assigned to: Brett Cannon (bcannon) Summary: Move modules out of Carbon Initial Comment: Some modules that are in the Carbon package for historical reasons need to move to other places (with a compaitbility module in Carbon, for 2.3). Definitely CG, CF and Qt, and for Qd and AE there's a point to be made too (but there are some technical difficulties there). ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2007-03-21 22:02 Message: Logged In: YES user_id=45365 Originator: YES I would just close this bug. The original reason for the report is that the mentioned modules are not technically part of what Apple calls "Carbon", so it was more of a naming thing than anything else. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-21 18:38 Message: Logged In: YES user_id=1344176 Originator: NO I don't understand how having these modules in Carbon is a bug. Why should they be moved out? Assigning to Brett since this seems like something that would fall under his PEP 3108. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696206&group_id=5470 From noreply at sourceforge.net Wed Mar 21 22:53:24 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 14:53:24 -0700 Subject: [ python-Bugs-696206 ] Move modules out of Carbon Message-ID: Bugs item #696206, was opened at 2003-03-02 13:26 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696206&group_id=5470 Please note that this 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: Invalid Priority: 5 Private: No Submitted By: Jack Jansen (jackjansen) Assigned to: Brett Cannon (bcannon) Summary: Move modules out of Carbon Initial Comment: Some modules that are in the Carbon package for historical reasons need to move to other places (with a compaitbility module in Carbon, for 2.3). Definitely CG, CF and Qt, and for Qd and AE there's a point to be made too (but there are some technical difficulties there). ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2007-03-21 14:53 Message: Logged In: YES user_id=357491 Originator: NO Closed it is! ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2007-03-21 14:02 Message: Logged In: YES user_id=45365 Originator: YES I would just close this bug. The original reason for the report is that the mentioned modules are not technically part of what Apple calls "Carbon", so it was more of a naming thing than anything else. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-21 10:38 Message: Logged In: YES user_id=1344176 Originator: NO I don't understand how having these modules in Carbon is a bug. Why should they be moved out? Assigning to Brett since this seems like something that would fall under his PEP 3108. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696206&group_id=5470 From noreply at sourceforge.net Wed Mar 21 23:03:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 15:03:51 -0700 Subject: [ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds Message-ID: Bugs item #1683368, was opened at 2007-03-18 20:32 Message generated for change (Comment added) made by blakeross You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Guido van Rossum (gvanrossum) Summary: object.__init__ shouldn't allow args/kwds Initial Comment: object.__init__ currently allows any amount of args and keywords even though they're ignored. This is inconsistent with other built-ins, like list, that are stricter about what they'll accept. It's also inconsistent with object.__new__, which does throw if any are provided (if the default __init__ is to be used). To reproduce: object.__init__(object(), foo, bar=3) This is a slight irritation when using cooperative super calling. I'd like each class' __init__ to cherry-pick keyword params it accepts and pass the remaining ones up the chain, but right now I can't rely on object.__init__ to throw if there are remaining keywords by that point. ---------------------------------------------------------------------- >Comment By: Blake Ross (blakeross) Date: 2007-03-21 15:03 Message: Logged In: YES user_id=1747060 Originator: YES Looks good. I skimmed briefly the tests you mentioned. The issue with test_array appears to be exactly the kind of bug this is intended to identify: it calls array.__init__(...), but array doesn't have its own initializer, so object's is used. I'd guess that the others are failing due to whatever the problem with pickling is (test_descr uses pickling). I haven't looked into that yet. I'm sure cooperative super calling of __init__ isn't all that common (it seems like the mechanism itself isn't used much yet, and may not be until it's done via keyword) but it doesn't seem like such a bad practice, especially when mixins are in the picture. There doesn't seem to be a great alternative. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-20 14:24 Message: Logged In: YES user_id=6380 Originator: NO I should mention that if we can't get the strict version of this in 2.6, we should be able to get it into 3.0. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-20 13:54 Message: Logged In: YES user_id=6380 Originator: NO Here's a stricter version. Unfortunately it breaks a couple of standard modules; this is a confirmation of my doubts whether the style of cooperative super calling of __init__ that you use is really the most common or "best practice". So far I have only fixed string.py (which would otherwise prevent extensions from being built); I haven't looked into why the other tests fail: test_array, test_cpickle, test_descr, test_pickle (and maybe more?). My conclusion: this would probably break too much code to be worth it. So I'll have to revert to the previous version. But anyway, here it is for your perusal. File Added: new_init_strict.patch ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-19 18:27 Message: Logged In: YES user_id=1747060 Originator: YES I think making the check more rigid is a good idea, since this should throw: class a(object): def __init__(self, foo): super(a, self).__init__(foo) def __new__(cls, foo): return object.__new__(cls) a(1) (minor typo in the patch: "solution it" -> "solution is") ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 16:35 Message: Logged In: YES user_id=6380 Originator: NO This smells enough like a new feature that it couldn't go into 2.5. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 16:31 Message: Logged In: YES user_id=6380 Originator: NO Attached is a patch that implements this proposal, adding copious commentary. It doesn't seem to break anything in the test suite. I wonder if we should even make the check more rigid: check the argument list if either the current method *is* overridden or the other one *is not* overridden. This would make super calls check the arguments even if the other method is overridden. What do you think? File Added: new_init.patch ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-19 15:45 Message: Logged In: YES user_id=1747060 Originator: YES Makes sense. I don't think we can ever be completely correct here since we're inferring intent from the presence of __init__/__new__ that's liable to be wrong in some cases, but it's likely correct often enough that it's worth doing. If I understand correctly, we want to be more forgiving iff one of the two methods is used, so it seems like we should be complaining if both are used *or* if neither is used. After all, I could add a __new__ to my coop use case and I'd still want object to complain. If that's the case, both object_new and object_init should be complaining if ((tp->tp_new == object_new && tp->tp_init == object_init) || (tp->tp_new != object_new && tp->tp_init != object_init)). Of course, for the paranoid, there's always the risk that __new__ will modify these class functions and change the outcome :) For instance, if a class had a __new__ and no __init__ and its __new__ changed __new__ back to object.__new__, object_init on that run would be fooled into thinking it's using the defaults for both and would complain. I think this could only be fixed in type_call, which is rather ugly...but then, this *is* a special case of the "call __init__ after __new__" behavior, and we're trying to solve it within the methods themselves. Perhaps this last point is academic enough to be ignored...I don't know why anyone would do this, although the language makes it possible. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 13:01 Message: Logged In: YES user_id=6380 Originator: NO I'll try to explain why I did it this way. I was considering the single inheritance case implementing an Immutable object, which overrides __new__ but has no need to override __init__ (since it's too late to do anything in __init__ for an Immutable object). Since the __init__ still gets called it would be annoying to have to override it just to make the error go away if there was a check in __init__. The other case is overriding __init__ without overriding __new__, which is the most common way of doing Mutable objects; here you wouldn't want __new__ to complain about extra args. So the only time when you'd want complaints is if both __new__ and __init__ are the defaults, in which case it doesn't really matter whether you implement this in __init__ or in __new__, so I arbitrarily chose __new__. I wasn't thinking of your use case at the time though (cooperative super calls to __init__, which still isn't something I engage in on a day-to-day basis). I wonder if the right thing to do wouldn't be to implement the same check both in __init__ and in __new__. Am I makign sense? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-19 01:56 Message: Logged In: YES user_id=849994 Originator: NO I don't really understand either why object_new() checks the arguments, not object_init(): """ static int object_init(PyObject *self, PyObject *args, PyObject *kwds) { return 0; } /* If we don't have a tp_new for a new-style class, new will use this one. Therefore this should take no arguments/keywords. However, this new may also be inherited by objects that define a tp_init but no tp_new. These objects WILL pass argumets to tp_new, because it gets the same args as tp_init. So only allow arguments if we aren't using the default init, in which case we expect init to handle argument parsing. */ static PyObject * object_new(PyTypeObject *type, PyObject *args, PyObject *kwds) { if (type->tp_init == object_init && (PyTuple_GET_SIZE(args) || (kwds && PyDict_Check(kwds) && PyDict_Size(kwds)))) { PyErr_SetString(PyExc_TypeError, "default __new__ takes no parameters"); return NULL; } return type->tp_alloc(type, 0); } """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 From noreply at sourceforge.net Wed Mar 21 23:42:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 15:42:25 -0700 Subject: [ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds Message-ID: Bugs item #1683368, was opened at 2007-03-18 23:32 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Guido van Rossum (gvanrossum) Summary: object.__init__ shouldn't allow args/kwds Initial Comment: object.__init__ currently allows any amount of args and keywords even though they're ignored. This is inconsistent with other built-ins, like list, that are stricter about what they'll accept. It's also inconsistent with object.__new__, which does throw if any are provided (if the default __init__ is to be used). To reproduce: object.__init__(object(), foo, bar=3) This is a slight irritation when using cooperative super calling. I'd like each class' __init__ to cherry-pick keyword params it accepts and pass the remaining ones up the chain, but right now I can't rely on object.__init__ to throw if there are remaining keywords by that point. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-21 18:42 Message: Logged In: YES user_id=6380 Originator: NO Well, but since it's been like this for a long time, I don't want to gratuitously break code. At least not in 2.6. So I'm rejecting the stricter patch for 2.6. (However, if you want to submit patches that would fix these breakages anyway, be my guest.) ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-21 18:03 Message: Logged In: YES user_id=1747060 Originator: YES Looks good. I skimmed briefly the tests you mentioned. The issue with test_array appears to be exactly the kind of bug this is intended to identify: it calls array.__init__(...), but array doesn't have its own initializer, so object's is used. I'd guess that the others are failing due to whatever the problem with pickling is (test_descr uses pickling). I haven't looked into that yet. I'm sure cooperative super calling of __init__ isn't all that common (it seems like the mechanism itself isn't used much yet, and may not be until it's done via keyword) but it doesn't seem like such a bad practice, especially when mixins are in the picture. There doesn't seem to be a great alternative. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-20 17:24 Message: Logged In: YES user_id=6380 Originator: NO I should mention that if we can't get the strict version of this in 2.6, we should be able to get it into 3.0. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-20 16:54 Message: Logged In: YES user_id=6380 Originator: NO Here's a stricter version. Unfortunately it breaks a couple of standard modules; this is a confirmation of my doubts whether the style of cooperative super calling of __init__ that you use is really the most common or "best practice". So far I have only fixed string.py (which would otherwise prevent extensions from being built); I haven't looked into why the other tests fail: test_array, test_cpickle, test_descr, test_pickle (and maybe more?). My conclusion: this would probably break too much code to be worth it. So I'll have to revert to the previous version. But anyway, here it is for your perusal. File Added: new_init_strict.patch ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-19 21:27 Message: Logged In: YES user_id=1747060 Originator: YES I think making the check more rigid is a good idea, since this should throw: class a(object): def __init__(self, foo): super(a, self).__init__(foo) def __new__(cls, foo): return object.__new__(cls) a(1) (minor typo in the patch: "solution it" -> "solution is") ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 19:35 Message: Logged In: YES user_id=6380 Originator: NO This smells enough like a new feature that it couldn't go into 2.5. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 19:31 Message: Logged In: YES user_id=6380 Originator: NO Attached is a patch that implements this proposal, adding copious commentary. It doesn't seem to break anything in the test suite. I wonder if we should even make the check more rigid: check the argument list if either the current method *is* overridden or the other one *is not* overridden. This would make super calls check the arguments even if the other method is overridden. What do you think? File Added: new_init.patch ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-19 18:45 Message: Logged In: YES user_id=1747060 Originator: YES Makes sense. I don't think we can ever be completely correct here since we're inferring intent from the presence of __init__/__new__ that's liable to be wrong in some cases, but it's likely correct often enough that it's worth doing. If I understand correctly, we want to be more forgiving iff one of the two methods is used, so it seems like we should be complaining if both are used *or* if neither is used. After all, I could add a __new__ to my coop use case and I'd still want object to complain. If that's the case, both object_new and object_init should be complaining if ((tp->tp_new == object_new && tp->tp_init == object_init) || (tp->tp_new != object_new && tp->tp_init != object_init)). Of course, for the paranoid, there's always the risk that __new__ will modify these class functions and change the outcome :) For instance, if a class had a __new__ and no __init__ and its __new__ changed __new__ back to object.__new__, object_init on that run would be fooled into thinking it's using the defaults for both and would complain. I think this could only be fixed in type_call, which is rather ugly...but then, this *is* a special case of the "call __init__ after __new__" behavior, and we're trying to solve it within the methods themselves. Perhaps this last point is academic enough to be ignored...I don't know why anyone would do this, although the language makes it possible. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 16:01 Message: Logged In: YES user_id=6380 Originator: NO I'll try to explain why I did it this way. I was considering the single inheritance case implementing an Immutable object, which overrides __new__ but has no need to override __init__ (since it's too late to do anything in __init__ for an Immutable object). Since the __init__ still gets called it would be annoying to have to override it just to make the error go away if there was a check in __init__. The other case is overriding __init__ without overriding __new__, which is the most common way of doing Mutable objects; here you wouldn't want __new__ to complain about extra args. So the only time when you'd want complaints is if both __new__ and __init__ are the defaults, in which case it doesn't really matter whether you implement this in __init__ or in __new__, so I arbitrarily chose __new__. I wasn't thinking of your use case at the time though (cooperative super calls to __init__, which still isn't something I engage in on a day-to-day basis). I wonder if the right thing to do wouldn't be to implement the same check both in __init__ and in __new__. Am I makign sense? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-19 04:56 Message: Logged In: YES user_id=849994 Originator: NO I don't really understand either why object_new() checks the arguments, not object_init(): """ static int object_init(PyObject *self, PyObject *args, PyObject *kwds) { return 0; } /* If we don't have a tp_new for a new-style class, new will use this one. Therefore this should take no arguments/keywords. However, this new may also be inherited by objects that define a tp_init but no tp_new. These objects WILL pass argumets to tp_new, because it gets the same args as tp_init. So only allow arguments if we aren't using the default init, in which case we expect init to handle argument parsing. */ static PyObject * object_new(PyTypeObject *type, PyObject *args, PyObject *kwds) { if (type->tp_init == object_init && (PyTuple_GET_SIZE(args) || (kwds && PyDict_Check(kwds) && PyDict_Size(kwds)))) { PyErr_SetString(PyExc_TypeError, "default __new__ takes no parameters"); return NULL; } return type->tp_alloc(type, 0); } """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 From noreply at sourceforge.net Wed Mar 21 23:48:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 15:48:31 -0700 Subject: [ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds Message-ID: Bugs item #1683368, was opened at 2007-03-18 20:32 Message generated for change (Comment added) made by blakeross You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Guido van Rossum (gvanrossum) Summary: object.__init__ shouldn't allow args/kwds Initial Comment: object.__init__ currently allows any amount of args and keywords even though they're ignored. This is inconsistent with other built-ins, like list, that are stricter about what they'll accept. It's also inconsistent with object.__new__, which does throw if any are provided (if the default __init__ is to be used). To reproduce: object.__init__(object(), foo, bar=3) This is a slight irritation when using cooperative super calling. I'd like each class' __init__ to cherry-pick keyword params it accepts and pass the remaining ones up the chain, but right now I can't rely on object.__init__ to throw if there are remaining keywords by that point. ---------------------------------------------------------------------- >Comment By: Blake Ross (blakeross) Date: 2007-03-21 15:48 Message: Logged In: YES user_id=1747060 Originator: YES Holding the strict version for 3 makes sense to me. Let me know if you need anything more on my end... thanks for the fast turnaround. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-21 15:42 Message: Logged In: YES user_id=6380 Originator: NO Well, but since it's been like this for a long time, I don't want to gratuitously break code. At least not in 2.6. So I'm rejecting the stricter patch for 2.6. (However, if you want to submit patches that would fix these breakages anyway, be my guest.) ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-21 15:03 Message: Logged In: YES user_id=1747060 Originator: YES Looks good. I skimmed briefly the tests you mentioned. The issue with test_array appears to be exactly the kind of bug this is intended to identify: it calls array.__init__(...), but array doesn't have its own initializer, so object's is used. I'd guess that the others are failing due to whatever the problem with pickling is (test_descr uses pickling). I haven't looked into that yet. I'm sure cooperative super calling of __init__ isn't all that common (it seems like the mechanism itself isn't used much yet, and may not be until it's done via keyword) but it doesn't seem like such a bad practice, especially when mixins are in the picture. There doesn't seem to be a great alternative. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-20 14:24 Message: Logged In: YES user_id=6380 Originator: NO I should mention that if we can't get the strict version of this in 2.6, we should be able to get it into 3.0. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-20 13:54 Message: Logged In: YES user_id=6380 Originator: NO Here's a stricter version. Unfortunately it breaks a couple of standard modules; this is a confirmation of my doubts whether the style of cooperative super calling of __init__ that you use is really the most common or "best practice". So far I have only fixed string.py (which would otherwise prevent extensions from being built); I haven't looked into why the other tests fail: test_array, test_cpickle, test_descr, test_pickle (and maybe more?). My conclusion: this would probably break too much code to be worth it. So I'll have to revert to the previous version. But anyway, here it is for your perusal. File Added: new_init_strict.patch ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-19 18:27 Message: Logged In: YES user_id=1747060 Originator: YES I think making the check more rigid is a good idea, since this should throw: class a(object): def __init__(self, foo): super(a, self).__init__(foo) def __new__(cls, foo): return object.__new__(cls) a(1) (minor typo in the patch: "solution it" -> "solution is") ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 16:35 Message: Logged In: YES user_id=6380 Originator: NO This smells enough like a new feature that it couldn't go into 2.5. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 16:31 Message: Logged In: YES user_id=6380 Originator: NO Attached is a patch that implements this proposal, adding copious commentary. It doesn't seem to break anything in the test suite. I wonder if we should even make the check more rigid: check the argument list if either the current method *is* overridden or the other one *is not* overridden. This would make super calls check the arguments even if the other method is overridden. What do you think? File Added: new_init.patch ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-19 15:45 Message: Logged In: YES user_id=1747060 Originator: YES Makes sense. I don't think we can ever be completely correct here since we're inferring intent from the presence of __init__/__new__ that's liable to be wrong in some cases, but it's likely correct often enough that it's worth doing. If I understand correctly, we want to be more forgiving iff one of the two methods is used, so it seems like we should be complaining if both are used *or* if neither is used. After all, I could add a __new__ to my coop use case and I'd still want object to complain. If that's the case, both object_new and object_init should be complaining if ((tp->tp_new == object_new && tp->tp_init == object_init) || (tp->tp_new != object_new && tp->tp_init != object_init)). Of course, for the paranoid, there's always the risk that __new__ will modify these class functions and change the outcome :) For instance, if a class had a __new__ and no __init__ and its __new__ changed __new__ back to object.__new__, object_init on that run would be fooled into thinking it's using the defaults for both and would complain. I think this could only be fixed in type_call, which is rather ugly...but then, this *is* a special case of the "call __init__ after __new__" behavior, and we're trying to solve it within the methods themselves. Perhaps this last point is academic enough to be ignored...I don't know why anyone would do this, although the language makes it possible. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 13:01 Message: Logged In: YES user_id=6380 Originator: NO I'll try to explain why I did it this way. I was considering the single inheritance case implementing an Immutable object, which overrides __new__ but has no need to override __init__ (since it's too late to do anything in __init__ for an Immutable object). Since the __init__ still gets called it would be annoying to have to override it just to make the error go away if there was a check in __init__. The other case is overriding __init__ without overriding __new__, which is the most common way of doing Mutable objects; here you wouldn't want __new__ to complain about extra args. So the only time when you'd want complaints is if both __new__ and __init__ are the defaults, in which case it doesn't really matter whether you implement this in __init__ or in __new__, so I arbitrarily chose __new__. I wasn't thinking of your use case at the time though (cooperative super calls to __init__, which still isn't something I engage in on a day-to-day basis). I wonder if the right thing to do wouldn't be to implement the same check both in __init__ and in __new__. Am I makign sense? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-19 01:56 Message: Logged In: YES user_id=849994 Originator: NO I don't really understand either why object_new() checks the arguments, not object_init(): """ static int object_init(PyObject *self, PyObject *args, PyObject *kwds) { return 0; } /* If we don't have a tp_new for a new-style class, new will use this one. Therefore this should take no arguments/keywords. However, this new may also be inherited by objects that define a tp_init but no tp_new. These objects WILL pass argumets to tp_new, because it gets the same args as tp_init. So only allow arguments if we aren't using the default init, in which case we expect init to handle argument parsing. */ static PyObject * object_new(PyTypeObject *type, PyObject *args, PyObject *kwds) { if (type->tp_init == object_init && (PyTuple_GET_SIZE(args) || (kwds && PyDict_Check(kwds) && PyDict_Size(kwds)))) { PyErr_SetString(PyExc_TypeError, "default __new__ takes no parameters"); return NULL; } return type->tp_alloc(type, 0); } """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 From noreply at sourceforge.net Thu Mar 22 00:16:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 16:16:00 -0700 Subject: [ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds Message-ID: Bugs item #1683368, was opened at 2007-03-18 23:32 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Guido van Rossum (gvanrossum) Summary: object.__init__ shouldn't allow args/kwds Initial Comment: object.__init__ currently allows any amount of args and keywords even though they're ignored. This is inconsistent with other built-ins, like list, that are stricter about what they'll accept. It's also inconsistent with object.__new__, which does throw if any are provided (if the default __init__ is to be used). To reproduce: object.__init__(object(), foo, bar=3) This is a slight irritation when using cooperative super calling. I'd like each class' __init__ to cherry-pick keyword params it accepts and pass the remaining ones up the chain, but right now I can't rely on object.__init__ to throw if there are remaining keywords by that point. ---------------------------------------------------------------------- >Comment By: Terry J. Reedy (tjreedy) Date: 2007-03-21 19:16 Message: Logged In: YES user_id=593130 Originator: NO I ask myself, what should I expect from the documentation... >>> object.__init__.__doc__ 'x.__init__(...) initializes x; see x.__class__.__doc__ for signature' >>> object.__class__ >>> type.__doc__ "type(object) -> the object's type\ntype(name, bases, dict) -> a new type" and I still don't know ;-). ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-21 18:48 Message: Logged In: YES user_id=1747060 Originator: YES Holding the strict version for 3 makes sense to me. Let me know if you need anything more on my end... thanks for the fast turnaround. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-21 18:42 Message: Logged In: YES user_id=6380 Originator: NO Well, but since it's been like this for a long time, I don't want to gratuitously break code. At least not in 2.6. So I'm rejecting the stricter patch for 2.6. (However, if you want to submit patches that would fix these breakages anyway, be my guest.) ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-21 18:03 Message: Logged In: YES user_id=1747060 Originator: YES Looks good. I skimmed briefly the tests you mentioned. The issue with test_array appears to be exactly the kind of bug this is intended to identify: it calls array.__init__(...), but array doesn't have its own initializer, so object's is used. I'd guess that the others are failing due to whatever the problem with pickling is (test_descr uses pickling). I haven't looked into that yet. I'm sure cooperative super calling of __init__ isn't all that common (it seems like the mechanism itself isn't used much yet, and may not be until it's done via keyword) but it doesn't seem like such a bad practice, especially when mixins are in the picture. There doesn't seem to be a great alternative. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-20 17:24 Message: Logged In: YES user_id=6380 Originator: NO I should mention that if we can't get the strict version of this in 2.6, we should be able to get it into 3.0. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-20 16:54 Message: Logged In: YES user_id=6380 Originator: NO Here's a stricter version. Unfortunately it breaks a couple of standard modules; this is a confirmation of my doubts whether the style of cooperative super calling of __init__ that you use is really the most common or "best practice". So far I have only fixed string.py (which would otherwise prevent extensions from being built); I haven't looked into why the other tests fail: test_array, test_cpickle, test_descr, test_pickle (and maybe more?). My conclusion: this would probably break too much code to be worth it. So I'll have to revert to the previous version. But anyway, here it is for your perusal. File Added: new_init_strict.patch ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-19 21:27 Message: Logged In: YES user_id=1747060 Originator: YES I think making the check more rigid is a good idea, since this should throw: class a(object): def __init__(self, foo): super(a, self).__init__(foo) def __new__(cls, foo): return object.__new__(cls) a(1) (minor typo in the patch: "solution it" -> "solution is") ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 19:35 Message: Logged In: YES user_id=6380 Originator: NO This smells enough like a new feature that it couldn't go into 2.5. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 19:31 Message: Logged In: YES user_id=6380 Originator: NO Attached is a patch that implements this proposal, adding copious commentary. It doesn't seem to break anything in the test suite. I wonder if we should even make the check more rigid: check the argument list if either the current method *is* overridden or the other one *is not* overridden. This would make super calls check the arguments even if the other method is overridden. What do you think? File Added: new_init.patch ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-19 18:45 Message: Logged In: YES user_id=1747060 Originator: YES Makes sense. I don't think we can ever be completely correct here since we're inferring intent from the presence of __init__/__new__ that's liable to be wrong in some cases, but it's likely correct often enough that it's worth doing. If I understand correctly, we want to be more forgiving iff one of the two methods is used, so it seems like we should be complaining if both are used *or* if neither is used. After all, I could add a __new__ to my coop use case and I'd still want object to complain. If that's the case, both object_new and object_init should be complaining if ((tp->tp_new == object_new && tp->tp_init == object_init) || (tp->tp_new != object_new && tp->tp_init != object_init)). Of course, for the paranoid, there's always the risk that __new__ will modify these class functions and change the outcome :) For instance, if a class had a __new__ and no __init__ and its __new__ changed __new__ back to object.__new__, object_init on that run would be fooled into thinking it's using the defaults for both and would complain. I think this could only be fixed in type_call, which is rather ugly...but then, this *is* a special case of the "call __init__ after __new__" behavior, and we're trying to solve it within the methods themselves. Perhaps this last point is academic enough to be ignored...I don't know why anyone would do this, although the language makes it possible. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 16:01 Message: Logged In: YES user_id=6380 Originator: NO I'll try to explain why I did it this way. I was considering the single inheritance case implementing an Immutable object, which overrides __new__ but has no need to override __init__ (since it's too late to do anything in __init__ for an Immutable object). Since the __init__ still gets called it would be annoying to have to override it just to make the error go away if there was a check in __init__. The other case is overriding __init__ without overriding __new__, which is the most common way of doing Mutable objects; here you wouldn't want __new__ to complain about extra args. So the only time when you'd want complaints is if both __new__ and __init__ are the defaults, in which case it doesn't really matter whether you implement this in __init__ or in __new__, so I arbitrarily chose __new__. I wasn't thinking of your use case at the time though (cooperative super calls to __init__, which still isn't something I engage in on a day-to-day basis). I wonder if the right thing to do wouldn't be to implement the same check both in __init__ and in __new__. Am I makign sense? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-19 04:56 Message: Logged In: YES user_id=849994 Originator: NO I don't really understand either why object_new() checks the arguments, not object_init(): """ static int object_init(PyObject *self, PyObject *args, PyObject *kwds) { return 0; } /* If we don't have a tp_new for a new-style class, new will use this one. Therefore this should take no arguments/keywords. However, this new may also be inherited by objects that define a tp_init but no tp_new. These objects WILL pass argumets to tp_new, because it gets the same args as tp_init. So only allow arguments if we aren't using the default init, in which case we expect init to handle argument parsing. */ static PyObject * object_new(PyTypeObject *type, PyObject *args, PyObject *kwds) { if (type->tp_init == object_init && (PyTuple_GET_SIZE(args) || (kwds && PyDict_Check(kwds) && PyDict_Size(kwds)))) { PyErr_SetString(PyExc_TypeError, "default __new__ takes no parameters"); return NULL; } return type->tp_alloc(type, 0); } """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 From noreply at sourceforge.net Thu Mar 22 01:44:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 17:44:30 -0700 Subject: [ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds Message-ID: Bugs item #1683368, was opened at 2007-03-18 21:32 Message generated for change (Comment added) made by rhamphoryncus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Guido van Rossum (gvanrossum) Summary: object.__init__ shouldn't allow args/kwds Initial Comment: object.__init__ currently allows any amount of args and keywords even though they're ignored. This is inconsistent with other built-ins, like list, that are stricter about what they'll accept. It's also inconsistent with object.__new__, which does throw if any are provided (if the default __init__ is to be used). To reproduce: object.__init__(object(), foo, bar=3) This is a slight irritation when using cooperative super calling. I'd like each class' __init__ to cherry-pick keyword params it accepts and pass the remaining ones up the chain, but right now I can't rely on object.__init__ to throw if there are remaining keywords by that point. ---------------------------------------------------------------------- Comment By: Adam Olsen (rhamphoryncus) Date: 2007-03-21 18:44 Message: Logged In: YES user_id=12364 Originator: NO I think the avoidance of super() is largely *because* of this kind of leniency. Consider this snippet on python 2.3: class Base(object): def __init__(self, foo=None, *args, **kwargs): super(Base, self).__init__(foo, *args, **kwargs) Base(foo='bar') Base('bar', 42) Base('bar', 42, x=7) All pass silently, no error checking. Now consider a python 3.0 version, with a strict object.__init__: class Base: def __init__(self, foo=None, *, y='hi', **kwargs): super(Base, self).__init__(**kwargs) Base(foo='bar') # Valid, accepted Base('bar', 42) # Raises exception Base('bar', x=7) # Raises exception The error checking added by this bug/patch and the error checking added by PEP 3102 (keyword-only arguments) make super a lot more sane. I think it would also help if calling a method via super() didn't allow positional arguments. If the base class's arguments can't be given as keyword args then you probably should call it explicitly, rather than relying on super()'s MRO. I was also going to suggest super() should automagically create empty methods your parent classes don't have, but then I realized you really should have a base class that asserts the lack of such an automagic method: class Base(object): def mymethod(self, myonlyarg='hello world'): assert not hasattr(super(Base, self), 'mymethod') By the time you reach this base class you will have stripped off any extra arguments that your subclasses added, leaving you with nothing to pass up (and nothing to pass to). Having two mixins with the same method name and without a common parent class is just not sane. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2007-03-21 17:16 Message: Logged In: YES user_id=593130 Originator: NO I ask myself, what should I expect from the documentation... >>> object.__init__.__doc__ 'x.__init__(...) initializes x; see x.__class__.__doc__ for signature' >>> object.__class__ >>> type.__doc__ "type(object) -> the object's type\ntype(name, bases, dict) -> a new type" and I still don't know ;-). ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-21 16:48 Message: Logged In: YES user_id=1747060 Originator: YES Holding the strict version for 3 makes sense to me. Let me know if you need anything more on my end... thanks for the fast turnaround. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-21 16:42 Message: Logged In: YES user_id=6380 Originator: NO Well, but since it's been like this for a long time, I don't want to gratuitously break code. At least not in 2.6. So I'm rejecting the stricter patch for 2.6. (However, if you want to submit patches that would fix these breakages anyway, be my guest.) ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-21 16:03 Message: Logged In: YES user_id=1747060 Originator: YES Looks good. I skimmed briefly the tests you mentioned. The issue with test_array appears to be exactly the kind of bug this is intended to identify: it calls array.__init__(...), but array doesn't have its own initializer, so object's is used. I'd guess that the others are failing due to whatever the problem with pickling is (test_descr uses pickling). I haven't looked into that yet. I'm sure cooperative super calling of __init__ isn't all that common (it seems like the mechanism itself isn't used much yet, and may not be until it's done via keyword) but it doesn't seem like such a bad practice, especially when mixins are in the picture. There doesn't seem to be a great alternative. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-20 15:24 Message: Logged In: YES user_id=6380 Originator: NO I should mention that if we can't get the strict version of this in 2.6, we should be able to get it into 3.0. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-20 14:54 Message: Logged In: YES user_id=6380 Originator: NO Here's a stricter version. Unfortunately it breaks a couple of standard modules; this is a confirmation of my doubts whether the style of cooperative super calling of __init__ that you use is really the most common or "best practice". So far I have only fixed string.py (which would otherwise prevent extensions from being built); I haven't looked into why the other tests fail: test_array, test_cpickle, test_descr, test_pickle (and maybe more?). My conclusion: this would probably break too much code to be worth it. So I'll have to revert to the previous version. But anyway, here it is for your perusal. File Added: new_init_strict.patch ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-19 19:27 Message: Logged In: YES user_id=1747060 Originator: YES I think making the check more rigid is a good idea, since this should throw: class a(object): def __init__(self, foo): super(a, self).__init__(foo) def __new__(cls, foo): return object.__new__(cls) a(1) (minor typo in the patch: "solution it" -> "solution is") ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 17:35 Message: Logged In: YES user_id=6380 Originator: NO This smells enough like a new feature that it couldn't go into 2.5. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 17:31 Message: Logged In: YES user_id=6380 Originator: NO Attached is a patch that implements this proposal, adding copious commentary. It doesn't seem to break anything in the test suite. I wonder if we should even make the check more rigid: check the argument list if either the current method *is* overridden or the other one *is not* overridden. This would make super calls check the arguments even if the other method is overridden. What do you think? File Added: new_init.patch ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-19 16:45 Message: Logged In: YES user_id=1747060 Originator: YES Makes sense. I don't think we can ever be completely correct here since we're inferring intent from the presence of __init__/__new__ that's liable to be wrong in some cases, but it's likely correct often enough that it's worth doing. If I understand correctly, we want to be more forgiving iff one of the two methods is used, so it seems like we should be complaining if both are used *or* if neither is used. After all, I could add a __new__ to my coop use case and I'd still want object to complain. If that's the case, both object_new and object_init should be complaining if ((tp->tp_new == object_new && tp->tp_init == object_init) || (tp->tp_new != object_new && tp->tp_init != object_init)). Of course, for the paranoid, there's always the risk that __new__ will modify these class functions and change the outcome :) For instance, if a class had a __new__ and no __init__ and its __new__ changed __new__ back to object.__new__, object_init on that run would be fooled into thinking it's using the defaults for both and would complain. I think this could only be fixed in type_call, which is rather ugly...but then, this *is* a special case of the "call __init__ after __new__" behavior, and we're trying to solve it within the methods themselves. Perhaps this last point is academic enough to be ignored...I don't know why anyone would do this, although the language makes it possible. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 14:01 Message: Logged In: YES user_id=6380 Originator: NO I'll try to explain why I did it this way. I was considering the single inheritance case implementing an Immutable object, which overrides __new__ but has no need to override __init__ (since it's too late to do anything in __init__ for an Immutable object). Since the __init__ still gets called it would be annoying to have to override it just to make the error go away if there was a check in __init__. The other case is overriding __init__ without overriding __new__, which is the most common way of doing Mutable objects; here you wouldn't want __new__ to complain about extra args. So the only time when you'd want complaints is if both __new__ and __init__ are the defaults, in which case it doesn't really matter whether you implement this in __init__ or in __new__, so I arbitrarily chose __new__. I wasn't thinking of your use case at the time though (cooperative super calls to __init__, which still isn't something I engage in on a day-to-day basis). I wonder if the right thing to do wouldn't be to implement the same check both in __init__ and in __new__. Am I makign sense? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-19 02:56 Message: Logged In: YES user_id=849994 Originator: NO I don't really understand either why object_new() checks the arguments, not object_init(): """ static int object_init(PyObject *self, PyObject *args, PyObject *kwds) { return 0; } /* If we don't have a tp_new for a new-style class, new will use this one. Therefore this should take no arguments/keywords. However, this new may also be inherited by objects that define a tp_init but no tp_new. These objects WILL pass argumets to tp_new, because it gets the same args as tp_init. So only allow arguments if we aren't using the default init, in which case we expect init to handle argument parsing. */ static PyObject * object_new(PyTypeObject *type, PyObject *args, PyObject *kwds) { if (type->tp_init == object_init && (PyTuple_GET_SIZE(args) || (kwds && PyDict_Check(kwds) && PyDict_Size(kwds)))) { PyErr_SetString(PyExc_TypeError, "default __new__ takes no parameters"); return NULL; } return type->tp_alloc(type, 0); } """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 From noreply at sourceforge.net Thu Mar 22 02:09:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 18:09:12 -0700 Subject: [ python-Bugs-1681671 ] Python and Indeterminate Forms (Math) Message-ID: Bugs item #1681671, was opened at 2007-03-15 15:28 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681671&group_id=5470 Please note that this 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: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: jehahn (jehahn) Assigned to: Nobody/Anonymous (nobody) Summary: Python and Indeterminate Forms (Math) Initial Comment: Primary example: Python 2.3.5 (#1, Mar 20 2005, 20:38:20) [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> 0 ** 0 1 Per http://mathworld.wolfram.com/Indeterminate.html, 0 ** 0 is an indeterminate form. 0 ** 0 should probably return NaN and NOT 1. Other examples include: Python 2.3.5 (#1, Mar 20 2005, 20:38:20) [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> inf = float("infinity") >>> inf ** 0 1.0 >>> 1 ** inf 1.0 For a few others, Python provides an arguably correct answer of NaN. Examples: Python 2.3.5 (#1, Mar 20 2005, 20:38:20) [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> inf = float("infinity") >>> inf * 0 nan >>> inf / inf nan >>> inf - inf nan And, of course, for the most obvious indeterminate form (0/0) Python does precisely the right thing: Python 2.3.5 (#1, Mar 20 2005, 20:38:20) [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> 0/0 Traceback (most recent call last): File "", line 1, in ? ZeroDivisionError: integer division or modulo by zero It could be argued that the correct thing to do here is to throw an exception - mathematically speaking these forms are about as meaningful as division by zero which Python handles by throwing an exception. (unlike Java and IEEE 754, which do arguably evil things here by returning +/- infinity for the quantity k/0 for all k != 0) Unfortunately, some people doing numerical work may have gotten used to the current Python behavior so the change isn't without risk. And some of the current values are common "conventions" used to simplify certain common issues. (e.g. 0 ** 0 == 1) Moreover, I don't know if this is dependent on platform (having only tried it on a couple of the boxes I have handy.) However, from a mathematical purist's standpoint, Python is doing the wrong thing on these counts. ---------------------------------------------------------------------- >Comment By: Terry J. Reedy (tjreedy) Date: 2007-03-21 21:09 Message: Logged In: YES user_id=593130 Originator: NO Definition: n**m == 1 multiplied by n m times. This definition is consistent with n**m * n**k == n**(m+k). By this definition, the 3 examples you call wrong are correct, though the latter two involving inf are possibly platform dependent. Closing as invalid ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-17 04:20 Message: Logged In: YES user_id=341410 Originator: NO Python's behavior with respect to floating point arithmetic is left to the platform's C floating point libraries. For example, on my Windows machine running Python 2.3.5, float("infinity") raises a ValueError. I would also point out that 0/0 is integer division in Python 2.3.5 . For other examples of platform-specific behavior: Python 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> inf*0 -1.#IND >>> inf**0 1.0 >>> 1**inf Traceback (most recent call last): File "", line 1, in ? ValueError: (33, 'Domain error') >>> inf*0 -1.#IND >>> inf/inf -1.#IND >>> inf-inf -1.#IND >>> So yeah. If you don't like how Python does math, complain to your vendor (Apple) or compile a version of Python with a C floating point library that works the way you want it to. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681671&group_id=5470 From noreply at sourceforge.net Thu Mar 22 04:06:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 20:06:30 -0700 Subject: [ python-Bugs-1685704 ] Command line interface to timeit.py Message-ID: Bugs item #1685704, was opened at 2007-03-21 23:06 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=1685704&group_id=5470 Please note that this 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 Private: No Submitted By: Tim Heaney (theaney) Assigned to: Nobody/Anonymous (nobody) Summary: Command line interface to timeit.py Initial Comment: In the documentation for timeit.py http://docs.python.org/lib/node808.html it says 25.9.1 Command Line Interface When called as a program from the command line, the following form is used: python timeit.py [-n N] [-r N] [-s S] [-t] [-c] [-h] [statement ...] In fact, for this to work we have to put in the full path to timeit.py. Wouldn't it be better to ask Python to search for it with the -m flag? That is, shouldn't that line be python -m timeit [-n N] [-r N] [-s S] [-t] [-c] [-h] [statement ...] instead? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685704&group_id=5470 From noreply at sourceforge.net Thu Mar 22 05:28:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 21:28:59 -0700 Subject: [ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds Message-ID: Bugs item #1683368, was opened at 2007-03-18 23:32 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Guido van Rossum (gvanrossum) Summary: object.__init__ shouldn't allow args/kwds Initial Comment: object.__init__ currently allows any amount of args and keywords even though they're ignored. This is inconsistent with other built-ins, like list, that are stricter about what they'll accept. It's also inconsistent with object.__new__, which does throw if any are provided (if the default __init__ is to be used). To reproduce: object.__init__(object(), foo, bar=3) This is a slight irritation when using cooperative super calling. I'd like each class' __init__ to cherry-pick keyword params it accepts and pass the remaining ones up the chain, but right now I can't rely on object.__init__ to throw if there are remaining keywords by that point. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-22 00:28 Message: Logged In: YES user_id=6380 Originator: NO > I think it would also help if calling a method via super() didn't allow > positional arguments. That's absurd, *except* for __init__(), where it could make sense depending on the style of cooperation used. But not enough to enforce this in the language; in Py3k you will be able to enforce this on a per-class basis. > Having two mixins with the same method name and > without a common parent class is just not sane. Right. This is a cornerstone of cooperative multiple inheritance that sometimes seems to be forgotten; there is a big difference between defining a method and extending a method, and only extending methods can make super calls. The __init__ case is an exception, because there's no requirement that a subclass have a signature compatible with the superclass (if you don't get this, read up on constructors in C++ or Java). ---------------------------------------------------------------------- Comment By: Adam Olsen (rhamphoryncus) Date: 2007-03-21 20:44 Message: Logged In: YES user_id=12364 Originator: NO I think the avoidance of super() is largely *because* of this kind of leniency. Consider this snippet on python 2.3: class Base(object): def __init__(self, foo=None, *args, **kwargs): super(Base, self).__init__(foo, *args, **kwargs) Base(foo='bar') Base('bar', 42) Base('bar', 42, x=7) All pass silently, no error checking. Now consider a python 3.0 version, with a strict object.__init__: class Base: def __init__(self, foo=None, *, y='hi', **kwargs): super(Base, self).__init__(**kwargs) Base(foo='bar') # Valid, accepted Base('bar', 42) # Raises exception Base('bar', x=7) # Raises exception The error checking added by this bug/patch and the error checking added by PEP 3102 (keyword-only arguments) make super a lot more sane. I think it would also help if calling a method via super() didn't allow positional arguments. If the base class's arguments can't be given as keyword args then you probably should call it explicitly, rather than relying on super()'s MRO. I was also going to suggest super() should automagically create empty methods your parent classes don't have, but then I realized you really should have a base class that asserts the lack of such an automagic method: class Base(object): def mymethod(self, myonlyarg='hello world'): assert not hasattr(super(Base, self), 'mymethod') By the time you reach this base class you will have stripped off any extra arguments that your subclasses added, leaving you with nothing to pass up (and nothing to pass to). Having two mixins with the same method name and without a common parent class is just not sane. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2007-03-21 19:16 Message: Logged In: YES user_id=593130 Originator: NO I ask myself, what should I expect from the documentation... >>> object.__init__.__doc__ 'x.__init__(...) initializes x; see x.__class__.__doc__ for signature' >>> object.__class__ >>> type.__doc__ "type(object) -> the object's type\ntype(name, bases, dict) -> a new type" and I still don't know ;-). ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-21 18:48 Message: Logged In: YES user_id=1747060 Originator: YES Holding the strict version for 3 makes sense to me. Let me know if you need anything more on my end... thanks for the fast turnaround. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-21 18:42 Message: Logged In: YES user_id=6380 Originator: NO Well, but since it's been like this for a long time, I don't want to gratuitously break code. At least not in 2.6. So I'm rejecting the stricter patch for 2.6. (However, if you want to submit patches that would fix these breakages anyway, be my guest.) ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-21 18:03 Message: Logged In: YES user_id=1747060 Originator: YES Looks good. I skimmed briefly the tests you mentioned. The issue with test_array appears to be exactly the kind of bug this is intended to identify: it calls array.__init__(...), but array doesn't have its own initializer, so object's is used. I'd guess that the others are failing due to whatever the problem with pickling is (test_descr uses pickling). I haven't looked into that yet. I'm sure cooperative super calling of __init__ isn't all that common (it seems like the mechanism itself isn't used much yet, and may not be until it's done via keyword) but it doesn't seem like such a bad practice, especially when mixins are in the picture. There doesn't seem to be a great alternative. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-20 17:24 Message: Logged In: YES user_id=6380 Originator: NO I should mention that if we can't get the strict version of this in 2.6, we should be able to get it into 3.0. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-20 16:54 Message: Logged In: YES user_id=6380 Originator: NO Here's a stricter version. Unfortunately it breaks a couple of standard modules; this is a confirmation of my doubts whether the style of cooperative super calling of __init__ that you use is really the most common or "best practice". So far I have only fixed string.py (which would otherwise prevent extensions from being built); I haven't looked into why the other tests fail: test_array, test_cpickle, test_descr, test_pickle (and maybe more?). My conclusion: this would probably break too much code to be worth it. So I'll have to revert to the previous version. But anyway, here it is for your perusal. File Added: new_init_strict.patch ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-19 21:27 Message: Logged In: YES user_id=1747060 Originator: YES I think making the check more rigid is a good idea, since this should throw: class a(object): def __init__(self, foo): super(a, self).__init__(foo) def __new__(cls, foo): return object.__new__(cls) a(1) (minor typo in the patch: "solution it" -> "solution is") ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 19:35 Message: Logged In: YES user_id=6380 Originator: NO This smells enough like a new feature that it couldn't go into 2.5. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 19:31 Message: Logged In: YES user_id=6380 Originator: NO Attached is a patch that implements this proposal, adding copious commentary. It doesn't seem to break anything in the test suite. I wonder if we should even make the check more rigid: check the argument list if either the current method *is* overridden or the other one *is not* overridden. This would make super calls check the arguments even if the other method is overridden. What do you think? File Added: new_init.patch ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-19 18:45 Message: Logged In: YES user_id=1747060 Originator: YES Makes sense. I don't think we can ever be completely correct here since we're inferring intent from the presence of __init__/__new__ that's liable to be wrong in some cases, but it's likely correct often enough that it's worth doing. If I understand correctly, we want to be more forgiving iff one of the two methods is used, so it seems like we should be complaining if both are used *or* if neither is used. After all, I could add a __new__ to my coop use case and I'd still want object to complain. If that's the case, both object_new and object_init should be complaining if ((tp->tp_new == object_new && tp->tp_init == object_init) || (tp->tp_new != object_new && tp->tp_init != object_init)). Of course, for the paranoid, there's always the risk that __new__ will modify these class functions and change the outcome :) For instance, if a class had a __new__ and no __init__ and its __new__ changed __new__ back to object.__new__, object_init on that run would be fooled into thinking it's using the defaults for both and would complain. I think this could only be fixed in type_call, which is rather ugly...but then, this *is* a special case of the "call __init__ after __new__" behavior, and we're trying to solve it within the methods themselves. Perhaps this last point is academic enough to be ignored...I don't know why anyone would do this, although the language makes it possible. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 16:01 Message: Logged In: YES user_id=6380 Originator: NO I'll try to explain why I did it this way. I was considering the single inheritance case implementing an Immutable object, which overrides __new__ but has no need to override __init__ (since it's too late to do anything in __init__ for an Immutable object). Since the __init__ still gets called it would be annoying to have to override it just to make the error go away if there was a check in __init__. The other case is overriding __init__ without overriding __new__, which is the most common way of doing Mutable objects; here you wouldn't want __new__ to complain about extra args. So the only time when you'd want complaints is if both __new__ and __init__ are the defaults, in which case it doesn't really matter whether you implement this in __init__ or in __new__, so I arbitrarily chose __new__. I wasn't thinking of your use case at the time though (cooperative super calls to __init__, which still isn't something I engage in on a day-to-day basis). I wonder if the right thing to do wouldn't be to implement the same check both in __init__ and in __new__. Am I makign sense? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-19 04:56 Message: Logged In: YES user_id=849994 Originator: NO I don't really understand either why object_new() checks the arguments, not object_init(): """ static int object_init(PyObject *self, PyObject *args, PyObject *kwds) { return 0; } /* If we don't have a tp_new for a new-style class, new will use this one. Therefore this should take no arguments/keywords. However, this new may also be inherited by objects that define a tp_init but no tp_new. These objects WILL pass argumets to tp_new, because it gets the same args as tp_init. So only allow arguments if we aren't using the default init, in which case we expect init to handle argument parsing. */ static PyObject * object_new(PyTypeObject *type, PyObject *args, PyObject *kwds) { if (type->tp_init == object_init && (PyTuple_GET_SIZE(args) || (kwds && PyDict_Check(kwds) && PyDict_Size(kwds)))) { PyErr_SetString(PyExc_TypeError, "default __new__ takes no parameters"); return NULL; } return type->tp_alloc(type, 0); } """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 From noreply at sourceforge.net Thu Mar 22 05:46:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 21:46:48 -0700 Subject: [ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds Message-ID: Bugs item #1683368, was opened at 2007-03-18 21:32 Message generated for change (Comment added) made by rhamphoryncus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Guido van Rossum (gvanrossum) Summary: object.__init__ shouldn't allow args/kwds Initial Comment: object.__init__ currently allows any amount of args and keywords even though they're ignored. This is inconsistent with other built-ins, like list, that are stricter about what they'll accept. It's also inconsistent with object.__new__, which does throw if any are provided (if the default __init__ is to be used). To reproduce: object.__init__(object(), foo, bar=3) This is a slight irritation when using cooperative super calling. I'd like each class' __init__ to cherry-pick keyword params it accepts and pass the remaining ones up the chain, but right now I can't rely on object.__init__ to throw if there are remaining keywords by that point. ---------------------------------------------------------------------- Comment By: Adam Olsen (rhamphoryncus) Date: 2007-03-21 22:46 Message: Logged In: YES user_id=12364 Originator: NO >> I think it would also help if calling a method via super() didn't allow >> positional arguments. > > That's absurd, *except* for __init__(), where it could make sense > depending on the style of cooperation used. But not enough to enforce this > in the language; in Py3k you will be able to enforce this on a per-class > basis. The vast majority of "positional" arguments can also be given via name. The rare exceptions (primarily C functions) may not cooperate well anyway, so you're trading a relatively obscure limitation for better error detection. Perhaps not that important though, since it could be taught as bad style unless absolutely needed. >> Having two mixins with the same method name and >> without a common parent class is just not sane. > > Right. This is a cornerstone of cooperative multiple inheritance that > sometimes seems to be forgotten; there is a big difference between defining > a method and extending a method, and only extending methods can make super > calls. > > The __init__ case is an exception, because there's no requirement that a > subclass have a signature compatible with the superclass (if you don't get > this, read up on constructors in C++ or Java). I understand the desire for it to be an exception, I fail to see how it actually is one. The namespace/signature conflicts exist just the same. The only way I can see to handle incompatible signatures is to add a flag that says "I am the *ONLY* class allowed to subclass X" (triggering an error if violated), have super() entirely bypass it, and then call X.__init__() directly. Even that doesn't handle X's superclasses being subclassed more than once, and it looks pretty complicated/obscure anyway. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-21 22:28 Message: Logged In: YES user_id=6380 Originator: NO > I think it would also help if calling a method via super() didn't allow > positional arguments. That's absurd, *except* for __init__(), where it could make sense depending on the style of cooperation used. But not enough to enforce this in the language; in Py3k you will be able to enforce this on a per-class basis. > Having two mixins with the same method name and > without a common parent class is just not sane. Right. This is a cornerstone of cooperative multiple inheritance that sometimes seems to be forgotten; there is a big difference between defining a method and extending a method, and only extending methods can make super calls. The __init__ case is an exception, because there's no requirement that a subclass have a signature compatible with the superclass (if you don't get this, read up on constructors in C++ or Java). ---------------------------------------------------------------------- Comment By: Adam Olsen (rhamphoryncus) Date: 2007-03-21 18:44 Message: Logged In: YES user_id=12364 Originator: NO I think the avoidance of super() is largely *because* of this kind of leniency. Consider this snippet on python 2.3: class Base(object): def __init__(self, foo=None, *args, **kwargs): super(Base, self).__init__(foo, *args, **kwargs) Base(foo='bar') Base('bar', 42) Base('bar', 42, x=7) All pass silently, no error checking. Now consider a python 3.0 version, with a strict object.__init__: class Base: def __init__(self, foo=None, *, y='hi', **kwargs): super(Base, self).__init__(**kwargs) Base(foo='bar') # Valid, accepted Base('bar', 42) # Raises exception Base('bar', x=7) # Raises exception The error checking added by this bug/patch and the error checking added by PEP 3102 (keyword-only arguments) make super a lot more sane. I think it would also help if calling a method via super() didn't allow positional arguments. If the base class's arguments can't be given as keyword args then you probably should call it explicitly, rather than relying on super()'s MRO. I was also going to suggest super() should automagically create empty methods your parent classes don't have, but then I realized you really should have a base class that asserts the lack of such an automagic method: class Base(object): def mymethod(self, myonlyarg='hello world'): assert not hasattr(super(Base, self), 'mymethod') By the time you reach this base class you will have stripped off any extra arguments that your subclasses added, leaving you with nothing to pass up (and nothing to pass to). Having two mixins with the same method name and without a common parent class is just not sane. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2007-03-21 17:16 Message: Logged In: YES user_id=593130 Originator: NO I ask myself, what should I expect from the documentation... >>> object.__init__.__doc__ 'x.__init__(...) initializes x; see x.__class__.__doc__ for signature' >>> object.__class__ >>> type.__doc__ "type(object) -> the object's type\ntype(name, bases, dict) -> a new type" and I still don't know ;-). ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-21 16:48 Message: Logged In: YES user_id=1747060 Originator: YES Holding the strict version for 3 makes sense to me. Let me know if you need anything more on my end... thanks for the fast turnaround. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-21 16:42 Message: Logged In: YES user_id=6380 Originator: NO Well, but since it's been like this for a long time, I don't want to gratuitously break code. At least not in 2.6. So I'm rejecting the stricter patch for 2.6. (However, if you want to submit patches that would fix these breakages anyway, be my guest.) ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-21 16:03 Message: Logged In: YES user_id=1747060 Originator: YES Looks good. I skimmed briefly the tests you mentioned. The issue with test_array appears to be exactly the kind of bug this is intended to identify: it calls array.__init__(...), but array doesn't have its own initializer, so object's is used. I'd guess that the others are failing due to whatever the problem with pickling is (test_descr uses pickling). I haven't looked into that yet. I'm sure cooperative super calling of __init__ isn't all that common (it seems like the mechanism itself isn't used much yet, and may not be until it's done via keyword) but it doesn't seem like such a bad practice, especially when mixins are in the picture. There doesn't seem to be a great alternative. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-20 15:24 Message: Logged In: YES user_id=6380 Originator: NO I should mention that if we can't get the strict version of this in 2.6, we should be able to get it into 3.0. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-20 14:54 Message: Logged In: YES user_id=6380 Originator: NO Here's a stricter version. Unfortunately it breaks a couple of standard modules; this is a confirmation of my doubts whether the style of cooperative super calling of __init__ that you use is really the most common or "best practice". So far I have only fixed string.py (which would otherwise prevent extensions from being built); I haven't looked into why the other tests fail: test_array, test_cpickle, test_descr, test_pickle (and maybe more?). My conclusion: this would probably break too much code to be worth it. So I'll have to revert to the previous version. But anyway, here it is for your perusal. File Added: new_init_strict.patch ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-19 19:27 Message: Logged In: YES user_id=1747060 Originator: YES I think making the check more rigid is a good idea, since this should throw: class a(object): def __init__(self, foo): super(a, self).__init__(foo) def __new__(cls, foo): return object.__new__(cls) a(1) (minor typo in the patch: "solution it" -> "solution is") ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 17:35 Message: Logged In: YES user_id=6380 Originator: NO This smells enough like a new feature that it couldn't go into 2.5. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 17:31 Message: Logged In: YES user_id=6380 Originator: NO Attached is a patch that implements this proposal, adding copious commentary. It doesn't seem to break anything in the test suite. I wonder if we should even make the check more rigid: check the argument list if either the current method *is* overridden or the other one *is not* overridden. This would make super calls check the arguments even if the other method is overridden. What do you think? File Added: new_init.patch ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-19 16:45 Message: Logged In: YES user_id=1747060 Originator: YES Makes sense. I don't think we can ever be completely correct here since we're inferring intent from the presence of __init__/__new__ that's liable to be wrong in some cases, but it's likely correct often enough that it's worth doing. If I understand correctly, we want to be more forgiving iff one of the two methods is used, so it seems like we should be complaining if both are used *or* if neither is used. After all, I could add a __new__ to my coop use case and I'd still want object to complain. If that's the case, both object_new and object_init should be complaining if ((tp->tp_new == object_new && tp->tp_init == object_init) || (tp->tp_new != object_new && tp->tp_init != object_init)). Of course, for the paranoid, there's always the risk that __new__ will modify these class functions and change the outcome :) For instance, if a class had a __new__ and no __init__ and its __new__ changed __new__ back to object.__new__, object_init on that run would be fooled into thinking it's using the defaults for both and would complain. I think this could only be fixed in type_call, which is rather ugly...but then, this *is* a special case of the "call __init__ after __new__" behavior, and we're trying to solve it within the methods themselves. Perhaps this last point is academic enough to be ignored...I don't know why anyone would do this, although the language makes it possible. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 14:01 Message: Logged In: YES user_id=6380 Originator: NO I'll try to explain why I did it this way. I was considering the single inheritance case implementing an Immutable object, which overrides __new__ but has no need to override __init__ (since it's too late to do anything in __init__ for an Immutable object). Since the __init__ still gets called it would be annoying to have to override it just to make the error go away if there was a check in __init__. The other case is overriding __init__ without overriding __new__, which is the most common way of doing Mutable objects; here you wouldn't want __new__ to complain about extra args. So the only time when you'd want complaints is if both __new__ and __init__ are the defaults, in which case it doesn't really matter whether you implement this in __init__ or in __new__, so I arbitrarily chose __new__. I wasn't thinking of your use case at the time though (cooperative super calls to __init__, which still isn't something I engage in on a day-to-day basis). I wonder if the right thing to do wouldn't be to implement the same check both in __init__ and in __new__. Am I makign sense? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-19 02:56 Message: Logged In: YES user_id=849994 Originator: NO I don't really understand either why object_new() checks the arguments, not object_init(): """ static int object_init(PyObject *self, PyObject *args, PyObject *kwds) { return 0; } /* If we don't have a tp_new for a new-style class, new will use this one. Therefore this should take no arguments/keywords. However, this new may also be inherited by objects that define a tp_init but no tp_new. These objects WILL pass argumets to tp_new, because it gets the same args as tp_init. So only allow arguments if we aren't using the default init, in which case we expect init to handle argument parsing. */ static PyObject * object_new(PyTypeObject *type, PyObject *args, PyObject *kwds) { if (type->tp_init == object_init && (PyTuple_GET_SIZE(args) || (kwds && PyDict_Check(kwds) && PyDict_Size(kwds)))) { PyErr_SetString(PyExc_TypeError, "default __new__ takes no parameters"); return NULL; } return type->tp_alloc(type, 0); } """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 From noreply at sourceforge.net Thu Mar 22 08:12:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 00:12:44 -0700 Subject: [ python-Bugs-1685773 ] tarfile file names under win32 Message-ID: Bugs item #1685773, was opened at 2007-03-22 08:12 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=1685773&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ralf (indi4source) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile file names under win32 Initial Comment: the tarfile module uses normpath() to store the file name in the archive. Under win32 this results in pathes with backslashes and possible a leading "\". This confuses the unix tar command. I suppose the following commands instead of just normpath(): path = normpath (path) path = path.replace ("\\", "/") path = path.lstrip ("/") ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685773&group_id=5470 From noreply at sourceforge.net Thu Mar 22 08:23:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 00:23:25 -0700 Subject: [ python-Bugs-1685775 ] msvccompiler.py doesn't recongnize VS2005 Message-ID: Bugs item #1685775, was opened at 2007-03-22 07: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=1685775&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Minmin Gong (gongminmin) Assigned to: Nobody/Anonymous (nobody) Summary: msvccompiler.py doesn't recongnize VS2005 Initial Comment: I'm trying to compile some python extensions by VS2005. However, it seems that msvccompiler.py doesn't recongnize VS2005. Only VC6/VS2003 is supported. When will distutils fix this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685775&group_id=5470 From noreply at sourceforge.net Thu Mar 22 08:57:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 00:57:12 -0700 Subject: [ python-Bugs-1685773 ] tarfile file names under win32 Message-ID: Bugs item #1685773, was opened at 2007-03-22 08:12 Message generated for change (Settings changed) made by gustaebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685773&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ralf (indi4source) >Assigned to: Lars Gust?bel (gustaebel) Summary: tarfile file names under win32 Initial Comment: the tarfile module uses normpath() to store the file name in the archive. Under win32 this results in pathes with backslashes and possible a leading "\". This confuses the unix tar command. I suppose the following commands instead of just normpath(): path = normpath (path) path = path.replace ("\\", "/") path = path.lstrip ("/") ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685773&group_id=5470 From noreply at sourceforge.net Thu Mar 22 09:06:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 01:06:20 -0700 Subject: [ python-Bugs-1685704 ] Command line interface to timeit.py Message-ID: Bugs item #1685704, was opened at 2007-03-22 03:06 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685704&group_id=5470 Please note that this 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 Private: No Submitted By: Tim Heaney (theaney) Assigned to: Nobody/Anonymous (nobody) Summary: Command line interface to timeit.py Initial Comment: In the documentation for timeit.py http://docs.python.org/lib/node808.html it says 25.9.1 Command Line Interface When called as a program from the command line, the following form is used: python timeit.py [-n N] [-r N] [-s S] [-t] [-c] [-h] [statement ...] In fact, for this to work we have to put in the full path to timeit.py. Wouldn't it be better to ask Python to search for it with the -m flag? That is, shouldn't that line be python -m timeit [-n N] [-r N] [-s S] [-t] [-c] [-h] [statement ...] instead? ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-22 08:06 Message: Logged In: YES user_id=849994 Originator: NO Yes, this is indeed the modern and better thing to do. Fixed in rev. 54524, 54525 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685704&group_id=5470 From noreply at sourceforge.net Thu Mar 22 14:06:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 06:06:29 -0700 Subject: [ python-Feature Requests-1673203 ] add identity function Message-ID: Feature Requests item #1673203, was opened at 2007-03-03 19:21 Message generated for change (Comment added) made by twobitsprite You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 Please note that this 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 Private: No Submitted By: paul rubin (phr) Assigned to: Raymond Hettinger (rhettinger) Summary: add identity function Initial Comment: Requested and assigned to Raymond at his suggestion: http://groups.google.com/group/comp.lang.python/msg/603870361743c85c There should be an identify function identity(x)=x. I suggest it also take and ignore an optional second arg: identity(x1,x2)=x1. The second arg can be useful in some generator expressions: foo = (x for x in bar if condition(x) and identity(True, memoize(x)) That allows calling memoize (or some other function) on the selected elements in the genexp, and disposing of the returned value. It's sort of like the const function (K combinator) to go along with the identity function's I combinator. OK, the above is not really in the functional spirit, but it's been useful. There could conceivably be also an actual const function const(k)=partial(identity,k) but I can't remember needing that in Python code. The two-arg identity function (uncurried version of const) is probably enough. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 09:06 Message: Logged In: YES user_id=1679533 Originator: NO I also would like to have a built-in identity function (in fact, I found this by googling "python identity function"). My use-case is a bit different. I ofter find myself wanting to simply specify a function for be used in a loop, something like: def f(items): if something: wrapper = int else: wrapper = identity for item in items: yield wrapper(item) of course, usually it's a bit more complex than that, but you get the idea... and I supposed its actually more like the previous use-case than I thought. I realize I could just use "lambda x: x", but I feel that comes with an unnecessary performance impact for something so trivial. I don't know how much python does to compile built-in functions, but I imagine that the identity function can be mostly optimized out at compile time if it were built-in. Just my two-cents. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-19 15:57 Message: Logged In: YES user_id=835142 Originator: NO I have just realized that the requested functionality is known in C as the comma operator. I often find myself writing "return Py_INCREF(o),o;" in my C code, but I cannot really defend that idiom against "Py_INCREF(o); return o;" alternative. My personal reason is entirely C-specific, if followed an if(), the first form does not require curly braces. In any case, comma operator can be emulated in python as exp1,expr2,expr3 -> (exp1,expr2,expr3)[-1] Since multi-argument "identity" is likely to be rejected, my proposal to alter the order of arguments is moot. My other suggestion that with identity, map(None, ..) should be deprecated in favor of map(identity, ..) is probably an arument against the identity proposal now. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-19 15:05 Message: Logged In: YES user_id=1344176 Originator: NO I can see adding the 1-argument form to operator or functools (as it's useful in functional programming), but the 2-argument form you've suggested is right out. If you really feel the need to torture a "for" loop into a genexp/listcomp like that, foo = (x for x in bar if condition(x) and [memoize(x)]) does the same thing using today's capabilities. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-12 16:06 Message: Logged In: YES user_id=341410 Originator: NO Not all x line functions should be built into Python. Further, Python's standard syntax offers an infix operator that does the same thing (though in slightly different order as described below, you can reorder with minimal effort). identity(X, Y) -> (Y and False) or X Also, the only use-case that you are provided and that I can imagine, are examples like you provide where one is changing state within a statement (if, elif, while, etc.) or expression (generator, list comprehension, conditional, etc.). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 09:21 Message: Logged In: YES user_id=835142 Originator: NO 1. If this proposal is accepted, it will make sense to deprecate the use of None as an identity function in map: >>> map(None, range(10)) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] 2. Some other languages have an dyadic identity function that returns the *second* argument. For example, K has : primitive: identity:(:) identity[1;2] 2 The rationale in K is that it is useful in an ammed function that replaces entries of an an array with a result of a dyadic function applied to the old and the supplied value and it is natural to have old value first: @[1 2 3;1;-;20] 1 -18 3 @[1 2 3;1;:;20] 1 20 3 This rationale does not apply to Python, but in the absence of other reasons to choose the order of arguments, Python may as well follow the precedent. Does anyone know a less exotic language that has a dyadic identity? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 From noreply at sourceforge.net Thu Mar 22 14:10:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 06:10:31 -0700 Subject: [ python-Bugs-1685962 ] socket.getaddrinfo() should take an address tuple. Message-ID: Bugs item #1685962, was opened at 2007-03-22 13:10 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=1685962&group_id=5470 Please note that this 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: Feature Request Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alan Kennedy (amak) Assigned to: Nobody/Anonymous (nobody) Summary: socket.getaddrinfo() should take an address tuple. Initial Comment: The getaddrinfo call should not take separate host and port parameters. Instead, it should take the same address tuples as every other python socket function, i.e. it's signature should be getaddrinfo( address_tuple[, family[, socktype[, proto[, flags]]]]) This is because all python socket calls take a (host, port) tuple as an address. However, functions that take a tuple are then forced to unpack that tuple in order to call getaddrinfo. The problem is that this is error prone. Consider the following code def my_trivial_socket_function(address_tuple, a=None): host, port = address_tuple for result in getaddrinfo(host, port, 0, 0, 0): whatever(*result) I can then call this function like so, and get a weird error my_trivial_socket_function("lo", 80) because the outcome of host, port = "lo" is host = "l" ; port = "o" One solution to this problem is to force every socket function, trivial or otherwise, to do error checking on the address tuple, like so def my_trivial_socket_function(address_tuple,a=None): assert type(address_tuple) is type( () ) assert type(address_tuple[0]) is type("") assert type(address_tuple[1]) is type(0) host, port = address_tuple for result in getaddrinfo(host, port, 0, 0, 0): pass But since the only reason the function has to unpack the tuple is to pass it to getaddrinfo, then the correct solution is to make getaddrinfo accept the same address format as every other python socket function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685962&group_id=5470 From noreply at sourceforge.net Thu Mar 22 18:00:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 10:00:09 -0700 Subject: [ python-Bugs-1686200 ] logging package failure for NTEventLogHandler Message-ID: Bugs item #1686200, was opened at 2007-03-22 17:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686200&group_id=5470 Please note that this 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 Private: No Submitted By: j vickroy (jvickroy) Assigned to: Nobody/Anonymous (nobody) Summary: logging package failure for NTEventLogHandler Initial Comment: When using a configuration file to initialize a logger, a failure occurs in the logging.config.fileConfig() procedure such that the NTEventLogHandler is not created. The failure is not observed when the NTEventLogHandler is explicitly defined in a script. The attached script and two configuration initialization files demonstrate the failure as seen on a Microsoft Windows XP Pro computer running service pack 2 and Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)]. DETAILED DESCRIPTION: When the attached script is run with EventLog.ini, on my Windows XP computer, the failure appears to occur at line 118: h = apply(klass, args) in File "C:\Python24\lib\logging\config.py" because for: klass: logging.handlers.NTEventLogHandler local variable *args* is: ('logging.config.fileConfig bug test') after line 116: args = cp.get(sectname, "args") but local variable *args* is: logging.config.fileConfig bug test after line 117: args = eval(args, vars(logging)) The behavior for the other two handlers is as follows: klass = logging.StreamHandler args is: (sys.stdout,) ... after line 116 args is: (', mode 'w' at 0x00A1E068>,) ... after line 117 klass = logging.handlers.TimedRotatingFileHandler args is: ('fileConfig-test.log', 'midnight', 1, 3) ... after line 116 args is: ('fileConfig-test.log', 'midnight', 1, 3) ... after line 117 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686200&group_id=5470 From noreply at sourceforge.net Thu Mar 22 18:49:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 10:49:10 -0700 Subject: [ python-Feature Requests-1673203 ] add identity function Message-ID: Feature Requests item #1673203, was opened at 2007-03-03 16:21 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 Please note that this 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 Private: No Submitted By: paul rubin (phr) Assigned to: Raymond Hettinger (rhettinger) Summary: add identity function Initial Comment: Requested and assigned to Raymond at his suggestion: http://groups.google.com/group/comp.lang.python/msg/603870361743c85c There should be an identify function identity(x)=x. I suggest it also take and ignore an optional second arg: identity(x1,x2)=x1. The second arg can be useful in some generator expressions: foo = (x for x in bar if condition(x) and identity(True, memoize(x)) That allows calling memoize (or some other function) on the selected elements in the genexp, and disposing of the returned value. It's sort of like the const function (K combinator) to go along with the identity function's I combinator. OK, the above is not really in the functional spirit, but it's been useful. There could conceivably be also an actual const function const(k)=partial(identity,k) but I can't remember needing that in Python code. The two-arg identity function (uncurried version of const) is probably enough. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-22 10:49 Message: Logged In: YES user_id=341410 Originator: NO twobitsprite: your use-case is different from that of others. While you could use an identity function for your purposes, a lambda would work just fine. Regardless, there is call overhead, which can only be reduced by not performing a call at all. In terms of an identity function versus tuple creation and indexing as per belopolsky's suggestion... >>> timeit.Timer("x(1+2,3+4)", "x = lambda *args:args[-1]").timeit() 0.99381552025397468 >>> timeit.Timer("(1+2,3+4)[-1]", "").timeit() 0.49153579156927663 Tuple is faster. Just use a tuple. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 06:06 Message: Logged In: YES user_id=1679533 Originator: NO I also would like to have a built-in identity function (in fact, I found this by googling "python identity function"). My use-case is a bit different. I ofter find myself wanting to simply specify a function for be used in a loop, something like: def f(items): if something: wrapper = int else: wrapper = identity for item in items: yield wrapper(item) of course, usually it's a bit more complex than that, but you get the idea... and I supposed its actually more like the previous use-case than I thought. I realize I could just use "lambda x: x", but I feel that comes with an unnecessary performance impact for something so trivial. I don't know how much python does to compile built-in functions, but I imagine that the identity function can be mostly optimized out at compile time if it were built-in. Just my two-cents. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-19 12:57 Message: Logged In: YES user_id=835142 Originator: NO I have just realized that the requested functionality is known in C as the comma operator. I often find myself writing "return Py_INCREF(o),o;" in my C code, but I cannot really defend that idiom against "Py_INCREF(o); return o;" alternative. My personal reason is entirely C-specific, if followed an if(), the first form does not require curly braces. In any case, comma operator can be emulated in python as exp1,expr2,expr3 -> (exp1,expr2,expr3)[-1] Since multi-argument "identity" is likely to be rejected, my proposal to alter the order of arguments is moot. My other suggestion that with identity, map(None, ..) should be deprecated in favor of map(identity, ..) is probably an arument against the identity proposal now. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-19 12:05 Message: Logged In: YES user_id=1344176 Originator: NO I can see adding the 1-argument form to operator or functools (as it's useful in functional programming), but the 2-argument form you've suggested is right out. If you really feel the need to torture a "for" loop into a genexp/listcomp like that, foo = (x for x in bar if condition(x) and [memoize(x)]) does the same thing using today's capabilities. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-12 13:06 Message: Logged In: YES user_id=341410 Originator: NO Not all x line functions should be built into Python. Further, Python's standard syntax offers an infix operator that does the same thing (though in slightly different order as described below, you can reorder with minimal effort). identity(X, Y) -> (Y and False) or X Also, the only use-case that you are provided and that I can imagine, are examples like you provide where one is changing state within a statement (if, elif, while, etc.) or expression (generator, list comprehension, conditional, etc.). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 06:21 Message: Logged In: YES user_id=835142 Originator: NO 1. If this proposal is accepted, it will make sense to deprecate the use of None as an identity function in map: >>> map(None, range(10)) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] 2. Some other languages have an dyadic identity function that returns the *second* argument. For example, K has : primitive: identity:(:) identity[1;2] 2 The rationale in K is that it is useful in an ammed function that replaces entries of an an array with a result of a dyadic function applied to the old and the supplied value and it is natural to have old value first: @[1 2 3;1;-;20] 1 -18 3 @[1 2 3;1;:;20] 1 20 3 This rationale does not apply to Python, but in the absence of other reasons to choose the order of arguments, Python may as well follow the precedent. Does anyone know a less exotic language that has a dyadic identity? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 From noreply at sourceforge.net Thu Mar 22 20:06:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 12:06:07 -0700 Subject: [ python-Feature Requests-1673203 ] add identity function Message-ID: Feature Requests item #1673203, was opened at 2007-03-03 19:21 Message generated for change (Comment added) made by twobitsprite You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 Please note that this 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 Private: No Submitted By: paul rubin (phr) Assigned to: Raymond Hettinger (rhettinger) Summary: add identity function Initial Comment: Requested and assigned to Raymond at his suggestion: http://groups.google.com/group/comp.lang.python/msg/603870361743c85c There should be an identify function identity(x)=x. I suggest it also take and ignore an optional second arg: identity(x1,x2)=x1. The second arg can be useful in some generator expressions: foo = (x for x in bar if condition(x) and identity(True, memoize(x)) That allows calling memoize (or some other function) on the selected elements in the genexp, and disposing of the returned value. It's sort of like the const function (K combinator) to go along with the identity function's I combinator. OK, the above is not really in the functional spirit, but it's been useful. There could conceivably be also an actual const function const(k)=partial(identity,k) but I can't remember needing that in Python code. The two-arg identity function (uncurried version of const) is probably enough. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 15:06 Message: Logged In: YES user_id=1679533 Originator: NO It still feels like an ugly hack for something so simple. I can't believe there is such resistance for something as trivial as a function which returns it's first argument. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-22 13:49 Message: Logged In: YES user_id=341410 Originator: NO twobitsprite: your use-case is different from that of others. While you could use an identity function for your purposes, a lambda would work just fine. Regardless, there is call overhead, which can only be reduced by not performing a call at all. In terms of an identity function versus tuple creation and indexing as per belopolsky's suggestion... >>> timeit.Timer("x(1+2,3+4)", "x = lambda *args:args[-1]").timeit() 0.99381552025397468 >>> timeit.Timer("(1+2,3+4)[-1]", "").timeit() 0.49153579156927663 Tuple is faster. Just use a tuple. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 09:06 Message: Logged In: YES user_id=1679533 Originator: NO I also would like to have a built-in identity function (in fact, I found this by googling "python identity function"). My use-case is a bit different. I ofter find myself wanting to simply specify a function for be used in a loop, something like: def f(items): if something: wrapper = int else: wrapper = identity for item in items: yield wrapper(item) of course, usually it's a bit more complex than that, but you get the idea... and I supposed its actually more like the previous use-case than I thought. I realize I could just use "lambda x: x", but I feel that comes with an unnecessary performance impact for something so trivial. I don't know how much python does to compile built-in functions, but I imagine that the identity function can be mostly optimized out at compile time if it were built-in. Just my two-cents. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-19 15:57 Message: Logged In: YES user_id=835142 Originator: NO I have just realized that the requested functionality is known in C as the comma operator. I often find myself writing "return Py_INCREF(o),o;" in my C code, but I cannot really defend that idiom against "Py_INCREF(o); return o;" alternative. My personal reason is entirely C-specific, if followed an if(), the first form does not require curly braces. In any case, comma operator can be emulated in python as exp1,expr2,expr3 -> (exp1,expr2,expr3)[-1] Since multi-argument "identity" is likely to be rejected, my proposal to alter the order of arguments is moot. My other suggestion that with identity, map(None, ..) should be deprecated in favor of map(identity, ..) is probably an arument against the identity proposal now. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-19 15:05 Message: Logged In: YES user_id=1344176 Originator: NO I can see adding the 1-argument form to operator or functools (as it's useful in functional programming), but the 2-argument form you've suggested is right out. If you really feel the need to torture a "for" loop into a genexp/listcomp like that, foo = (x for x in bar if condition(x) and [memoize(x)]) does the same thing using today's capabilities. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-12 16:06 Message: Logged In: YES user_id=341410 Originator: NO Not all x line functions should be built into Python. Further, Python's standard syntax offers an infix operator that does the same thing (though in slightly different order as described below, you can reorder with minimal effort). identity(X, Y) -> (Y and False) or X Also, the only use-case that you are provided and that I can imagine, are examples like you provide where one is changing state within a statement (if, elif, while, etc.) or expression (generator, list comprehension, conditional, etc.). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 09:21 Message: Logged In: YES user_id=835142 Originator: NO 1. If this proposal is accepted, it will make sense to deprecate the use of None as an identity function in map: >>> map(None, range(10)) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] 2. Some other languages have an dyadic identity function that returns the *second* argument. For example, K has : primitive: identity:(:) identity[1;2] 2 The rationale in K is that it is useful in an ammed function that replaces entries of an an array with a result of a dyadic function applied to the old and the supplied value and it is natural to have old value first: @[1 2 3;1;-;20] 1 -18 3 @[1 2 3;1;:;20] 1 20 3 This rationale does not apply to Python, but in the absence of other reasons to choose the order of arguments, Python may as well follow the precedent. Does anyone know a less exotic language that has a dyadic identity? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 From noreply at sourceforge.net Thu Mar 22 20:25:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 12:25:15 -0700 Subject: [ python-Feature Requests-1673203 ] add identity function Message-ID: Feature Requests item #1673203, was opened at 2007-03-03 19:21 Message generated for change (Comment added) made by twobitsprite You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 Please note that this 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 Private: No Submitted By: paul rubin (phr) Assigned to: Raymond Hettinger (rhettinger) Summary: add identity function Initial Comment: Requested and assigned to Raymond at his suggestion: http://groups.google.com/group/comp.lang.python/msg/603870361743c85c There should be an identify function identity(x)=x. I suggest it also take and ignore an optional second arg: identity(x1,x2)=x1. The second arg can be useful in some generator expressions: foo = (x for x in bar if condition(x) and identity(True, memoize(x)) That allows calling memoize (or some other function) on the selected elements in the genexp, and disposing of the returned value. It's sort of like the const function (K combinator) to go along with the identity function's I combinator. OK, the above is not really in the functional spirit, but it's been useful. There could conceivably be also an actual const function const(k)=partial(identity,k) but I can't remember needing that in Python code. The two-arg identity function (uncurried version of const) is probably enough. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 15:25 Message: Logged In: YES user_id=1679533 Originator: NO Also, map like functions start to look a bit ugly (of course, this is overly simplistic, but serves as an example): def my_map(func, items): acc = [] for item in items: if func == None: acc.append(item) else: acc.append(func(item)) return acc which has the obvious overhead of a test for every iteration. Of course, you could just make two versions of the for loop, one which applies and one which doesn't, but that immetiately violates once-and-only-once and also forces the function to be overly concerned with what it is passed. this is _much_ cleaner: def my_map2(func, items): return [func(i) for i in items] and the user of the function can simply pass as and this keeps the details of what to do with the items outside of the function. Without identity, whenever I want to allow the user to inject code to modify data, I have to account for the fact that they might want to do nothing with it, and so I have to test for None constantly. This is simply bad practice and, IMHO, violates everything python stands for, which is elegance, simplicity and "batteries included", right? If you want I patch, I can try to provide one; however I have very minimal knowledge of how the vm works, and I've only looked at the code a couple of times. In fact, I might even go ahead and do that, it can't be that difficult. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 15:06 Message: Logged In: YES user_id=1679533 Originator: NO It still feels like an ugly hack for something so simple. I can't believe there is such resistance for something as trivial as a function which returns it's first argument. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-22 13:49 Message: Logged In: YES user_id=341410 Originator: NO twobitsprite: your use-case is different from that of others. While you could use an identity function for your purposes, a lambda would work just fine. Regardless, there is call overhead, which can only be reduced by not performing a call at all. In terms of an identity function versus tuple creation and indexing as per belopolsky's suggestion... >>> timeit.Timer("x(1+2,3+4)", "x = lambda *args:args[-1]").timeit() 0.99381552025397468 >>> timeit.Timer("(1+2,3+4)[-1]", "").timeit() 0.49153579156927663 Tuple is faster. Just use a tuple. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 09:06 Message: Logged In: YES user_id=1679533 Originator: NO I also would like to have a built-in identity function (in fact, I found this by googling "python identity function"). My use-case is a bit different. I ofter find myself wanting to simply specify a function for be used in a loop, something like: def f(items): if something: wrapper = int else: wrapper = identity for item in items: yield wrapper(item) of course, usually it's a bit more complex than that, but you get the idea... and I supposed its actually more like the previous use-case than I thought. I realize I could just use "lambda x: x", but I feel that comes with an unnecessary performance impact for something so trivial. I don't know how much python does to compile built-in functions, but I imagine that the identity function can be mostly optimized out at compile time if it were built-in. Just my two-cents. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-19 15:57 Message: Logged In: YES user_id=835142 Originator: NO I have just realized that the requested functionality is known in C as the comma operator. I often find myself writing "return Py_INCREF(o),o;" in my C code, but I cannot really defend that idiom against "Py_INCREF(o); return o;" alternative. My personal reason is entirely C-specific, if followed an if(), the first form does not require curly braces. In any case, comma operator can be emulated in python as exp1,expr2,expr3 -> (exp1,expr2,expr3)[-1] Since multi-argument "identity" is likely to be rejected, my proposal to alter the order of arguments is moot. My other suggestion that with identity, map(None, ..) should be deprecated in favor of map(identity, ..) is probably an arument against the identity proposal now. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-19 15:05 Message: Logged In: YES user_id=1344176 Originator: NO I can see adding the 1-argument form to operator or functools (as it's useful in functional programming), but the 2-argument form you've suggested is right out. If you really feel the need to torture a "for" loop into a genexp/listcomp like that, foo = (x for x in bar if condition(x) and [memoize(x)]) does the same thing using today's capabilities. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-12 16:06 Message: Logged In: YES user_id=341410 Originator: NO Not all x line functions should be built into Python. Further, Python's standard syntax offers an infix operator that does the same thing (though in slightly different order as described below, you can reorder with minimal effort). identity(X, Y) -> (Y and False) or X Also, the only use-case that you are provided and that I can imagine, are examples like you provide where one is changing state within a statement (if, elif, while, etc.) or expression (generator, list comprehension, conditional, etc.). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 09:21 Message: Logged In: YES user_id=835142 Originator: NO 1. If this proposal is accepted, it will make sense to deprecate the use of None as an identity function in map: >>> map(None, range(10)) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] 2. Some other languages have an dyadic identity function that returns the *second* argument. For example, K has : primitive: identity:(:) identity[1;2] 2 The rationale in K is that it is useful in an ammed function that replaces entries of an an array with a result of a dyadic function applied to the old and the supplied value and it is natural to have old value first: @[1 2 3;1;-;20] 1 -18 3 @[1 2 3;1;:;20] 1 20 3 This rationale does not apply to Python, but in the absence of other reasons to choose the order of arguments, Python may as well follow the precedent. Does anyone know a less exotic language that has a dyadic identity? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 From noreply at sourceforge.net Thu Mar 22 20:32:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 12:32:56 -0700 Subject: [ python-Feature Requests-1673203 ] add identity function Message-ID: Feature Requests item #1673203, was opened at 2007-03-03 19:21 Message generated for change (Comment added) made by belopolsky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 Please note that this 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 Private: No Submitted By: paul rubin (phr) Assigned to: Raymond Hettinger (rhettinger) Summary: add identity function Initial Comment: Requested and assigned to Raymond at his suggestion: http://groups.google.com/group/comp.lang.python/msg/603870361743c85c There should be an identify function identity(x)=x. I suggest it also take and ignore an optional second arg: identity(x1,x2)=x1. The second arg can be useful in some generator expressions: foo = (x for x in bar if condition(x) and identity(True, memoize(x)) That allows calling memoize (or some other function) on the selected elements in the genexp, and disposing of the returned value. It's sort of like the const function (K combinator) to go along with the identity function's I combinator. OK, the above is not really in the functional spirit, but it's been useful. There could conceivably be also an actual const function const(k)=partial(identity,k) but I can't remember needing that in Python code. The two-arg identity function (uncurried version of const) is probably enough. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-22 15:32 Message: Logged In: YES user_id=835142 Originator: NO > I can't believe there is such resistance for something > as trivial as a function which returns it's first argument. The resistance is precisely because it is so trivial. As josiahcarlson suggested before, "Not all x line functions should be built into Python." Compare the following two alternatives: def identity(*args): return args[0] and from functools import identity The first option is only slightly longer than the second, but it is actually much clearer. With the second option, it is not obvious that identity takes an arbitrary number of arguments and if it does, which argument it will return. The only advantage is that if coded in C, functools.identity may be slightly faster. However, given that >>> dis(lambda x: x) 1 0 LOAD_FAST 0 (x) 3 RETURN_VALUE I am not sure a C coded identity can significantly beat it. The real savings would come if python compiler could optimize away calls to identity altogether, but nobody has explained how that could be done or why it would be easier to optimize away identity that lambda x:x. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 15:25 Message: Logged In: YES user_id=1679533 Originator: NO Also, map like functions start to look a bit ugly (of course, this is overly simplistic, but serves as an example): def my_map(func, items): acc = [] for item in items: if func == None: acc.append(item) else: acc.append(func(item)) return acc which has the obvious overhead of a test for every iteration. Of course, you could just make two versions of the for loop, one which applies and one which doesn't, but that immetiately violates once-and-only-once and also forces the function to be overly concerned with what it is passed. this is _much_ cleaner: def my_map2(func, items): return [func(i) for i in items] and the user of the function can simply pass as and this keeps the details of what to do with the items outside of the function. Without identity, whenever I want to allow the user to inject code to modify data, I have to account for the fact that they might want to do nothing with it, and so I have to test for None constantly. This is simply bad practice and, IMHO, violates everything python stands for, which is elegance, simplicity and "batteries included", right? If you want I patch, I can try to provide one; however I have very minimal knowledge of how the vm works, and I've only looked at the code a couple of times. In fact, I might even go ahead and do that, it can't be that difficult. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 15:06 Message: Logged In: YES user_id=1679533 Originator: NO It still feels like an ugly hack for something so simple. I can't believe there is such resistance for something as trivial as a function which returns it's first argument. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-22 13:49 Message: Logged In: YES user_id=341410 Originator: NO twobitsprite: your use-case is different from that of others. While you could use an identity function for your purposes, a lambda would work just fine. Regardless, there is call overhead, which can only be reduced by not performing a call at all. In terms of an identity function versus tuple creation and indexing as per belopolsky's suggestion... >>> timeit.Timer("x(1+2,3+4)", "x = lambda *args:args[-1]").timeit() 0.99381552025397468 >>> timeit.Timer("(1+2,3+4)[-1]", "").timeit() 0.49153579156927663 Tuple is faster. Just use a tuple. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 09:06 Message: Logged In: YES user_id=1679533 Originator: NO I also would like to have a built-in identity function (in fact, I found this by googling "python identity function"). My use-case is a bit different. I ofter find myself wanting to simply specify a function for be used in a loop, something like: def f(items): if something: wrapper = int else: wrapper = identity for item in items: yield wrapper(item) of course, usually it's a bit more complex than that, but you get the idea... and I supposed its actually more like the previous use-case than I thought. I realize I could just use "lambda x: x", but I feel that comes with an unnecessary performance impact for something so trivial. I don't know how much python does to compile built-in functions, but I imagine that the identity function can be mostly optimized out at compile time if it were built-in. Just my two-cents. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-19 15:57 Message: Logged In: YES user_id=835142 Originator: NO I have just realized that the requested functionality is known in C as the comma operator. I often find myself writing "return Py_INCREF(o),o;" in my C code, but I cannot really defend that idiom against "Py_INCREF(o); return o;" alternative. My personal reason is entirely C-specific, if followed an if(), the first form does not require curly braces. In any case, comma operator can be emulated in python as exp1,expr2,expr3 -> (exp1,expr2,expr3)[-1] Since multi-argument "identity" is likely to be rejected, my proposal to alter the order of arguments is moot. My other suggestion that with identity, map(None, ..) should be deprecated in favor of map(identity, ..) is probably an arument against the identity proposal now. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-19 15:05 Message: Logged In: YES user_id=1344176 Originator: NO I can see adding the 1-argument form to operator or functools (as it's useful in functional programming), but the 2-argument form you've suggested is right out. If you really feel the need to torture a "for" loop into a genexp/listcomp like that, foo = (x for x in bar if condition(x) and [memoize(x)]) does the same thing using today's capabilities. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-12 16:06 Message: Logged In: YES user_id=341410 Originator: NO Not all x line functions should be built into Python. Further, Python's standard syntax offers an infix operator that does the same thing (though in slightly different order as described below, you can reorder with minimal effort). identity(X, Y) -> (Y and False) or X Also, the only use-case that you are provided and that I can imagine, are examples like you provide where one is changing state within a statement (if, elif, while, etc.) or expression (generator, list comprehension, conditional, etc.). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 09:21 Message: Logged In: YES user_id=835142 Originator: NO 1. If this proposal is accepted, it will make sense to deprecate the use of None as an identity function in map: >>> map(None, range(10)) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] 2. Some other languages have an dyadic identity function that returns the *second* argument. For example, K has : primitive: identity:(:) identity[1;2] 2 The rationale in K is that it is useful in an ammed function that replaces entries of an an array with a result of a dyadic function applied to the old and the supplied value and it is natural to have old value first: @[1 2 3;1;-;20] 1 -18 3 @[1 2 3;1;:;20] 1 20 3 This rationale does not apply to Python, but in the absence of other reasons to choose the order of arguments, Python may as well follow the precedent. Does anyone know a less exotic language that has a dyadic identity? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 From noreply at sourceforge.net Thu Mar 22 20:37:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 12:37:02 -0700 Subject: [ python-Feature Requests-1673203 ] add identity function Message-ID: Feature Requests item #1673203, was opened at 2007-03-03 19:21 Message generated for change (Comment added) made by twobitsprite You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 Please note that this 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 Private: No Submitted By: paul rubin (phr) Assigned to: Raymond Hettinger (rhettinger) Summary: add identity function Initial Comment: Requested and assigned to Raymond at his suggestion: http://groups.google.com/group/comp.lang.python/msg/603870361743c85c There should be an identify function identity(x)=x. I suggest it also take and ignore an optional second arg: identity(x1,x2)=x1. The second arg can be useful in some generator expressions: foo = (x for x in bar if condition(x) and identity(True, memoize(x)) That allows calling memoize (or some other function) on the selected elements in the genexp, and disposing of the returned value. It's sort of like the const function (K combinator) to go along with the identity function's I combinator. OK, the above is not really in the functional spirit, but it's been useful. There could conceivably be also an actual const function const(k)=partial(identity,k) but I can't remember needing that in Python code. The two-arg identity function (uncurried version of const) is probably enough. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 15:37 Message: Logged In: YES user_id=1679533 Originator: NO Well, I'm suggesting that it be in __builtins__, but whatever... If I had it my way I'd program in Haskell every chance I got anyways, I only use python because my boss/co-workers prefer it. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-22 15:32 Message: Logged In: YES user_id=835142 Originator: NO > I can't believe there is such resistance for something > as trivial as a function which returns it's first argument. The resistance is precisely because it is so trivial. As josiahcarlson suggested before, "Not all x line functions should be built into Python." Compare the following two alternatives: def identity(*args): return args[0] and from functools import identity The first option is only slightly longer than the second, but it is actually much clearer. With the second option, it is not obvious that identity takes an arbitrary number of arguments and if it does, which argument it will return. The only advantage is that if coded in C, functools.identity may be slightly faster. However, given that >>> dis(lambda x: x) 1 0 LOAD_FAST 0 (x) 3 RETURN_VALUE I am not sure a C coded identity can significantly beat it. The real savings would come if python compiler could optimize away calls to identity altogether, but nobody has explained how that could be done or why it would be easier to optimize away identity that lambda x:x. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 15:25 Message: Logged In: YES user_id=1679533 Originator: NO Also, map like functions start to look a bit ugly (of course, this is overly simplistic, but serves as an example): def my_map(func, items): acc = [] for item in items: if func == None: acc.append(item) else: acc.append(func(item)) return acc which has the obvious overhead of a test for every iteration. Of course, you could just make two versions of the for loop, one which applies and one which doesn't, but that immetiately violates once-and-only-once and also forces the function to be overly concerned with what it is passed. this is _much_ cleaner: def my_map2(func, items): return [func(i) for i in items] and the user of the function can simply pass as and this keeps the details of what to do with the items outside of the function. Without identity, whenever I want to allow the user to inject code to modify data, I have to account for the fact that they might want to do nothing with it, and so I have to test for None constantly. This is simply bad practice and, IMHO, violates everything python stands for, which is elegance, simplicity and "batteries included", right? If you want I patch, I can try to provide one; however I have very minimal knowledge of how the vm works, and I've only looked at the code a couple of times. In fact, I might even go ahead and do that, it can't be that difficult. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 15:06 Message: Logged In: YES user_id=1679533 Originator: NO It still feels like an ugly hack for something so simple. I can't believe there is such resistance for something as trivial as a function which returns it's first argument. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-22 13:49 Message: Logged In: YES user_id=341410 Originator: NO twobitsprite: your use-case is different from that of others. While you could use an identity function for your purposes, a lambda would work just fine. Regardless, there is call overhead, which can only be reduced by not performing a call at all. In terms of an identity function versus tuple creation and indexing as per belopolsky's suggestion... >>> timeit.Timer("x(1+2,3+4)", "x = lambda *args:args[-1]").timeit() 0.99381552025397468 >>> timeit.Timer("(1+2,3+4)[-1]", "").timeit() 0.49153579156927663 Tuple is faster. Just use a tuple. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 09:06 Message: Logged In: YES user_id=1679533 Originator: NO I also would like to have a built-in identity function (in fact, I found this by googling "python identity function"). My use-case is a bit different. I ofter find myself wanting to simply specify a function for be used in a loop, something like: def f(items): if something: wrapper = int else: wrapper = identity for item in items: yield wrapper(item) of course, usually it's a bit more complex than that, but you get the idea... and I supposed its actually more like the previous use-case than I thought. I realize I could just use "lambda x: x", but I feel that comes with an unnecessary performance impact for something so trivial. I don't know how much python does to compile built-in functions, but I imagine that the identity function can be mostly optimized out at compile time if it were built-in. Just my two-cents. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-19 15:57 Message: Logged In: YES user_id=835142 Originator: NO I have just realized that the requested functionality is known in C as the comma operator. I often find myself writing "return Py_INCREF(o),o;" in my C code, but I cannot really defend that idiom against "Py_INCREF(o); return o;" alternative. My personal reason is entirely C-specific, if followed an if(), the first form does not require curly braces. In any case, comma operator can be emulated in python as exp1,expr2,expr3 -> (exp1,expr2,expr3)[-1] Since multi-argument "identity" is likely to be rejected, my proposal to alter the order of arguments is moot. My other suggestion that with identity, map(None, ..) should be deprecated in favor of map(identity, ..) is probably an arument against the identity proposal now. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-19 15:05 Message: Logged In: YES user_id=1344176 Originator: NO I can see adding the 1-argument form to operator or functools (as it's useful in functional programming), but the 2-argument form you've suggested is right out. If you really feel the need to torture a "for" loop into a genexp/listcomp like that, foo = (x for x in bar if condition(x) and [memoize(x)]) does the same thing using today's capabilities. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-12 16:06 Message: Logged In: YES user_id=341410 Originator: NO Not all x line functions should be built into Python. Further, Python's standard syntax offers an infix operator that does the same thing (though in slightly different order as described below, you can reorder with minimal effort). identity(X, Y) -> (Y and False) or X Also, the only use-case that you are provided and that I can imagine, are examples like you provide where one is changing state within a statement (if, elif, while, etc.) or expression (generator, list comprehension, conditional, etc.). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 09:21 Message: Logged In: YES user_id=835142 Originator: NO 1. If this proposal is accepted, it will make sense to deprecate the use of None as an identity function in map: >>> map(None, range(10)) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] 2. Some other languages have an dyadic identity function that returns the *second* argument. For example, K has : primitive: identity:(:) identity[1;2] 2 The rationale in K is that it is useful in an ammed function that replaces entries of an an array with a result of a dyadic function applied to the old and the supplied value and it is natural to have old value first: @[1 2 3;1;-;20] 1 -18 3 @[1 2 3;1;:;20] 1 20 3 This rationale does not apply to Python, but in the absence of other reasons to choose the order of arguments, Python may as well follow the precedent. Does anyone know a less exotic language that has a dyadic identity? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 From noreply at sourceforge.net Thu Mar 22 21:06:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 13:06:37 -0700 Subject: [ python-Feature Requests-1673203 ] add identity function Message-ID: Feature Requests item #1673203, was opened at 2007-03-03 19:21 Message generated for change (Comment added) made by twobitsprite You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 Please note that this 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 Private: No Submitted By: paul rubin (phr) Assigned to: Raymond Hettinger (rhettinger) Summary: add identity function Initial Comment: Requested and assigned to Raymond at his suggestion: http://groups.google.com/group/comp.lang.python/msg/603870361743c85c There should be an identify function identity(x)=x. I suggest it also take and ignore an optional second arg: identity(x1,x2)=x1. The second arg can be useful in some generator expressions: foo = (x for x in bar if condition(x) and identity(True, memoize(x)) That allows calling memoize (or some other function) on the selected elements in the genexp, and disposing of the returned value. It's sort of like the const function (K combinator) to go along with the identity function's I combinator. OK, the above is not really in the functional spirit, but it's been useful. There could conceivably be also an actual const function const(k)=partial(identity,k) but I can't remember needing that in Python code. The two-arg identity function (uncurried version of const) is probably enough. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 16:06 Message: Logged In: YES user_id=1679533 Originator: NO --- bltinmodule-orig.c 2007-03-22 16:00:21.452245559 -0400 +++ bltinmodule.c 2007-03-22 15:56:19.353115310 -0400 @@ -69,6 +69,17 @@ return PyNumber_Absolute(v); } +static PyObject * +builtin_identity(PyObject *self, PyObject *v) +{ + return v; +} + +PyDoc_STRVAR(identity_doc, +"identity(x) -> x\n\ +\n\ +The identity function. Simply returns is first argument."); + PyDoc_STRVAR(abs_doc, "abs(number) -> number\n\ \n\ @@ -2281,6 +2292,7 @@ #endif {"vars", builtin_vars, METH_VARARGS, vars_doc}, {"zip", builtin_zip, METH_VARARGS, zip_doc}, + {"identity", builtin_identity, METH_O, identity_doc}, {NULL, NULL}, }; ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 15:37 Message: Logged In: YES user_id=1679533 Originator: NO Well, I'm suggesting that it be in __builtins__, but whatever... If I had it my way I'd program in Haskell every chance I got anyways, I only use python because my boss/co-workers prefer it. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-22 15:32 Message: Logged In: YES user_id=835142 Originator: NO > I can't believe there is such resistance for something > as trivial as a function which returns it's first argument. The resistance is precisely because it is so trivial. As josiahcarlson suggested before, "Not all x line functions should be built into Python." Compare the following two alternatives: def identity(*args): return args[0] and from functools import identity The first option is only slightly longer than the second, but it is actually much clearer. With the second option, it is not obvious that identity takes an arbitrary number of arguments and if it does, which argument it will return. The only advantage is that if coded in C, functools.identity may be slightly faster. However, given that >>> dis(lambda x: x) 1 0 LOAD_FAST 0 (x) 3 RETURN_VALUE I am not sure a C coded identity can significantly beat it. The real savings would come if python compiler could optimize away calls to identity altogether, but nobody has explained how that could be done or why it would be easier to optimize away identity that lambda x:x. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 15:25 Message: Logged In: YES user_id=1679533 Originator: NO Also, map like functions start to look a bit ugly (of course, this is overly simplistic, but serves as an example): def my_map(func, items): acc = [] for item in items: if func == None: acc.append(item) else: acc.append(func(item)) return acc which has the obvious overhead of a test for every iteration. Of course, you could just make two versions of the for loop, one which applies and one which doesn't, but that immetiately violates once-and-only-once and also forces the function to be overly concerned with what it is passed. this is _much_ cleaner: def my_map2(func, items): return [func(i) for i in items] and the user of the function can simply pass as and this keeps the details of what to do with the items outside of the function. Without identity, whenever I want to allow the user to inject code to modify data, I have to account for the fact that they might want to do nothing with it, and so I have to test for None constantly. This is simply bad practice and, IMHO, violates everything python stands for, which is elegance, simplicity and "batteries included", right? If you want I patch, I can try to provide one; however I have very minimal knowledge of how the vm works, and I've only looked at the code a couple of times. In fact, I might even go ahead and do that, it can't be that difficult. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 15:06 Message: Logged In: YES user_id=1679533 Originator: NO It still feels like an ugly hack for something so simple. I can't believe there is such resistance for something as trivial as a function which returns it's first argument. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-22 13:49 Message: Logged In: YES user_id=341410 Originator: NO twobitsprite: your use-case is different from that of others. While you could use an identity function for your purposes, a lambda would work just fine. Regardless, there is call overhead, which can only be reduced by not performing a call at all. In terms of an identity function versus tuple creation and indexing as per belopolsky's suggestion... >>> timeit.Timer("x(1+2,3+4)", "x = lambda *args:args[-1]").timeit() 0.99381552025397468 >>> timeit.Timer("(1+2,3+4)[-1]", "").timeit() 0.49153579156927663 Tuple is faster. Just use a tuple. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 09:06 Message: Logged In: YES user_id=1679533 Originator: NO I also would like to have a built-in identity function (in fact, I found this by googling "python identity function"). My use-case is a bit different. I ofter find myself wanting to simply specify a function for be used in a loop, something like: def f(items): if something: wrapper = int else: wrapper = identity for item in items: yield wrapper(item) of course, usually it's a bit more complex than that, but you get the idea... and I supposed its actually more like the previous use-case than I thought. I realize I could just use "lambda x: x", but I feel that comes with an unnecessary performance impact for something so trivial. I don't know how much python does to compile built-in functions, but I imagine that the identity function can be mostly optimized out at compile time if it were built-in. Just my two-cents. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-19 15:57 Message: Logged In: YES user_id=835142 Originator: NO I have just realized that the requested functionality is known in C as the comma operator. I often find myself writing "return Py_INCREF(o),o;" in my C code, but I cannot really defend that idiom against "Py_INCREF(o); return o;" alternative. My personal reason is entirely C-specific, if followed an if(), the first form does not require curly braces. In any case, comma operator can be emulated in python as exp1,expr2,expr3 -> (exp1,expr2,expr3)[-1] Since multi-argument "identity" is likely to be rejected, my proposal to alter the order of arguments is moot. My other suggestion that with identity, map(None, ..) should be deprecated in favor of map(identity, ..) is probably an arument against the identity proposal now. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-19 15:05 Message: Logged In: YES user_id=1344176 Originator: NO I can see adding the 1-argument form to operator or functools (as it's useful in functional programming), but the 2-argument form you've suggested is right out. If you really feel the need to torture a "for" loop into a genexp/listcomp like that, foo = (x for x in bar if condition(x) and [memoize(x)]) does the same thing using today's capabilities. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-12 16:06 Message: Logged In: YES user_id=341410 Originator: NO Not all x line functions should be built into Python. Further, Python's standard syntax offers an infix operator that does the same thing (though in slightly different order as described below, you can reorder with minimal effort). identity(X, Y) -> (Y and False) or X Also, the only use-case that you are provided and that I can imagine, are examples like you provide where one is changing state within a statement (if, elif, while, etc.) or expression (generator, list comprehension, conditional, etc.). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 09:21 Message: Logged In: YES user_id=835142 Originator: NO 1. If this proposal is accepted, it will make sense to deprecate the use of None as an identity function in map: >>> map(None, range(10)) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] 2. Some other languages have an dyadic identity function that returns the *second* argument. For example, K has : primitive: identity:(:) identity[1;2] 2 The rationale in K is that it is useful in an ammed function that replaces entries of an an array with a result of a dyadic function applied to the old and the supplied value and it is natural to have old value first: @[1 2 3;1;-;20] 1 -18 3 @[1 2 3;1;:;20] 1 20 3 This rationale does not apply to Python, but in the absence of other reasons to choose the order of arguments, Python may as well follow the precedent. Does anyone know a less exotic language that has a dyadic identity? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 From noreply at sourceforge.net Thu Mar 22 21:06:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 13:06:59 -0700 Subject: [ python-Feature Requests-1673203 ] add identity function Message-ID: Feature Requests item #1673203, was opened at 2007-03-03 16:21 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 Please note that this 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 Private: No Submitted By: paul rubin (phr) Assigned to: Raymond Hettinger (rhettinger) Summary: add identity function Initial Comment: Requested and assigned to Raymond at his suggestion: http://groups.google.com/group/comp.lang.python/msg/603870361743c85c There should be an identify function identity(x)=x. I suggest it also take and ignore an optional second arg: identity(x1,x2)=x1. The second arg can be useful in some generator expressions: foo = (x for x in bar if condition(x) and identity(True, memoize(x)) That allows calling memoize (or some other function) on the selected elements in the genexp, and disposing of the returned value. It's sort of like the const function (K combinator) to go along with the identity function's I combinator. OK, the above is not really in the functional spirit, but it's been useful. There could conceivably be also an actual const function const(k)=partial(identity,k) but I can't remember needing that in Python code. The two-arg identity function (uncurried version of const) is probably enough. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-22 13:06 Message: Logged In: YES user_id=341410 Originator: NO > Well, I'm suggesting that it be in __builtins__, but whatever... You apparently didn't get the memo; map, filter, reduce, etc., are all going to be placed into functools and removed from __builtins__. Adding identity to __builtins__ is not going to happen. Further, your preferred programming language not being Python is not topical to the discussion. If you want Haskell, and your boss isn't letting you use it, please don't complain here. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 13:06 Message: Logged In: YES user_id=1679533 Originator: NO --- bltinmodule-orig.c 2007-03-22 16:00:21.452245559 -0400 +++ bltinmodule.c 2007-03-22 15:56:19.353115310 -0400 @@ -69,6 +69,17 @@ return PyNumber_Absolute(v); } +static PyObject * +builtin_identity(PyObject *self, PyObject *v) +{ + return v; +} + +PyDoc_STRVAR(identity_doc, +"identity(x) -> x\n\ +\n\ +The identity function. Simply returns is first argument."); + PyDoc_STRVAR(abs_doc, "abs(number) -> number\n\ \n\ @@ -2281,6 +2292,7 @@ #endif {"vars", builtin_vars, METH_VARARGS, vars_doc}, {"zip", builtin_zip, METH_VARARGS, zip_doc}, + {"identity", builtin_identity, METH_O, identity_doc}, {NULL, NULL}, }; ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 12:37 Message: Logged In: YES user_id=1679533 Originator: NO Well, I'm suggesting that it be in __builtins__, but whatever... If I had it my way I'd program in Haskell every chance I got anyways, I only use python because my boss/co-workers prefer it. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-22 12:32 Message: Logged In: YES user_id=835142 Originator: NO > I can't believe there is such resistance for something > as trivial as a function which returns it's first argument. The resistance is precisely because it is so trivial. As josiahcarlson suggested before, "Not all x line functions should be built into Python." Compare the following two alternatives: def identity(*args): return args[0] and from functools import identity The first option is only slightly longer than the second, but it is actually much clearer. With the second option, it is not obvious that identity takes an arbitrary number of arguments and if it does, which argument it will return. The only advantage is that if coded in C, functools.identity may be slightly faster. However, given that >>> dis(lambda x: x) 1 0 LOAD_FAST 0 (x) 3 RETURN_VALUE I am not sure a C coded identity can significantly beat it. The real savings would come if python compiler could optimize away calls to identity altogether, but nobody has explained how that could be done or why it would be easier to optimize away identity that lambda x:x. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 12:25 Message: Logged In: YES user_id=1679533 Originator: NO Also, map like functions start to look a bit ugly (of course, this is overly simplistic, but serves as an example): def my_map(func, items): acc = [] for item in items: if func == None: acc.append(item) else: acc.append(func(item)) return acc which has the obvious overhead of a test for every iteration. Of course, you could just make two versions of the for loop, one which applies and one which doesn't, but that immetiately violates once-and-only-once and also forces the function to be overly concerned with what it is passed. this is _much_ cleaner: def my_map2(func, items): return [func(i) for i in items] and the user of the function can simply pass as and this keeps the details of what to do with the items outside of the function. Without identity, whenever I want to allow the user to inject code to modify data, I have to account for the fact that they might want to do nothing with it, and so I have to test for None constantly. This is simply bad practice and, IMHO, violates everything python stands for, which is elegance, simplicity and "batteries included", right? If you want I patch, I can try to provide one; however I have very minimal knowledge of how the vm works, and I've only looked at the code a couple of times. In fact, I might even go ahead and do that, it can't be that difficult. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 12:06 Message: Logged In: YES user_id=1679533 Originator: NO It still feels like an ugly hack for something so simple. I can't believe there is such resistance for something as trivial as a function which returns it's first argument. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-22 10:49 Message: Logged In: YES user_id=341410 Originator: NO twobitsprite: your use-case is different from that of others. While you could use an identity function for your purposes, a lambda would work just fine. Regardless, there is call overhead, which can only be reduced by not performing a call at all. In terms of an identity function versus tuple creation and indexing as per belopolsky's suggestion... >>> timeit.Timer("x(1+2,3+4)", "x = lambda *args:args[-1]").timeit() 0.99381552025397468 >>> timeit.Timer("(1+2,3+4)[-1]", "").timeit() 0.49153579156927663 Tuple is faster. Just use a tuple. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 06:06 Message: Logged In: YES user_id=1679533 Originator: NO I also would like to have a built-in identity function (in fact, I found this by googling "python identity function"). My use-case is a bit different. I ofter find myself wanting to simply specify a function for be used in a loop, something like: def f(items): if something: wrapper = int else: wrapper = identity for item in items: yield wrapper(item) of course, usually it's a bit more complex than that, but you get the idea... and I supposed its actually more like the previous use-case than I thought. I realize I could just use "lambda x: x", but I feel that comes with an unnecessary performance impact for something so trivial. I don't know how much python does to compile built-in functions, but I imagine that the identity function can be mostly optimized out at compile time if it were built-in. Just my two-cents. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-19 12:57 Message: Logged In: YES user_id=835142 Originator: NO I have just realized that the requested functionality is known in C as the comma operator. I often find myself writing "return Py_INCREF(o),o;" in my C code, but I cannot really defend that idiom against "Py_INCREF(o); return o;" alternative. My personal reason is entirely C-specific, if followed an if(), the first form does not require curly braces. In any case, comma operator can be emulated in python as exp1,expr2,expr3 -> (exp1,expr2,expr3)[-1] Since multi-argument "identity" is likely to be rejected, my proposal to alter the order of arguments is moot. My other suggestion that with identity, map(None, ..) should be deprecated in favor of map(identity, ..) is probably an arument against the identity proposal now. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-19 12:05 Message: Logged In: YES user_id=1344176 Originator: NO I can see adding the 1-argument form to operator or functools (as it's useful in functional programming), but the 2-argument form you've suggested is right out. If you really feel the need to torture a "for" loop into a genexp/listcomp like that, foo = (x for x in bar if condition(x) and [memoize(x)]) does the same thing using today's capabilities. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-12 13:06 Message: Logged In: YES user_id=341410 Originator: NO Not all x line functions should be built into Python. Further, Python's standard syntax offers an infix operator that does the same thing (though in slightly different order as described below, you can reorder with minimal effort). identity(X, Y) -> (Y and False) or X Also, the only use-case that you are provided and that I can imagine, are examples like you provide where one is changing state within a statement (if, elif, while, etc.) or expression (generator, list comprehension, conditional, etc.). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 06:21 Message: Logged In: YES user_id=835142 Originator: NO 1. If this proposal is accepted, it will make sense to deprecate the use of None as an identity function in map: >>> map(None, range(10)) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] 2. Some other languages have an dyadic identity function that returns the *second* argument. For example, K has : primitive: identity:(:) identity[1;2] 2 The rationale in K is that it is useful in an ammed function that replaces entries of an an array with a result of a dyadic function applied to the old and the supplied value and it is natural to have old value first: @[1 2 3;1;-;20] 1 -18 3 @[1 2 3;1;:;20] 1 20 3 This rationale does not apply to Python, but in the absence of other reasons to choose the order of arguments, Python may as well follow the precedent. Does anyone know a less exotic language that has a dyadic identity? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 From noreply at sourceforge.net Thu Mar 22 21:13:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 13:13:10 -0700 Subject: [ python-Feature Requests-1673203 ] add identity function Message-ID: Feature Requests item #1673203, was opened at 2007-03-03 16:21 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 Please note that this 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 Private: No Submitted By: paul rubin (phr) Assigned to: Raymond Hettinger (rhettinger) Summary: add identity function Initial Comment: Requested and assigned to Raymond at his suggestion: http://groups.google.com/group/comp.lang.python/msg/603870361743c85c There should be an identify function identity(x)=x. I suggest it also take and ignore an optional second arg: identity(x1,x2)=x1. The second arg can be useful in some generator expressions: foo = (x for x in bar if condition(x) and identity(True, memoize(x)) That allows calling memoize (or some other function) on the selected elements in the genexp, and disposing of the returned value. It's sort of like the const function (K combinator) to go along with the identity function's I combinator. OK, the above is not really in the functional spirit, but it's been useful. There could conceivably be also an actual const function const(k)=partial(identity,k) but I can't remember needing that in Python code. The two-arg identity function (uncurried version of const) is probably enough. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-22 13:13 Message: Logged In: YES user_id=341410 Originator: NO Your patch isn't what was asked for by other users. The Python equivalent to what was asked for was: identity = lambda arg0, *args: arg0 Regardless, being that it is a functional language construct, it's not going to make it into __builtins__. Never mind that adding to __builtins__ has a higher requirement than in other portions of the standard library. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-22 13:06 Message: Logged In: YES user_id=341410 Originator: NO > Well, I'm suggesting that it be in __builtins__, but whatever... You apparently didn't get the memo; map, filter, reduce, etc., are all going to be placed into functools and removed from __builtins__. Adding identity to __builtins__ is not going to happen. Further, your preferred programming language not being Python is not topical to the discussion. If you want Haskell, and your boss isn't letting you use it, please don't complain here. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 13:06 Message: Logged In: YES user_id=1679533 Originator: NO --- bltinmodule-orig.c 2007-03-22 16:00:21.452245559 -0400 +++ bltinmodule.c 2007-03-22 15:56:19.353115310 -0400 @@ -69,6 +69,17 @@ return PyNumber_Absolute(v); } +static PyObject * +builtin_identity(PyObject *self, PyObject *v) +{ + return v; +} + +PyDoc_STRVAR(identity_doc, +"identity(x) -> x\n\ +\n\ +The identity function. Simply returns is first argument."); + PyDoc_STRVAR(abs_doc, "abs(number) -> number\n\ \n\ @@ -2281,6 +2292,7 @@ #endif {"vars", builtin_vars, METH_VARARGS, vars_doc}, {"zip", builtin_zip, METH_VARARGS, zip_doc}, + {"identity", builtin_identity, METH_O, identity_doc}, {NULL, NULL}, }; ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 12:37 Message: Logged In: YES user_id=1679533 Originator: NO Well, I'm suggesting that it be in __builtins__, but whatever... If I had it my way I'd program in Haskell every chance I got anyways, I only use python because my boss/co-workers prefer it. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-22 12:32 Message: Logged In: YES user_id=835142 Originator: NO > I can't believe there is such resistance for something > as trivial as a function which returns it's first argument. The resistance is precisely because it is so trivial. As josiahcarlson suggested before, "Not all x line functions should be built into Python." Compare the following two alternatives: def identity(*args): return args[0] and from functools import identity The first option is only slightly longer than the second, but it is actually much clearer. With the second option, it is not obvious that identity takes an arbitrary number of arguments and if it does, which argument it will return. The only advantage is that if coded in C, functools.identity may be slightly faster. However, given that >>> dis(lambda x: x) 1 0 LOAD_FAST 0 (x) 3 RETURN_VALUE I am not sure a C coded identity can significantly beat it. The real savings would come if python compiler could optimize away calls to identity altogether, but nobody has explained how that could be done or why it would be easier to optimize away identity that lambda x:x. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 12:25 Message: Logged In: YES user_id=1679533 Originator: NO Also, map like functions start to look a bit ugly (of course, this is overly simplistic, but serves as an example): def my_map(func, items): acc = [] for item in items: if func == None: acc.append(item) else: acc.append(func(item)) return acc which has the obvious overhead of a test for every iteration. Of course, you could just make two versions of the for loop, one which applies and one which doesn't, but that immetiately violates once-and-only-once and also forces the function to be overly concerned with what it is passed. this is _much_ cleaner: def my_map2(func, items): return [func(i) for i in items] and the user of the function can simply pass as and this keeps the details of what to do with the items outside of the function. Without identity, whenever I want to allow the user to inject code to modify data, I have to account for the fact that they might want to do nothing with it, and so I have to test for None constantly. This is simply bad practice and, IMHO, violates everything python stands for, which is elegance, simplicity and "batteries included", right? If you want I patch, I can try to provide one; however I have very minimal knowledge of how the vm works, and I've only looked at the code a couple of times. In fact, I might even go ahead and do that, it can't be that difficult. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 12:06 Message: Logged In: YES user_id=1679533 Originator: NO It still feels like an ugly hack for something so simple. I can't believe there is such resistance for something as trivial as a function which returns it's first argument. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-22 10:49 Message: Logged In: YES user_id=341410 Originator: NO twobitsprite: your use-case is different from that of others. While you could use an identity function for your purposes, a lambda would work just fine. Regardless, there is call overhead, which can only be reduced by not performing a call at all. In terms of an identity function versus tuple creation and indexing as per belopolsky's suggestion... >>> timeit.Timer("x(1+2,3+4)", "x = lambda *args:args[-1]").timeit() 0.99381552025397468 >>> timeit.Timer("(1+2,3+4)[-1]", "").timeit() 0.49153579156927663 Tuple is faster. Just use a tuple. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 06:06 Message: Logged In: YES user_id=1679533 Originator: NO I also would like to have a built-in identity function (in fact, I found this by googling "python identity function"). My use-case is a bit different. I ofter find myself wanting to simply specify a function for be used in a loop, something like: def f(items): if something: wrapper = int else: wrapper = identity for item in items: yield wrapper(item) of course, usually it's a bit more complex than that, but you get the idea... and I supposed its actually more like the previous use-case than I thought. I realize I could just use "lambda x: x", but I feel that comes with an unnecessary performance impact for something so trivial. I don't know how much python does to compile built-in functions, but I imagine that the identity function can be mostly optimized out at compile time if it were built-in. Just my two-cents. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-19 12:57 Message: Logged In: YES user_id=835142 Originator: NO I have just realized that the requested functionality is known in C as the comma operator. I often find myself writing "return Py_INCREF(o),o;" in my C code, but I cannot really defend that idiom against "Py_INCREF(o); return o;" alternative. My personal reason is entirely C-specific, if followed an if(), the first form does not require curly braces. In any case, comma operator can be emulated in python as exp1,expr2,expr3 -> (exp1,expr2,expr3)[-1] Since multi-argument "identity" is likely to be rejected, my proposal to alter the order of arguments is moot. My other suggestion that with identity, map(None, ..) should be deprecated in favor of map(identity, ..) is probably an arument against the identity proposal now. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-19 12:05 Message: Logged In: YES user_id=1344176 Originator: NO I can see adding the 1-argument form to operator or functools (as it's useful in functional programming), but the 2-argument form you've suggested is right out. If you really feel the need to torture a "for" loop into a genexp/listcomp like that, foo = (x for x in bar if condition(x) and [memoize(x)]) does the same thing using today's capabilities. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-12 13:06 Message: Logged In: YES user_id=341410 Originator: NO Not all x line functions should be built into Python. Further, Python's standard syntax offers an infix operator that does the same thing (though in slightly different order as described below, you can reorder with minimal effort). identity(X, Y) -> (Y and False) or X Also, the only use-case that you are provided and that I can imagine, are examples like you provide where one is changing state within a statement (if, elif, while, etc.) or expression (generator, list comprehension, conditional, etc.). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 06:21 Message: Logged In: YES user_id=835142 Originator: NO 1. If this proposal is accepted, it will make sense to deprecate the use of None as an identity function in map: >>> map(None, range(10)) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] 2. Some other languages have an dyadic identity function that returns the *second* argument. For example, K has : primitive: identity:(:) identity[1;2] 2 The rationale in K is that it is useful in an ammed function that replaces entries of an an array with a result of a dyadic function applied to the old and the supplied value and it is natural to have old value first: @[1 2 3;1;-;20] 1 -18 3 @[1 2 3;1;:;20] 1 20 3 This rationale does not apply to Python, but in the absence of other reasons to choose the order of arguments, Python may as well follow the precedent. Does anyone know a less exotic language that has a dyadic identity? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 From noreply at sourceforge.net Thu Mar 22 21:15:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 13:15:26 -0700 Subject: [ python-Feature Requests-1673203 ] add identity function Message-ID: Feature Requests item #1673203, was opened at 2007-03-03 19:21 Message generated for change (Comment added) made by jackdied You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 Please note that this 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 Private: No Submitted By: paul rubin (phr) Assigned to: Raymond Hettinger (rhettinger) Summary: add identity function Initial Comment: Requested and assigned to Raymond at his suggestion: http://groups.google.com/group/comp.lang.python/msg/603870361743c85c There should be an identify function identity(x)=x. I suggest it also take and ignore an optional second arg: identity(x1,x2)=x1. The second arg can be useful in some generator expressions: foo = (x for x in bar if condition(x) and identity(True, memoize(x)) That allows calling memoize (or some other function) on the selected elements in the genexp, and disposing of the returned value. It's sort of like the const function (K combinator) to go along with the identity function's I combinator. OK, the above is not really in the functional spirit, but it's been useful. There could conceivably be also an actual const function const(k)=partial(identity,k) but I can't remember needing that in Python code. The two-arg identity function (uncurried version of const) is probably enough. ---------------------------------------------------------------------- >Comment By: Jack Diederich (jackdied) Date: 2007-03-22 16:15 Message: Logged In: YES user_id=591932 Originator: NO Raymond, please make a pronouncement. +1 on adding it to the operator module. Lots of one liners go there. -1000 to having it take more than one argument. If I saw this identity(ob, 42) for the first time (or second, or ...) I would have to look up what it does. As a plain identity function it is obvious. Patch to operator.c, liboperator.tex, test_operator.py, NEWS attached. Raymond, there isn't a good section in the doc for this function so I added it to the logical operators. The fact that there isn't a good section for it might be a mark against it being included. It is a couple times faster than the python version which isn't exciting. sprat:~/src/python-rw> ./python Lib/timeit.py -s "from operator import identity" "identity(None)" 10000000 loops, best of 3: 0.161 usec per loop sprat:~/src/python-rw> ./python Lib/timeit.py -s "def identity(ob): return ob" "identity(None)" 1000000 loops, best of 3: 0.421 usec per loop File Added: identity.patch ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-22 16:13 Message: Logged In: YES user_id=341410 Originator: NO Your patch isn't what was asked for by other users. The Python equivalent to what was asked for was: identity = lambda arg0, *args: arg0 Regardless, being that it is a functional language construct, it's not going to make it into __builtins__. Never mind that adding to __builtins__ has a higher requirement than in other portions of the standard library. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-22 16:06 Message: Logged In: YES user_id=341410 Originator: NO > Well, I'm suggesting that it be in __builtins__, but whatever... You apparently didn't get the memo; map, filter, reduce, etc., are all going to be placed into functools and removed from __builtins__. Adding identity to __builtins__ is not going to happen. Further, your preferred programming language not being Python is not topical to the discussion. If you want Haskell, and your boss isn't letting you use it, please don't complain here. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 16:06 Message: Logged In: YES user_id=1679533 Originator: NO --- bltinmodule-orig.c 2007-03-22 16:00:21.452245559 -0400 +++ bltinmodule.c 2007-03-22 15:56:19.353115310 -0400 @@ -69,6 +69,17 @@ return PyNumber_Absolute(v); } +static PyObject * +builtin_identity(PyObject *self, PyObject *v) +{ + return v; +} + +PyDoc_STRVAR(identity_doc, +"identity(x) -> x\n\ +\n\ +The identity function. Simply returns is first argument."); + PyDoc_STRVAR(abs_doc, "abs(number) -> number\n\ \n\ @@ -2281,6 +2292,7 @@ #endif {"vars", builtin_vars, METH_VARARGS, vars_doc}, {"zip", builtin_zip, METH_VARARGS, zip_doc}, + {"identity", builtin_identity, METH_O, identity_doc}, {NULL, NULL}, }; ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 15:37 Message: Logged In: YES user_id=1679533 Originator: NO Well, I'm suggesting that it be in __builtins__, but whatever... If I had it my way I'd program in Haskell every chance I got anyways, I only use python because my boss/co-workers prefer it. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-22 15:32 Message: Logged In: YES user_id=835142 Originator: NO > I can't believe there is such resistance for something > as trivial as a function which returns it's first argument. The resistance is precisely because it is so trivial. As josiahcarlson suggested before, "Not all x line functions should be built into Python." Compare the following two alternatives: def identity(*args): return args[0] and from functools import identity The first option is only slightly longer than the second, but it is actually much clearer. With the second option, it is not obvious that identity takes an arbitrary number of arguments and if it does, which argument it will return. The only advantage is that if coded in C, functools.identity may be slightly faster. However, given that >>> dis(lambda x: x) 1 0 LOAD_FAST 0 (x) 3 RETURN_VALUE I am not sure a C coded identity can significantly beat it. The real savings would come if python compiler could optimize away calls to identity altogether, but nobody has explained how that could be done or why it would be easier to optimize away identity that lambda x:x. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 15:25 Message: Logged In: YES user_id=1679533 Originator: NO Also, map like functions start to look a bit ugly (of course, this is overly simplistic, but serves as an example): def my_map(func, items): acc = [] for item in items: if func == None: acc.append(item) else: acc.append(func(item)) return acc which has the obvious overhead of a test for every iteration. Of course, you could just make two versions of the for loop, one which applies and one which doesn't, but that immetiately violates once-and-only-once and also forces the function to be overly concerned with what it is passed. this is _much_ cleaner: def my_map2(func, items): return [func(i) for i in items] and the user of the function can simply pass as and this keeps the details of what to do with the items outside of the function. Without identity, whenever I want to allow the user to inject code to modify data, I have to account for the fact that they might want to do nothing with it, and so I have to test for None constantly. This is simply bad practice and, IMHO, violates everything python stands for, which is elegance, simplicity and "batteries included", right? If you want I patch, I can try to provide one; however I have very minimal knowledge of how the vm works, and I've only looked at the code a couple of times. In fact, I might even go ahead and do that, it can't be that difficult. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 15:06 Message: Logged In: YES user_id=1679533 Originator: NO It still feels like an ugly hack for something so simple. I can't believe there is such resistance for something as trivial as a function which returns it's first argument. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-22 13:49 Message: Logged In: YES user_id=341410 Originator: NO twobitsprite: your use-case is different from that of others. While you could use an identity function for your purposes, a lambda would work just fine. Regardless, there is call overhead, which can only be reduced by not performing a call at all. In terms of an identity function versus tuple creation and indexing as per belopolsky's suggestion... >>> timeit.Timer("x(1+2,3+4)", "x = lambda *args:args[-1]").timeit() 0.99381552025397468 >>> timeit.Timer("(1+2,3+4)[-1]", "").timeit() 0.49153579156927663 Tuple is faster. Just use a tuple. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 09:06 Message: Logged In: YES user_id=1679533 Originator: NO I also would like to have a built-in identity function (in fact, I found this by googling "python identity function"). My use-case is a bit different. I ofter find myself wanting to simply specify a function for be used in a loop, something like: def f(items): if something: wrapper = int else: wrapper = identity for item in items: yield wrapper(item) of course, usually it's a bit more complex than that, but you get the idea... and I supposed its actually more like the previous use-case than I thought. I realize I could just use "lambda x: x", but I feel that comes with an unnecessary performance impact for something so trivial. I don't know how much python does to compile built-in functions, but I imagine that the identity function can be mostly optimized out at compile time if it were built-in. Just my two-cents. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-19 15:57 Message: Logged In: YES user_id=835142 Originator: NO I have just realized that the requested functionality is known in C as the comma operator. I often find myself writing "return Py_INCREF(o),o;" in my C code, but I cannot really defend that idiom against "Py_INCREF(o); return o;" alternative. My personal reason is entirely C-specific, if followed an if(), the first form does not require curly braces. In any case, comma operator can be emulated in python as exp1,expr2,expr3 -> (exp1,expr2,expr3)[-1] Since multi-argument "identity" is likely to be rejected, my proposal to alter the order of arguments is moot. My other suggestion that with identity, map(None, ..) should be deprecated in favor of map(identity, ..) is probably an arument against the identity proposal now. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-19 15:05 Message: Logged In: YES user_id=1344176 Originator: NO I can see adding the 1-argument form to operator or functools (as it's useful in functional programming), but the 2-argument form you've suggested is right out. If you really feel the need to torture a "for" loop into a genexp/listcomp like that, foo = (x for x in bar if condition(x) and [memoize(x)]) does the same thing using today's capabilities. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-12 16:06 Message: Logged In: YES user_id=341410 Originator: NO Not all x line functions should be built into Python. Further, Python's standard syntax offers an infix operator that does the same thing (though in slightly different order as described below, you can reorder with minimal effort). identity(X, Y) -> (Y and False) or X Also, the only use-case that you are provided and that I can imagine, are examples like you provide where one is changing state within a statement (if, elif, while, etc.) or expression (generator, list comprehension, conditional, etc.). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 09:21 Message: Logged In: YES user_id=835142 Originator: NO 1. If this proposal is accepted, it will make sense to deprecate the use of None as an identity function in map: >>> map(None, range(10)) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] 2. Some other languages have an dyadic identity function that returns the *second* argument. For example, K has : primitive: identity:(:) identity[1;2] 2 The rationale in K is that it is useful in an ammed function that replaces entries of an an array with a result of a dyadic function applied to the old and the supplied value and it is natural to have old value first: @[1 2 3;1;-;20] 1 -18 3 @[1 2 3;1;:;20] 1 20 3 This rationale does not apply to Python, but in the absence of other reasons to choose the order of arguments, Python may as well follow the precedent. Does anyone know a less exotic language that has a dyadic identity? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 From noreply at sourceforge.net Thu Mar 22 21:18:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 13:18:01 -0700 Subject: [ python-Bugs-1581906 ] test_sqlite fails on OSX G5 arch if test_ctypes is run Message-ID: Bugs item #1581906, was opened at 2006-10-21 20:02 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Skip Montanaro (montanaro) >Assigned to: Skip Montanaro (montanaro) Summary: test_sqlite fails on OSX G5 arch if test_ctypes is run Initial Comment: I noticed a test_sqlite test failure on my Mac G5 the other day while trying to set up a buildbot for sqlalchemy. Everything runs fine on my G4 powerbook. Both machines run Mac OSX 10.4.8 with Apple's gcc 4.0.0, build 5026. I whittled the problem down to just having test_ctypes and test_sqlite enabled, then further whittled it down to just having Lib/ctypes/test/ test_find.py available (all other ctypes tests eliminated). More detailed problem descriptions are in these two postings to python-dev: http://article.gmane.org/gmane.comp.python.devel/84478 http://article.gmane.org/gmane.comp.python.devel/84481 Skip ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2007-03-22 21:18 Message: Logged In: YES user_id=11105 Originator: NO Skip, I do not have a G5 machine available, only a G4 and the problem doesn't appear there. For someone with a G5 it should not be too difficult to reproduce (or investigate), I think that running './python Lib/test/regrtest.py test_ctypes test_sqlite' should suffice. However, if loading the GLUT library changes the cwd, and sqlite fails with a changed working dir, I'm not sure where the problem really is and how it should be fixed. It could be said that test_ctypes should restore the cwd after the tests (but maybe this should be done by the test framework?), or it could be said that test_sqlite should set the cwd in case the test relies on it. I'll assign back to you because I have no way to test it on a machine where the problem appears. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-03-18 18:20 Message: Logged In: YES user_id=44345 Originator: YES Thomas, I assigned this to you simply so you can cast your eye on the problem and see if you think there might be anything ctypes-related in the problem I've reported. I've ignored it up 'til now, but I bumped up against it again trying to get the Pybots SQLAlchemy test suite running on my Mac. During my previous encounter with this problem Ronald Oussouren reported on a possible connection with GLUT: http://mail.python.org/pipermail/python-dev/2006-October/069523.html Assuming there is no obvious ctypes connection you can determine (it's not clear to me that there is any current directory funny business going on) just assign it back to me and I'll try to find a pysqlite expert to take a look. Thx, Skip ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-10-21 20:04 Message: Logged In: YES user_id=44345 Another article here: http://article.gmane.org/gmane.comp.python.devel/84487 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470 From noreply at sourceforge.net Thu Mar 22 21:18:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 13:18:47 -0700 Subject: [ python-Feature Requests-1673203 ] add identity function Message-ID: Feature Requests item #1673203, was opened at 2007-03-03 19:21 Message generated for change (Comment added) made by belopolsky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 Please note that this 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 Private: No Submitted By: paul rubin (phr) Assigned to: Raymond Hettinger (rhettinger) Summary: add identity function Initial Comment: Requested and assigned to Raymond at his suggestion: http://groups.google.com/group/comp.lang.python/msg/603870361743c85c There should be an identify function identity(x)=x. I suggest it also take and ignore an optional second arg: identity(x1,x2)=x1. The second arg can be useful in some generator expressions: foo = (x for x in bar if condition(x) and identity(True, memoize(x)) That allows calling memoize (or some other function) on the selected elements in the genexp, and disposing of the returned value. It's sort of like the const function (K combinator) to go along with the identity function's I combinator. OK, the above is not really in the functional spirit, but it's been useful. There could conceivably be also an actual const function const(k)=partial(identity,k) but I can't remember needing that in Python code. The two-arg identity function (uncurried version of const) is probably enough. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-22 16:18 Message: Logged In: YES user_id=835142 Originator: NO Raising "Haskel is better than Python" argument is unlikely to win you friends here. Neither will submitting a patch with a reference count bug :-). ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2007-03-22 16:15 Message: Logged In: YES user_id=591932 Originator: NO Raymond, please make a pronouncement. +1 on adding it to the operator module. Lots of one liners go there. -1000 to having it take more than one argument. If I saw this identity(ob, 42) for the first time (or second, or ...) I would have to look up what it does. As a plain identity function it is obvious. Patch to operator.c, liboperator.tex, test_operator.py, NEWS attached. Raymond, there isn't a good section in the doc for this function so I added it to the logical operators. The fact that there isn't a good section for it might be a mark against it being included. It is a couple times faster than the python version which isn't exciting. sprat:~/src/python-rw> ./python Lib/timeit.py -s "from operator import identity" "identity(None)" 10000000 loops, best of 3: 0.161 usec per loop sprat:~/src/python-rw> ./python Lib/timeit.py -s "def identity(ob): return ob" "identity(None)" 1000000 loops, best of 3: 0.421 usec per loop File Added: identity.patch ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-22 16:13 Message: Logged In: YES user_id=341410 Originator: NO Your patch isn't what was asked for by other users. The Python equivalent to what was asked for was: identity = lambda arg0, *args: arg0 Regardless, being that it is a functional language construct, it's not going to make it into __builtins__. Never mind that adding to __builtins__ has a higher requirement than in other portions of the standard library. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-22 16:06 Message: Logged In: YES user_id=341410 Originator: NO > Well, I'm suggesting that it be in __builtins__, but whatever... You apparently didn't get the memo; map, filter, reduce, etc., are all going to be placed into functools and removed from __builtins__. Adding identity to __builtins__ is not going to happen. Further, your preferred programming language not being Python is not topical to the discussion. If you want Haskell, and your boss isn't letting you use it, please don't complain here. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 16:06 Message: Logged In: YES user_id=1679533 Originator: NO --- bltinmodule-orig.c 2007-03-22 16:00:21.452245559 -0400 +++ bltinmodule.c 2007-03-22 15:56:19.353115310 -0400 @@ -69,6 +69,17 @@ return PyNumber_Absolute(v); } +static PyObject * +builtin_identity(PyObject *self, PyObject *v) +{ + return v; +} + +PyDoc_STRVAR(identity_doc, +"identity(x) -> x\n\ +\n\ +The identity function. Simply returns is first argument."); + PyDoc_STRVAR(abs_doc, "abs(number) -> number\n\ \n\ @@ -2281,6 +2292,7 @@ #endif {"vars", builtin_vars, METH_VARARGS, vars_doc}, {"zip", builtin_zip, METH_VARARGS, zip_doc}, + {"identity", builtin_identity, METH_O, identity_doc}, {NULL, NULL}, }; ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 15:37 Message: Logged In: YES user_id=1679533 Originator: NO Well, I'm suggesting that it be in __builtins__, but whatever... If I had it my way I'd program in Haskell every chance I got anyways, I only use python because my boss/co-workers prefer it. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-22 15:32 Message: Logged In: YES user_id=835142 Originator: NO > I can't believe there is such resistance for something > as trivial as a function which returns it's first argument. The resistance is precisely because it is so trivial. As josiahcarlson suggested before, "Not all x line functions should be built into Python." Compare the following two alternatives: def identity(*args): return args[0] and from functools import identity The first option is only slightly longer than the second, but it is actually much clearer. With the second option, it is not obvious that identity takes an arbitrary number of arguments and if it does, which argument it will return. The only advantage is that if coded in C, functools.identity may be slightly faster. However, given that >>> dis(lambda x: x) 1 0 LOAD_FAST 0 (x) 3 RETURN_VALUE I am not sure a C coded identity can significantly beat it. The real savings would come if python compiler could optimize away calls to identity altogether, but nobody has explained how that could be done or why it would be easier to optimize away identity that lambda x:x. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 15:25 Message: Logged In: YES user_id=1679533 Originator: NO Also, map like functions start to look a bit ugly (of course, this is overly simplistic, but serves as an example): def my_map(func, items): acc = [] for item in items: if func == None: acc.append(item) else: acc.append(func(item)) return acc which has the obvious overhead of a test for every iteration. Of course, you could just make two versions of the for loop, one which applies and one which doesn't, but that immetiately violates once-and-only-once and also forces the function to be overly concerned with what it is passed. this is _much_ cleaner: def my_map2(func, items): return [func(i) for i in items] and the user of the function can simply pass as and this keeps the details of what to do with the items outside of the function. Without identity, whenever I want to allow the user to inject code to modify data, I have to account for the fact that they might want to do nothing with it, and so I have to test for None constantly. This is simply bad practice and, IMHO, violates everything python stands for, which is elegance, simplicity and "batteries included", right? If you want I patch, I can try to provide one; however I have very minimal knowledge of how the vm works, and I've only looked at the code a couple of times. In fact, I might even go ahead and do that, it can't be that difficult. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 15:06 Message: Logged In: YES user_id=1679533 Originator: NO It still feels like an ugly hack for something so simple. I can't believe there is such resistance for something as trivial as a function which returns it's first argument. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-22 13:49 Message: Logged In: YES user_id=341410 Originator: NO twobitsprite: your use-case is different from that of others. While you could use an identity function for your purposes, a lambda would work just fine. Regardless, there is call overhead, which can only be reduced by not performing a call at all. In terms of an identity function versus tuple creation and indexing as per belopolsky's suggestion... >>> timeit.Timer("x(1+2,3+4)", "x = lambda *args:args[-1]").timeit() 0.99381552025397468 >>> timeit.Timer("(1+2,3+4)[-1]", "").timeit() 0.49153579156927663 Tuple is faster. Just use a tuple. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 09:06 Message: Logged In: YES user_id=1679533 Originator: NO I also would like to have a built-in identity function (in fact, I found this by googling "python identity function"). My use-case is a bit different. I ofter find myself wanting to simply specify a function for be used in a loop, something like: def f(items): if something: wrapper = int else: wrapper = identity for item in items: yield wrapper(item) of course, usually it's a bit more complex than that, but you get the idea... and I supposed its actually more like the previous use-case than I thought. I realize I could just use "lambda x: x", but I feel that comes with an unnecessary performance impact for something so trivial. I don't know how much python does to compile built-in functions, but I imagine that the identity function can be mostly optimized out at compile time if it were built-in. Just my two-cents. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-19 15:57 Message: Logged In: YES user_id=835142 Originator: NO I have just realized that the requested functionality is known in C as the comma operator. I often find myself writing "return Py_INCREF(o),o;" in my C code, but I cannot really defend that idiom against "Py_INCREF(o); return o;" alternative. My personal reason is entirely C-specific, if followed an if(), the first form does not require curly braces. In any case, comma operator can be emulated in python as exp1,expr2,expr3 -> (exp1,expr2,expr3)[-1] Since multi-argument "identity" is likely to be rejected, my proposal to alter the order of arguments is moot. My other suggestion that with identity, map(None, ..) should be deprecated in favor of map(identity, ..) is probably an arument against the identity proposal now. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-19 15:05 Message: Logged In: YES user_id=1344176 Originator: NO I can see adding the 1-argument form to operator or functools (as it's useful in functional programming), but the 2-argument form you've suggested is right out. If you really feel the need to torture a "for" loop into a genexp/listcomp like that, foo = (x for x in bar if condition(x) and [memoize(x)]) does the same thing using today's capabilities. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-12 16:06 Message: Logged In: YES user_id=341410 Originator: NO Not all x line functions should be built into Python. Further, Python's standard syntax offers an infix operator that does the same thing (though in slightly different order as described below, you can reorder with minimal effort). identity(X, Y) -> (Y and False) or X Also, the only use-case that you are provided and that I can imagine, are examples like you provide where one is changing state within a statement (if, elif, while, etc.) or expression (generator, list comprehension, conditional, etc.). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 09:21 Message: Logged In: YES user_id=835142 Originator: NO 1. If this proposal is accepted, it will make sense to deprecate the use of None as an identity function in map: >>> map(None, range(10)) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] 2. Some other languages have an dyadic identity function that returns the *second* argument. For example, K has : primitive: identity:(:) identity[1;2] 2 The rationale in K is that it is useful in an ammed function that replaces entries of an an array with a result of a dyadic function applied to the old and the supplied value and it is natural to have old value first: @[1 2 3;1;-;20] 1 -18 3 @[1 2 3;1;:;20] 1 20 3 This rationale does not apply to Python, but in the absence of other reasons to choose the order of arguments, Python may as well follow the precedent. Does anyone know a less exotic language that has a dyadic identity? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 From noreply at sourceforge.net Thu Mar 22 21:31:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 13:31:09 -0700 Subject: [ python-Feature Requests-1673203 ] add identity function Message-ID: Feature Requests item #1673203, was opened at 2007-03-03 19:21 Message generated for change (Comment added) made by twobitsprite You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 Please note that this 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 Private: No Submitted By: paul rubin (phr) Assigned to: Raymond Hettinger (rhettinger) Summary: add identity function Initial Comment: Requested and assigned to Raymond at his suggestion: http://groups.google.com/group/comp.lang.python/msg/603870361743c85c There should be an identify function identity(x)=x. I suggest it also take and ignore an optional second arg: identity(x1,x2)=x1. The second arg can be useful in some generator expressions: foo = (x for x in bar if condition(x) and identity(True, memoize(x)) That allows calling memoize (or some other function) on the selected elements in the genexp, and disposing of the returned value. It's sort of like the const function (K combinator) to go along with the identity function's I combinator. OK, the above is not really in the functional spirit, but it's been useful. There could conceivably be also an actual const function const(k)=partial(identity,k) but I can't remember needing that in Python code. The two-arg identity function (uncurried version of const) is probably enough. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 16:31 Message: Logged In: YES user_id=1679533 Originator: NO josiah, My appologies for not being hip to the latest python dev news. I would have no problem with putting the function in a module like functools/itertools/operator/whatever, I just thought something like that might belong with map/filter/etc... so, if that's where they're going, I can just from functools import * and go on my merry way. I was just responding to your argument that defining it yourself would be just as easy as importing from a module. +1 on Raymond's patch (not that I expect my vote to count much, being some random guy :P) execpt for it going into operator, being as map/etc are going somewhere else... either way, I think it's silly to mobe map/etc out of builtins, but hey... what am I gonna do about it? :P ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-22 16:18 Message: Logged In: YES user_id=835142 Originator: NO Raising "Haskel is better than Python" argument is unlikely to win you friends here. Neither will submitting a patch with a reference count bug :-). ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2007-03-22 16:15 Message: Logged In: YES user_id=591932 Originator: NO Raymond, please make a pronouncement. +1 on adding it to the operator module. Lots of one liners go there. -1000 to having it take more than one argument. If I saw this identity(ob, 42) for the first time (or second, or ...) I would have to look up what it does. As a plain identity function it is obvious. Patch to operator.c, liboperator.tex, test_operator.py, NEWS attached. Raymond, there isn't a good section in the doc for this function so I added it to the logical operators. The fact that there isn't a good section for it might be a mark against it being included. It is a couple times faster than the python version which isn't exciting. sprat:~/src/python-rw> ./python Lib/timeit.py -s "from operator import identity" "identity(None)" 10000000 loops, best of 3: 0.161 usec per loop sprat:~/src/python-rw> ./python Lib/timeit.py -s "def identity(ob): return ob" "identity(None)" 1000000 loops, best of 3: 0.421 usec per loop File Added: identity.patch ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-22 16:13 Message: Logged In: YES user_id=341410 Originator: NO Your patch isn't what was asked for by other users. The Python equivalent to what was asked for was: identity = lambda arg0, *args: arg0 Regardless, being that it is a functional language construct, it's not going to make it into __builtins__. Never mind that adding to __builtins__ has a higher requirement than in other portions of the standard library. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-22 16:06 Message: Logged In: YES user_id=341410 Originator: NO > Well, I'm suggesting that it be in __builtins__, but whatever... You apparently didn't get the memo; map, filter, reduce, etc., are all going to be placed into functools and removed from __builtins__. Adding identity to __builtins__ is not going to happen. Further, your preferred programming language not being Python is not topical to the discussion. If you want Haskell, and your boss isn't letting you use it, please don't complain here. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 16:06 Message: Logged In: YES user_id=1679533 Originator: NO --- bltinmodule-orig.c 2007-03-22 16:00:21.452245559 -0400 +++ bltinmodule.c 2007-03-22 15:56:19.353115310 -0400 @@ -69,6 +69,17 @@ return PyNumber_Absolute(v); } +static PyObject * +builtin_identity(PyObject *self, PyObject *v) +{ + return v; +} + +PyDoc_STRVAR(identity_doc, +"identity(x) -> x\n\ +\n\ +The identity function. Simply returns is first argument."); + PyDoc_STRVAR(abs_doc, "abs(number) -> number\n\ \n\ @@ -2281,6 +2292,7 @@ #endif {"vars", builtin_vars, METH_VARARGS, vars_doc}, {"zip", builtin_zip, METH_VARARGS, zip_doc}, + {"identity", builtin_identity, METH_O, identity_doc}, {NULL, NULL}, }; ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 15:37 Message: Logged In: YES user_id=1679533 Originator: NO Well, I'm suggesting that it be in __builtins__, but whatever... If I had it my way I'd program in Haskell every chance I got anyways, I only use python because my boss/co-workers prefer it. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-22 15:32 Message: Logged In: YES user_id=835142 Originator: NO > I can't believe there is such resistance for something > as trivial as a function which returns it's first argument. The resistance is precisely because it is so trivial. As josiahcarlson suggested before, "Not all x line functions should be built into Python." Compare the following two alternatives: def identity(*args): return args[0] and from functools import identity The first option is only slightly longer than the second, but it is actually much clearer. With the second option, it is not obvious that identity takes an arbitrary number of arguments and if it does, which argument it will return. The only advantage is that if coded in C, functools.identity may be slightly faster. However, given that >>> dis(lambda x: x) 1 0 LOAD_FAST 0 (x) 3 RETURN_VALUE I am not sure a C coded identity can significantly beat it. The real savings would come if python compiler could optimize away calls to identity altogether, but nobody has explained how that could be done or why it would be easier to optimize away identity that lambda x:x. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 15:25 Message: Logged In: YES user_id=1679533 Originator: NO Also, map like functions start to look a bit ugly (of course, this is overly simplistic, but serves as an example): def my_map(func, items): acc = [] for item in items: if func == None: acc.append(item) else: acc.append(func(item)) return acc which has the obvious overhead of a test for every iteration. Of course, you could just make two versions of the for loop, one which applies and one which doesn't, but that immetiately violates once-and-only-once and also forces the function to be overly concerned with what it is passed. this is _much_ cleaner: def my_map2(func, items): return [func(i) for i in items] and the user of the function can simply pass as and this keeps the details of what to do with the items outside of the function. Without identity, whenever I want to allow the user to inject code to modify data, I have to account for the fact that they might want to do nothing with it, and so I have to test for None constantly. This is simply bad practice and, IMHO, violates everything python stands for, which is elegance, simplicity and "batteries included", right? If you want I patch, I can try to provide one; however I have very minimal knowledge of how the vm works, and I've only looked at the code a couple of times. In fact, I might even go ahead and do that, it can't be that difficult. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 15:06 Message: Logged In: YES user_id=1679533 Originator: NO It still feels like an ugly hack for something so simple. I can't believe there is such resistance for something as trivial as a function which returns it's first argument. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-22 13:49 Message: Logged In: YES user_id=341410 Originator: NO twobitsprite: your use-case is different from that of others. While you could use an identity function for your purposes, a lambda would work just fine. Regardless, there is call overhead, which can only be reduced by not performing a call at all. In terms of an identity function versus tuple creation and indexing as per belopolsky's suggestion... >>> timeit.Timer("x(1+2,3+4)", "x = lambda *args:args[-1]").timeit() 0.99381552025397468 >>> timeit.Timer("(1+2,3+4)[-1]", "").timeit() 0.49153579156927663 Tuple is faster. Just use a tuple. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 09:06 Message: Logged In: YES user_id=1679533 Originator: NO I also would like to have a built-in identity function (in fact, I found this by googling "python identity function"). My use-case is a bit different. I ofter find myself wanting to simply specify a function for be used in a loop, something like: def f(items): if something: wrapper = int else: wrapper = identity for item in items: yield wrapper(item) of course, usually it's a bit more complex than that, but you get the idea... and I supposed its actually more like the previous use-case than I thought. I realize I could just use "lambda x: x", but I feel that comes with an unnecessary performance impact for something so trivial. I don't know how much python does to compile built-in functions, but I imagine that the identity function can be mostly optimized out at compile time if it were built-in. Just my two-cents. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-19 15:57 Message: Logged In: YES user_id=835142 Originator: NO I have just realized that the requested functionality is known in C as the comma operator. I often find myself writing "return Py_INCREF(o),o;" in my C code, but I cannot really defend that idiom against "Py_INCREF(o); return o;" alternative. My personal reason is entirely C-specific, if followed an if(), the first form does not require curly braces. In any case, comma operator can be emulated in python as exp1,expr2,expr3 -> (exp1,expr2,expr3)[-1] Since multi-argument "identity" is likely to be rejected, my proposal to alter the order of arguments is moot. My other suggestion that with identity, map(None, ..) should be deprecated in favor of map(identity, ..) is probably an arument against the identity proposal now. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-19 15:05 Message: Logged In: YES user_id=1344176 Originator: NO I can see adding the 1-argument form to operator or functools (as it's useful in functional programming), but the 2-argument form you've suggested is right out. If you really feel the need to torture a "for" loop into a genexp/listcomp like that, foo = (x for x in bar if condition(x) and [memoize(x)]) does the same thing using today's capabilities. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-12 16:06 Message: Logged In: YES user_id=341410 Originator: NO Not all x line functions should be built into Python. Further, Python's standard syntax offers an infix operator that does the same thing (though in slightly different order as described below, you can reorder with minimal effort). identity(X, Y) -> (Y and False) or X Also, the only use-case that you are provided and that I can imagine, are examples like you provide where one is changing state within a statement (if, elif, while, etc.) or expression (generator, list comprehension, conditional, etc.). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 09:21 Message: Logged In: YES user_id=835142 Originator: NO 1. If this proposal is accepted, it will make sense to deprecate the use of None as an identity function in map: >>> map(None, range(10)) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] 2. Some other languages have an dyadic identity function that returns the *second* argument. For example, K has : primitive: identity:(:) identity[1;2] 2 The rationale in K is that it is useful in an ammed function that replaces entries of an an array with a result of a dyadic function applied to the old and the supplied value and it is natural to have old value first: @[1 2 3;1;-;20] 1 -18 3 @[1 2 3;1;:;20] 1 20 3 This rationale does not apply to Python, but in the absence of other reasons to choose the order of arguments, Python may as well follow the precedent. Does anyone know a less exotic language that has a dyadic identity? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 From noreply at sourceforge.net Thu Mar 22 21:34:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 13:34:18 -0700 Subject: [ python-Feature Requests-1673203 ] add identity function Message-ID: Feature Requests item #1673203, was opened at 2007-03-03 19:21 Message generated for change (Comment added) made by belopolsky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 Please note that this 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 Private: No Submitted By: paul rubin (phr) Assigned to: Raymond Hettinger (rhettinger) Summary: add identity function Initial Comment: Requested and assigned to Raymond at his suggestion: http://groups.google.com/group/comp.lang.python/msg/603870361743c85c There should be an identify function identity(x)=x. I suggest it also take and ignore an optional second arg: identity(x1,x2)=x1. The second arg can be useful in some generator expressions: foo = (x for x in bar if condition(x) and identity(True, memoize(x)) That allows calling memoize (or some other function) on the selected elements in the genexp, and disposing of the returned value. It's sort of like the const function (K combinator) to go along with the identity function's I combinator. OK, the above is not really in the functional spirit, but it's been useful. There could conceivably be also an actual const function const(k)=partial(identity,k) but I can't remember needing that in Python code. The two-arg identity function (uncurried version of const) is probably enough. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-22 16:34 Message: Logged In: YES user_id=835142 Originator: NO I need to clarify that my comment about a buggy patch was responding to twobitsprite, not to jackdied whose post I noticed only after I hit submit. Jackdied's patch is correct, but my concern is that with identity in operators, functional programmers will start passing identity instead of None as func to map(func, ..) that will result in much slower code. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 16:31 Message: Logged In: YES user_id=1679533 Originator: NO josiah, My appologies for not being hip to the latest python dev news. I would have no problem with putting the function in a module like functools/itertools/operator/whatever, I just thought something like that might belong with map/filter/etc... so, if that's where they're going, I can just from functools import * and go on my merry way. I was just responding to your argument that defining it yourself would be just as easy as importing from a module. +1 on Raymond's patch (not that I expect my vote to count much, being some random guy :P) execpt for it going into operator, being as map/etc are going somewhere else... either way, I think it's silly to mobe map/etc out of builtins, but hey... what am I gonna do about it? :P ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-22 16:18 Message: Logged In: YES user_id=835142 Originator: NO Raising "Haskel is better than Python" argument is unlikely to win you friends here. Neither will submitting a patch with a reference count bug :-). ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2007-03-22 16:15 Message: Logged In: YES user_id=591932 Originator: NO Raymond, please make a pronouncement. +1 on adding it to the operator module. Lots of one liners go there. -1000 to having it take more than one argument. If I saw this identity(ob, 42) for the first time (or second, or ...) I would have to look up what it does. As a plain identity function it is obvious. Patch to operator.c, liboperator.tex, test_operator.py, NEWS attached. Raymond, there isn't a good section in the doc for this function so I added it to the logical operators. The fact that there isn't a good section for it might be a mark against it being included. It is a couple times faster than the python version which isn't exciting. sprat:~/src/python-rw> ./python Lib/timeit.py -s "from operator import identity" "identity(None)" 10000000 loops, best of 3: 0.161 usec per loop sprat:~/src/python-rw> ./python Lib/timeit.py -s "def identity(ob): return ob" "identity(None)" 1000000 loops, best of 3: 0.421 usec per loop File Added: identity.patch ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-22 16:13 Message: Logged In: YES user_id=341410 Originator: NO Your patch isn't what was asked for by other users. The Python equivalent to what was asked for was: identity = lambda arg0, *args: arg0 Regardless, being that it is a functional language construct, it's not going to make it into __builtins__. Never mind that adding to __builtins__ has a higher requirement than in other portions of the standard library. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-22 16:06 Message: Logged In: YES user_id=341410 Originator: NO > Well, I'm suggesting that it be in __builtins__, but whatever... You apparently didn't get the memo; map, filter, reduce, etc., are all going to be placed into functools and removed from __builtins__. Adding identity to __builtins__ is not going to happen. Further, your preferred programming language not being Python is not topical to the discussion. If you want Haskell, and your boss isn't letting you use it, please don't complain here. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 16:06 Message: Logged In: YES user_id=1679533 Originator: NO --- bltinmodule-orig.c 2007-03-22 16:00:21.452245559 -0400 +++ bltinmodule.c 2007-03-22 15:56:19.353115310 -0400 @@ -69,6 +69,17 @@ return PyNumber_Absolute(v); } +static PyObject * +builtin_identity(PyObject *self, PyObject *v) +{ + return v; +} + +PyDoc_STRVAR(identity_doc, +"identity(x) -> x\n\ +\n\ +The identity function. Simply returns is first argument."); + PyDoc_STRVAR(abs_doc, "abs(number) -> number\n\ \n\ @@ -2281,6 +2292,7 @@ #endif {"vars", builtin_vars, METH_VARARGS, vars_doc}, {"zip", builtin_zip, METH_VARARGS, zip_doc}, + {"identity", builtin_identity, METH_O, identity_doc}, {NULL, NULL}, }; ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 15:37 Message: Logged In: YES user_id=1679533 Originator: NO Well, I'm suggesting that it be in __builtins__, but whatever... If I had it my way I'd program in Haskell every chance I got anyways, I only use python because my boss/co-workers prefer it. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-22 15:32 Message: Logged In: YES user_id=835142 Originator: NO > I can't believe there is such resistance for something > as trivial as a function which returns it's first argument. The resistance is precisely because it is so trivial. As josiahcarlson suggested before, "Not all x line functions should be built into Python." Compare the following two alternatives: def identity(*args): return args[0] and from functools import identity The first option is only slightly longer than the second, but it is actually much clearer. With the second option, it is not obvious that identity takes an arbitrary number of arguments and if it does, which argument it will return. The only advantage is that if coded in C, functools.identity may be slightly faster. However, given that >>> dis(lambda x: x) 1 0 LOAD_FAST 0 (x) 3 RETURN_VALUE I am not sure a C coded identity can significantly beat it. The real savings would come if python compiler could optimize away calls to identity altogether, but nobody has explained how that could be done or why it would be easier to optimize away identity that lambda x:x. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 15:25 Message: Logged In: YES user_id=1679533 Originator: NO Also, map like functions start to look a bit ugly (of course, this is overly simplistic, but serves as an example): def my_map(func, items): acc = [] for item in items: if func == None: acc.append(item) else: acc.append(func(item)) return acc which has the obvious overhead of a test for every iteration. Of course, you could just make two versions of the for loop, one which applies and one which doesn't, but that immetiately violates once-and-only-once and also forces the function to be overly concerned with what it is passed. this is _much_ cleaner: def my_map2(func, items): return [func(i) for i in items] and the user of the function can simply pass as and this keeps the details of what to do with the items outside of the function. Without identity, whenever I want to allow the user to inject code to modify data, I have to account for the fact that they might want to do nothing with it, and so I have to test for None constantly. This is simply bad practice and, IMHO, violates everything python stands for, which is elegance, simplicity and "batteries included", right? If you want I patch, I can try to provide one; however I have very minimal knowledge of how the vm works, and I've only looked at the code a couple of times. In fact, I might even go ahead and do that, it can't be that difficult. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 15:06 Message: Logged In: YES user_id=1679533 Originator: NO It still feels like an ugly hack for something so simple. I can't believe there is such resistance for something as trivial as a function which returns it's first argument. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-22 13:49 Message: Logged In: YES user_id=341410 Originator: NO twobitsprite: your use-case is different from that of others. While you could use an identity function for your purposes, a lambda would work just fine. Regardless, there is call overhead, which can only be reduced by not performing a call at all. In terms of an identity function versus tuple creation and indexing as per belopolsky's suggestion... >>> timeit.Timer("x(1+2,3+4)", "x = lambda *args:args[-1]").timeit() 0.99381552025397468 >>> timeit.Timer("(1+2,3+4)[-1]", "").timeit() 0.49153579156927663 Tuple is faster. Just use a tuple. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 09:06 Message: Logged In: YES user_id=1679533 Originator: NO I also would like to have a built-in identity function (in fact, I found this by googling "python identity function"). My use-case is a bit different. I ofter find myself wanting to simply specify a function for be used in a loop, something like: def f(items): if something: wrapper = int else: wrapper = identity for item in items: yield wrapper(item) of course, usually it's a bit more complex than that, but you get the idea... and I supposed its actually more like the previous use-case than I thought. I realize I could just use "lambda x: x", but I feel that comes with an unnecessary performance impact for something so trivial. I don't know how much python does to compile built-in functions, but I imagine that the identity function can be mostly optimized out at compile time if it were built-in. Just my two-cents. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-19 15:57 Message: Logged In: YES user_id=835142 Originator: NO I have just realized that the requested functionality is known in C as the comma operator. I often find myself writing "return Py_INCREF(o),o;" in my C code, but I cannot really defend that idiom against "Py_INCREF(o); return o;" alternative. My personal reason is entirely C-specific, if followed an if(), the first form does not require curly braces. In any case, comma operator can be emulated in python as exp1,expr2,expr3 -> (exp1,expr2,expr3)[-1] Since multi-argument "identity" is likely to be rejected, my proposal to alter the order of arguments is moot. My other suggestion that with identity, map(None, ..) should be deprecated in favor of map(identity, ..) is probably an arument against the identity proposal now. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-19 15:05 Message: Logged In: YES user_id=1344176 Originator: NO I can see adding the 1-argument form to operator or functools (as it's useful in functional programming), but the 2-argument form you've suggested is right out. If you really feel the need to torture a "for" loop into a genexp/listcomp like that, foo = (x for x in bar if condition(x) and [memoize(x)]) does the same thing using today's capabilities. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-12 16:06 Message: Logged In: YES user_id=341410 Originator: NO Not all x line functions should be built into Python. Further, Python's standard syntax offers an infix operator that does the same thing (though in slightly different order as described below, you can reorder with minimal effort). identity(X, Y) -> (Y and False) or X Also, the only use-case that you are provided and that I can imagine, are examples like you provide where one is changing state within a statement (if, elif, while, etc.) or expression (generator, list comprehension, conditional, etc.). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 09:21 Message: Logged In: YES user_id=835142 Originator: NO 1. If this proposal is accepted, it will make sense to deprecate the use of None as an identity function in map: >>> map(None, range(10)) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] 2. Some other languages have an dyadic identity function that returns the *second* argument. For example, K has : primitive: identity:(:) identity[1;2] 2 The rationale in K is that it is useful in an ammed function that replaces entries of an an array with a result of a dyadic function applied to the old and the supplied value and it is natural to have old value first: @[1 2 3;1;-;20] 1 -18 3 @[1 2 3;1;:;20] 1 20 3 This rationale does not apply to Python, but in the absence of other reasons to choose the order of arguments, Python may as well follow the precedent. Does anyone know a less exotic language that has a dyadic identity? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 From noreply at sourceforge.net Thu Mar 22 21:57:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 13:57:12 -0700 Subject: [ python-Feature Requests-1673203 ] add identity function Message-ID: Feature Requests item #1673203, was opened at 2007-03-03 19:21 Message generated for change (Comment added) made by jackdied You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 Please note that this 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 Private: No Submitted By: paul rubin (phr) Assigned to: Raymond Hettinger (rhettinger) Summary: add identity function Initial Comment: Requested and assigned to Raymond at his suggestion: http://groups.google.com/group/comp.lang.python/msg/603870361743c85c There should be an identify function identity(x)=x. I suggest it also take and ignore an optional second arg: identity(x1,x2)=x1. The second arg can be useful in some generator expressions: foo = (x for x in bar if condition(x) and identity(True, memoize(x)) That allows calling memoize (or some other function) on the selected elements in the genexp, and disposing of the returned value. It's sort of like the const function (K combinator) to go along with the identity function's I combinator. OK, the above is not really in the functional spirit, but it's been useful. There could conceivably be also an actual const function const(k)=partial(identity,k) but I can't remember needing that in Python code. The two-arg identity function (uncurried version of const) is probably enough. ---------------------------------------------------------------------- >Comment By: Jack Diederich (jackdied) Date: 2007-03-22 16:57 Message: Logged In: YES user_id=591932 Originator: NO Let's put this thread on hold until we get a pronouncement. I don't think there is anything additional to be said. Alexander, don't worry, I didn't think you were talking about my patch ;) and don't worry about people writing sub-optimal code. If you start doing that you'll never get any sleep. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-22 16:34 Message: Logged In: YES user_id=835142 Originator: NO I need to clarify that my comment about a buggy patch was responding to twobitsprite, not to jackdied whose post I noticed only after I hit submit. Jackdied's patch is correct, but my concern is that with identity in operators, functional programmers will start passing identity instead of None as func to map(func, ..) that will result in much slower code. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 16:31 Message: Logged In: YES user_id=1679533 Originator: NO josiah, My appologies for not being hip to the latest python dev news. I would have no problem with putting the function in a module like functools/itertools/operator/whatever, I just thought something like that might belong with map/filter/etc... so, if that's where they're going, I can just from functools import * and go on my merry way. I was just responding to your argument that defining it yourself would be just as easy as importing from a module. +1 on Raymond's patch (not that I expect my vote to count much, being some random guy :P) execpt for it going into operator, being as map/etc are going somewhere else... either way, I think it's silly to mobe map/etc out of builtins, but hey... what am I gonna do about it? :P ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-22 16:18 Message: Logged In: YES user_id=835142 Originator: NO Raising "Haskel is better than Python" argument is unlikely to win you friends here. Neither will submitting a patch with a reference count bug :-). ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2007-03-22 16:15 Message: Logged In: YES user_id=591932 Originator: NO Raymond, please make a pronouncement. +1 on adding it to the operator module. Lots of one liners go there. -1000 to having it take more than one argument. If I saw this identity(ob, 42) for the first time (or second, or ...) I would have to look up what it does. As a plain identity function it is obvious. Patch to operator.c, liboperator.tex, test_operator.py, NEWS attached. Raymond, there isn't a good section in the doc for this function so I added it to the logical operators. The fact that there isn't a good section for it might be a mark against it being included. It is a couple times faster than the python version which isn't exciting. sprat:~/src/python-rw> ./python Lib/timeit.py -s "from operator import identity" "identity(None)" 10000000 loops, best of 3: 0.161 usec per loop sprat:~/src/python-rw> ./python Lib/timeit.py -s "def identity(ob): return ob" "identity(None)" 1000000 loops, best of 3: 0.421 usec per loop File Added: identity.patch ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-22 16:13 Message: Logged In: YES user_id=341410 Originator: NO Your patch isn't what was asked for by other users. The Python equivalent to what was asked for was: identity = lambda arg0, *args: arg0 Regardless, being that it is a functional language construct, it's not going to make it into __builtins__. Never mind that adding to __builtins__ has a higher requirement than in other portions of the standard library. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-22 16:06 Message: Logged In: YES user_id=341410 Originator: NO > Well, I'm suggesting that it be in __builtins__, but whatever... You apparently didn't get the memo; map, filter, reduce, etc., are all going to be placed into functools and removed from __builtins__. Adding identity to __builtins__ is not going to happen. Further, your preferred programming language not being Python is not topical to the discussion. If you want Haskell, and your boss isn't letting you use it, please don't complain here. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 16:06 Message: Logged In: YES user_id=1679533 Originator: NO --- bltinmodule-orig.c 2007-03-22 16:00:21.452245559 -0400 +++ bltinmodule.c 2007-03-22 15:56:19.353115310 -0400 @@ -69,6 +69,17 @@ return PyNumber_Absolute(v); } +static PyObject * +builtin_identity(PyObject *self, PyObject *v) +{ + return v; +} + +PyDoc_STRVAR(identity_doc, +"identity(x) -> x\n\ +\n\ +The identity function. Simply returns is first argument."); + PyDoc_STRVAR(abs_doc, "abs(number) -> number\n\ \n\ @@ -2281,6 +2292,7 @@ #endif {"vars", builtin_vars, METH_VARARGS, vars_doc}, {"zip", builtin_zip, METH_VARARGS, zip_doc}, + {"identity", builtin_identity, METH_O, identity_doc}, {NULL, NULL}, }; ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 15:37 Message: Logged In: YES user_id=1679533 Originator: NO Well, I'm suggesting that it be in __builtins__, but whatever... If I had it my way I'd program in Haskell every chance I got anyways, I only use python because my boss/co-workers prefer it. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-22 15:32 Message: Logged In: YES user_id=835142 Originator: NO > I can't believe there is such resistance for something > as trivial as a function which returns it's first argument. The resistance is precisely because it is so trivial. As josiahcarlson suggested before, "Not all x line functions should be built into Python." Compare the following two alternatives: def identity(*args): return args[0] and from functools import identity The first option is only slightly longer than the second, but it is actually much clearer. With the second option, it is not obvious that identity takes an arbitrary number of arguments and if it does, which argument it will return. The only advantage is that if coded in C, functools.identity may be slightly faster. However, given that >>> dis(lambda x: x) 1 0 LOAD_FAST 0 (x) 3 RETURN_VALUE I am not sure a C coded identity can significantly beat it. The real savings would come if python compiler could optimize away calls to identity altogether, but nobody has explained how that could be done or why it would be easier to optimize away identity that lambda x:x. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 15:25 Message: Logged In: YES user_id=1679533 Originator: NO Also, map like functions start to look a bit ugly (of course, this is overly simplistic, but serves as an example): def my_map(func, items): acc = [] for item in items: if func == None: acc.append(item) else: acc.append(func(item)) return acc which has the obvious overhead of a test for every iteration. Of course, you could just make two versions of the for loop, one which applies and one which doesn't, but that immetiately violates once-and-only-once and also forces the function to be overly concerned with what it is passed. this is _much_ cleaner: def my_map2(func, items): return [func(i) for i in items] and the user of the function can simply pass as and this keeps the details of what to do with the items outside of the function. Without identity, whenever I want to allow the user to inject code to modify data, I have to account for the fact that they might want to do nothing with it, and so I have to test for None constantly. This is simply bad practice and, IMHO, violates everything python stands for, which is elegance, simplicity and "batteries included", right? If you want I patch, I can try to provide one; however I have very minimal knowledge of how the vm works, and I've only looked at the code a couple of times. In fact, I might even go ahead and do that, it can't be that difficult. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 15:06 Message: Logged In: YES user_id=1679533 Originator: NO It still feels like an ugly hack for something so simple. I can't believe there is such resistance for something as trivial as a function which returns it's first argument. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-22 13:49 Message: Logged In: YES user_id=341410 Originator: NO twobitsprite: your use-case is different from that of others. While you could use an identity function for your purposes, a lambda would work just fine. Regardless, there is call overhead, which can only be reduced by not performing a call at all. In terms of an identity function versus tuple creation and indexing as per belopolsky's suggestion... >>> timeit.Timer("x(1+2,3+4)", "x = lambda *args:args[-1]").timeit() 0.99381552025397468 >>> timeit.Timer("(1+2,3+4)[-1]", "").timeit() 0.49153579156927663 Tuple is faster. Just use a tuple. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 09:06 Message: Logged In: YES user_id=1679533 Originator: NO I also would like to have a built-in identity function (in fact, I found this by googling "python identity function"). My use-case is a bit different. I ofter find myself wanting to simply specify a function for be used in a loop, something like: def f(items): if something: wrapper = int else: wrapper = identity for item in items: yield wrapper(item) of course, usually it's a bit more complex than that, but you get the idea... and I supposed its actually more like the previous use-case than I thought. I realize I could just use "lambda x: x", but I feel that comes with an unnecessary performance impact for something so trivial. I don't know how much python does to compile built-in functions, but I imagine that the identity function can be mostly optimized out at compile time if it were built-in. Just my two-cents. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-19 15:57 Message: Logged In: YES user_id=835142 Originator: NO I have just realized that the requested functionality is known in C as the comma operator. I often find myself writing "return Py_INCREF(o),o;" in my C code, but I cannot really defend that idiom against "Py_INCREF(o); return o;" alternative. My personal reason is entirely C-specific, if followed an if(), the first form does not require curly braces. In any case, comma operator can be emulated in python as exp1,expr2,expr3 -> (exp1,expr2,expr3)[-1] Since multi-argument "identity" is likely to be rejected, my proposal to alter the order of arguments is moot. My other suggestion that with identity, map(None, ..) should be deprecated in favor of map(identity, ..) is probably an arument against the identity proposal now. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-19 15:05 Message: Logged In: YES user_id=1344176 Originator: NO I can see adding the 1-argument form to operator or functools (as it's useful in functional programming), but the 2-argument form you've suggested is right out. If you really feel the need to torture a "for" loop into a genexp/listcomp like that, foo = (x for x in bar if condition(x) and [memoize(x)]) does the same thing using today's capabilities. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-12 16:06 Message: Logged In: YES user_id=341410 Originator: NO Not all x line functions should be built into Python. Further, Python's standard syntax offers an infix operator that does the same thing (though in slightly different order as described below, you can reorder with minimal effort). identity(X, Y) -> (Y and False) or X Also, the only use-case that you are provided and that I can imagine, are examples like you provide where one is changing state within a statement (if, elif, while, etc.) or expression (generator, list comprehension, conditional, etc.). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 09:21 Message: Logged In: YES user_id=835142 Originator: NO 1. If this proposal is accepted, it will make sense to deprecate the use of None as an identity function in map: >>> map(None, range(10)) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] 2. Some other languages have an dyadic identity function that returns the *second* argument. For example, K has : primitive: identity:(:) identity[1;2] 2 The rationale in K is that it is useful in an ammed function that replaces entries of an an array with a result of a dyadic function applied to the old and the supplied value and it is natural to have old value first: @[1 2 3;1;-;20] 1 -18 3 @[1 2 3;1;:;20] 1 20 3 This rationale does not apply to Python, but in the absence of other reasons to choose the order of arguments, Python may as well follow the precedent. Does anyone know a less exotic language that has a dyadic identity? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 From noreply at sourceforge.net Thu Mar 22 22:26:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 14:26:42 -0700 Subject: [ python-Feature Requests-1673203 ] add identity function Message-ID: Feature Requests item #1673203, was opened at 2007-03-03 19:21 Message generated for change (Comment added) made by twobitsprite You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 Please note that this 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 Private: No Submitted By: paul rubin (phr) Assigned to: Raymond Hettinger (rhettinger) Summary: add identity function Initial Comment: Requested and assigned to Raymond at his suggestion: http://groups.google.com/group/comp.lang.python/msg/603870361743c85c There should be an identify function identity(x)=x. I suggest it also take and ignore an optional second arg: identity(x1,x2)=x1. The second arg can be useful in some generator expressions: foo = (x for x in bar if condition(x) and identity(True, memoize(x)) That allows calling memoize (or some other function) on the selected elements in the genexp, and disposing of the returned value. It's sort of like the const function (K combinator) to go along with the identity function's I combinator. OK, the above is not really in the functional spirit, but it's been useful. There could conceivably be also an actual const function const(k)=partial(identity,k) but I can't remember needing that in Python code. The two-arg identity function (uncurried version of const) is probably enough. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 17:26 Message: Logged In: YES user_id=1679533 Originator: NO > Neither will submitting a patch with a reference count bug :-). Bleh, generational garbage collectors are where its at anyways. ;P ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2007-03-22 16:57 Message: Logged In: YES user_id=591932 Originator: NO Let's put this thread on hold until we get a pronouncement. I don't think there is anything additional to be said. Alexander, don't worry, I didn't think you were talking about my patch ;) and don't worry about people writing sub-optimal code. If you start doing that you'll never get any sleep. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-22 16:34 Message: Logged In: YES user_id=835142 Originator: NO I need to clarify that my comment about a buggy patch was responding to twobitsprite, not to jackdied whose post I noticed only after I hit submit. Jackdied's patch is correct, but my concern is that with identity in operators, functional programmers will start passing identity instead of None as func to map(func, ..) that will result in much slower code. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 16:31 Message: Logged In: YES user_id=1679533 Originator: NO josiah, My appologies for not being hip to the latest python dev news. I would have no problem with putting the function in a module like functools/itertools/operator/whatever, I just thought something like that might belong with map/filter/etc... so, if that's where they're going, I can just from functools import * and go on my merry way. I was just responding to your argument that defining it yourself would be just as easy as importing from a module. +1 on Raymond's patch (not that I expect my vote to count much, being some random guy :P) execpt for it going into operator, being as map/etc are going somewhere else... either way, I think it's silly to mobe map/etc out of builtins, but hey... what am I gonna do about it? :P ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-22 16:18 Message: Logged In: YES user_id=835142 Originator: NO Raising "Haskel is better than Python" argument is unlikely to win you friends here. Neither will submitting a patch with a reference count bug :-). ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2007-03-22 16:15 Message: Logged In: YES user_id=591932 Originator: NO Raymond, please make a pronouncement. +1 on adding it to the operator module. Lots of one liners go there. -1000 to having it take more than one argument. If I saw this identity(ob, 42) for the first time (or second, or ...) I would have to look up what it does. As a plain identity function it is obvious. Patch to operator.c, liboperator.tex, test_operator.py, NEWS attached. Raymond, there isn't a good section in the doc for this function so I added it to the logical operators. The fact that there isn't a good section for it might be a mark against it being included. It is a couple times faster than the python version which isn't exciting. sprat:~/src/python-rw> ./python Lib/timeit.py -s "from operator import identity" "identity(None)" 10000000 loops, best of 3: 0.161 usec per loop sprat:~/src/python-rw> ./python Lib/timeit.py -s "def identity(ob): return ob" "identity(None)" 1000000 loops, best of 3: 0.421 usec per loop File Added: identity.patch ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-22 16:13 Message: Logged In: YES user_id=341410 Originator: NO Your patch isn't what was asked for by other users. The Python equivalent to what was asked for was: identity = lambda arg0, *args: arg0 Regardless, being that it is a functional language construct, it's not going to make it into __builtins__. Never mind that adding to __builtins__ has a higher requirement than in other portions of the standard library. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-22 16:06 Message: Logged In: YES user_id=341410 Originator: NO > Well, I'm suggesting that it be in __builtins__, but whatever... You apparently didn't get the memo; map, filter, reduce, etc., are all going to be placed into functools and removed from __builtins__. Adding identity to __builtins__ is not going to happen. Further, your preferred programming language not being Python is not topical to the discussion. If you want Haskell, and your boss isn't letting you use it, please don't complain here. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 16:06 Message: Logged In: YES user_id=1679533 Originator: NO --- bltinmodule-orig.c 2007-03-22 16:00:21.452245559 -0400 +++ bltinmodule.c 2007-03-22 15:56:19.353115310 -0400 @@ -69,6 +69,17 @@ return PyNumber_Absolute(v); } +static PyObject * +builtin_identity(PyObject *self, PyObject *v) +{ + return v; +} + +PyDoc_STRVAR(identity_doc, +"identity(x) -> x\n\ +\n\ +The identity function. Simply returns is first argument."); + PyDoc_STRVAR(abs_doc, "abs(number) -> number\n\ \n\ @@ -2281,6 +2292,7 @@ #endif {"vars", builtin_vars, METH_VARARGS, vars_doc}, {"zip", builtin_zip, METH_VARARGS, zip_doc}, + {"identity", builtin_identity, METH_O, identity_doc}, {NULL, NULL}, }; ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 15:37 Message: Logged In: YES user_id=1679533 Originator: NO Well, I'm suggesting that it be in __builtins__, but whatever... If I had it my way I'd program in Haskell every chance I got anyways, I only use python because my boss/co-workers prefer it. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-22 15:32 Message: Logged In: YES user_id=835142 Originator: NO > I can't believe there is such resistance for something > as trivial as a function which returns it's first argument. The resistance is precisely because it is so trivial. As josiahcarlson suggested before, "Not all x line functions should be built into Python." Compare the following two alternatives: def identity(*args): return args[0] and from functools import identity The first option is only slightly longer than the second, but it is actually much clearer. With the second option, it is not obvious that identity takes an arbitrary number of arguments and if it does, which argument it will return. The only advantage is that if coded in C, functools.identity may be slightly faster. However, given that >>> dis(lambda x: x) 1 0 LOAD_FAST 0 (x) 3 RETURN_VALUE I am not sure a C coded identity can significantly beat it. The real savings would come if python compiler could optimize away calls to identity altogether, but nobody has explained how that could be done or why it would be easier to optimize away identity that lambda x:x. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 15:25 Message: Logged In: YES user_id=1679533 Originator: NO Also, map like functions start to look a bit ugly (of course, this is overly simplistic, but serves as an example): def my_map(func, items): acc = [] for item in items: if func == None: acc.append(item) else: acc.append(func(item)) return acc which has the obvious overhead of a test for every iteration. Of course, you could just make two versions of the for loop, one which applies and one which doesn't, but that immetiately violates once-and-only-once and also forces the function to be overly concerned with what it is passed. this is _much_ cleaner: def my_map2(func, items): return [func(i) for i in items] and the user of the function can simply pass as and this keeps the details of what to do with the items outside of the function. Without identity, whenever I want to allow the user to inject code to modify data, I have to account for the fact that they might want to do nothing with it, and so I have to test for None constantly. This is simply bad practice and, IMHO, violates everything python stands for, which is elegance, simplicity and "batteries included", right? If you want I patch, I can try to provide one; however I have very minimal knowledge of how the vm works, and I've only looked at the code a couple of times. In fact, I might even go ahead and do that, it can't be that difficult. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 15:06 Message: Logged In: YES user_id=1679533 Originator: NO It still feels like an ugly hack for something so simple. I can't believe there is such resistance for something as trivial as a function which returns it's first argument. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-22 13:49 Message: Logged In: YES user_id=341410 Originator: NO twobitsprite: your use-case is different from that of others. While you could use an identity function for your purposes, a lambda would work just fine. Regardless, there is call overhead, which can only be reduced by not performing a call at all. In terms of an identity function versus tuple creation and indexing as per belopolsky's suggestion... >>> timeit.Timer("x(1+2,3+4)", "x = lambda *args:args[-1]").timeit() 0.99381552025397468 >>> timeit.Timer("(1+2,3+4)[-1]", "").timeit() 0.49153579156927663 Tuple is faster. Just use a tuple. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 09:06 Message: Logged In: YES user_id=1679533 Originator: NO I also would like to have a built-in identity function (in fact, I found this by googling "python identity function"). My use-case is a bit different. I ofter find myself wanting to simply specify a function for be used in a loop, something like: def f(items): if something: wrapper = int else: wrapper = identity for item in items: yield wrapper(item) of course, usually it's a bit more complex than that, but you get the idea... and I supposed its actually more like the previous use-case than I thought. I realize I could just use "lambda x: x", but I feel that comes with an unnecessary performance impact for something so trivial. I don't know how much python does to compile built-in functions, but I imagine that the identity function can be mostly optimized out at compile time if it were built-in. Just my two-cents. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-19 15:57 Message: Logged In: YES user_id=835142 Originator: NO I have just realized that the requested functionality is known in C as the comma operator. I often find myself writing "return Py_INCREF(o),o;" in my C code, but I cannot really defend that idiom against "Py_INCREF(o); return o;" alternative. My personal reason is entirely C-specific, if followed an if(), the first form does not require curly braces. In any case, comma operator can be emulated in python as exp1,expr2,expr3 -> (exp1,expr2,expr3)[-1] Since multi-argument "identity" is likely to be rejected, my proposal to alter the order of arguments is moot. My other suggestion that with identity, map(None, ..) should be deprecated in favor of map(identity, ..) is probably an arument against the identity proposal now. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-19 15:05 Message: Logged In: YES user_id=1344176 Originator: NO I can see adding the 1-argument form to operator or functools (as it's useful in functional programming), but the 2-argument form you've suggested is right out. If you really feel the need to torture a "for" loop into a genexp/listcomp like that, foo = (x for x in bar if condition(x) and [memoize(x)]) does the same thing using today's capabilities. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-12 16:06 Message: Logged In: YES user_id=341410 Originator: NO Not all x line functions should be built into Python. Further, Python's standard syntax offers an infix operator that does the same thing (though in slightly different order as described below, you can reorder with minimal effort). identity(X, Y) -> (Y and False) or X Also, the only use-case that you are provided and that I can imagine, are examples like you provide where one is changing state within a statement (if, elif, while, etc.) or expression (generator, list comprehension, conditional, etc.). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 09:21 Message: Logged In: YES user_id=835142 Originator: NO 1. If this proposal is accepted, it will make sense to deprecate the use of None as an identity function in map: >>> map(None, range(10)) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] 2. Some other languages have an dyadic identity function that returns the *second* argument. For example, K has : primitive: identity:(:) identity[1;2] 2 The rationale in K is that it is useful in an ammed function that replaces entries of an an array with a result of a dyadic function applied to the old and the supplied value and it is natural to have old value first: @[1 2 3;1;-;20] 1 -18 3 @[1 2 3;1;:;20] 1 20 3 This rationale does not apply to Python, but in the absence of other reasons to choose the order of arguments, Python may as well follow the precedent. Does anyone know a less exotic language that has a dyadic identity? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 From noreply at sourceforge.net Thu Mar 22 23:00:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 15:00:14 -0700 Subject: [ python-Bugs-1686386 ] Python SEGFAULT on invalid superclass access Message-ID: Bugs item #1686386, was opened at 2007-03-22 23:00 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=1686386&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: toxik (ludvig.ericson) Assigned to: Nobody/Anonymous (nobody) Summary: Python SEGFAULT on invalid superclass access Initial Comment: When one uses a class that has derived BaseException in one way or another and uses an invalid super() and calls a function upon that object, Python dies with SIGSEGV. Reproduce code: >>> class X(BaseException): ... def __init__(self): ... super(X, self).__init__(self) ... >>> X() Segmentation fault I could reproduce this on two different Python 2.5 installations. This is as much as I could get from gdb: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1211660624 (LWP 30234)] 0xb7ea601c in _PyObject_GC_Malloc () from /usr/lib/libpython2.5.so.1.0 (gdb) bt #0 0xb7ea601c in _PyObject_GC_Malloc () from /usr/lib/libpython2.5.so.1.0 #1 0xb7ea613b in _PyObject_GC_NewVar () from /usr/lib/libpython2.5.so.1.0 #2 0xb7e4abe4 in PyTuple_New () from /usr/lib/libpython2.5.so.1.0 #3 0xb7e4b48d in ?? () from /usr/lib/libpython2.5.so.1.0 #4 0x00000001 in ?? () #5 0x00000000 in ?? () ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686386&group_id=5470 From noreply at sourceforge.net Thu Mar 22 23:04:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 15:04:37 -0700 Subject: [ python-Feature Requests-1686390 ] csv sniff example Message-ID: Feature Requests item #1686390, was opened at 2007-03-22 22: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=1686390&group_id=5470 Please note that this 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 Private: No Submitted By: Thomas Guettler (guettli) Assigned to: Nobody/Anonymous (nobody) Summary: csv sniff example Initial Comment: Hi, I think the csv module misses an example for the nice sniff method: import csv dialect=csv.Sniffer().sniff(open(csvfile).read(1024)) fd=open(csvfile) for row in csv.reader(fd, dialect): for col in row: print col, print ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1686390&group_id=5470 From noreply at sourceforge.net Thu Mar 22 23:05:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 15:05:46 -0700 Subject: [ python-Feature Requests-1673409 ] datetime module missing some important methods Message-ID: Feature Requests item #1673409, was opened at 2007-03-04 11:59 Message generated for change (Comment added) made by guettli You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673409&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jon Ribbens (jribbens) Assigned to: Tim Peters (tim_one) Summary: datetime module missing some important methods Initial Comment: The datetime module is missing some important methods for interacting with timestamps (i.e. seconds since 1970-01-01T00:00:00). There are methods to convert from a timestamp, i.e. date.fromtimestamp and datetime.fromtimestamp, but there are no methods to convert back. In addition, timedelta has no method for returning the number of seconds it represents (i.e. days*86400+seconds+microseconds/1000000). ---------------------------------------------------------------------- Comment By: Thomas Guettler (guettli) Date: 2007-03-22 22:05 Message: Logged In: YES user_id=22123 Originator: NO Yes, that's true. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673409&group_id=5470 From noreply at sourceforge.net Thu Mar 22 23:09:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 15:09:54 -0700 Subject: [ python-Bugs-1686386 ] Python SEGFAULT on invalid superclass access Message-ID: Bugs item #1686386, was opened at 2007-03-22 23:00 Message generated for change (Comment added) made by ludvig.ericson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686386&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: toxik (ludvig.ericson) Assigned to: Nobody/Anonymous (nobody) Summary: Python SEGFAULT on invalid superclass access Initial Comment: When one uses a class that has derived BaseException in one way or another and uses an invalid super() and calls a function upon that object, Python dies with SIGSEGV. Reproduce code: >>> class X(BaseException): ... def __init__(self): ... super(X, self).__init__(self) ... >>> X() Segmentation fault I could reproduce this on two different Python 2.5 installations. This is as much as I could get from gdb: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1211660624 (LWP 30234)] 0xb7ea601c in _PyObject_GC_Malloc () from /usr/lib/libpython2.5.so.1.0 (gdb) bt #0 0xb7ea601c in _PyObject_GC_Malloc () from /usr/lib/libpython2.5.so.1.0 #1 0xb7ea613b in _PyObject_GC_NewVar () from /usr/lib/libpython2.5.so.1.0 #2 0xb7e4abe4 in PyTuple_New () from /usr/lib/libpython2.5.so.1.0 #3 0xb7e4b48d in ?? () from /usr/lib/libpython2.5.so.1.0 #4 0x00000001 in ?? () #5 0x00000000 in ?? () ---------------------------------------------------------------------- >Comment By: toxik (ludvig.ericson) Date: 2007-03-22 23:09 Message: Logged In: YES user_id=1373326 Originator: YES It might be added that this works (throws an exception) in python 2.4 (though, BaseException does not exist there): TypeError: super() argument 1 must be type, not classobj ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686386&group_id=5470 From noreply at sourceforge.net Thu Mar 22 23:37:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 15:37:20 -0700 Subject: [ python-Bugs-1686386 ] Python SEGFAULT on invalid superclass access Message-ID: Bugs item #1686386, was opened at 2007-03-22 22:00 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686386&group_id=5470 Please note that this 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.5 Status: Open Resolution: None >Priority: 6 Private: No Submitted By: toxik (ludvig.ericson) Assigned to: Nobody/Anonymous (nobody) Summary: Python SEGFAULT on invalid superclass access Initial Comment: When one uses a class that has derived BaseException in one way or another and uses an invalid super() and calls a function upon that object, Python dies with SIGSEGV. Reproduce code: >>> class X(BaseException): ... def __init__(self): ... super(X, self).__init__(self) ... >>> X() Segmentation fault I could reproduce this on two different Python 2.5 installations. This is as much as I could get from gdb: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1211660624 (LWP 30234)] 0xb7ea601c in _PyObject_GC_Malloc () from /usr/lib/libpython2.5.so.1.0 (gdb) bt #0 0xb7ea601c in _PyObject_GC_Malloc () from /usr/lib/libpython2.5.so.1.0 #1 0xb7ea613b in _PyObject_GC_NewVar () from /usr/lib/libpython2.5.so.1.0 #2 0xb7e4abe4 in PyTuple_New () from /usr/lib/libpython2.5.so.1.0 #3 0xb7e4b48d in ?? () from /usr/lib/libpython2.5.so.1.0 #4 0x00000001 in ?? () #5 0x00000000 in ?? () ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-22 22:37 Message: Logged In: YES user_id=849994 Originator: NO This is not new in 2.5. That is does not work with super() in 2.4 is because in 2.4 exceptions are old-style classes. Look at this: >>> class X(Exception): ... def __init__(self): ... Exception.__init__(self, self) ... >>> x=X() >>> str(x) [1] 4396 segmentation fault python2.4 The problem is that str(x) calls str(x) etc. ---------------------------------------------------------------------- Comment By: toxik (ludvig.ericson) Date: 2007-03-22 22:09 Message: Logged In: YES user_id=1373326 Originator: YES It might be added that this works (throws an exception) in python 2.4 (though, BaseException does not exist there): TypeError: super() argument 1 must be type, not classobj ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686386&group_id=5470 From noreply at sourceforge.net Fri Mar 23 03:31:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 19:31:29 -0700 Subject: [ python-Bugs-1686475 ] os.stat() WindowsError 13 when file in use Message-ID: Bugs item #1686475, was opened at 2007-03-22 22: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=1686475&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: d roberts (dcroberts) Assigned to: Nobody/Anonymous (nobody) Summary: os.stat() WindowsError 13 when file in use Initial Comment: Using 2.5 Sept 19, 2006 on Windows XP, 32-bit. os.stat() on an "in use" file (i.e., open by another process) erroneously returns WindowsError [Error 13]. The file stats should be available on an open file, even if you cannot read/write the file itself. Python 2.4 correctly returns the stats on the file. ---------------- CORRECT in 2.4: Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32 >>> import os >>> os.stat('c:\\hiberfil.sys') (33206, 0L, 2, 1, 0, 0, 804311040L, 1173962381, 1173962381, 1069302780) ----------------- ERROR in 2.5: Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 >>> import os >>> os.stat("c:\\hiberfil.sys") Traceback (most recent call last): File "", line 1, in WindowsError: [Error 13] The process cannot access the file because it is being used by another process: 'c:\\hiberfil.sys' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686475&group_id=5470 From noreply at sourceforge.net Fri Mar 23 06:01:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 22:01:02 -0700 Subject: [ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds Message-ID: Bugs item #1683368, was opened at 2007-03-18 23:32 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 Please note that this 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 3000 Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Guido van Rossum (gvanrossum) Summary: object.__init__ shouldn't allow args/kwds Initial Comment: object.__init__ currently allows any amount of args and keywords even though they're ignored. This is inconsistent with other built-ins, like list, that are stricter about what they'll accept. It's also inconsistent with object.__new__, which does throw if any are provided (if the default __init__ is to be used). To reproduce: object.__init__(object(), foo, bar=3) This is a slight irritation when using cooperative super calling. I'd like each class' __init__ to cherry-pick keyword params it accepts and pass the remaining ones up the chain, but right now I can't rely on object.__init__ to throw if there are remaining keywords by that point. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-23 01:01 Message: Logged In: YES user_id=6380 Originator: NO Committed revision 54539. The committed version issues warnings rather than errors when both methods are overridden, to avoid too much breakage. The string.py change was necessary to avoid spurious warnings (with no module/lineno!) and breakage of test_subprocess.py. Something fishy's going on -- is string.Template() used by the warnings module or by site.py??? I'm leaving this bug open but changing the category to Py3k so remind me it needs to be merged and then changed there. ---------------------------------------------------------------------- Comment By: Adam Olsen (rhamphoryncus) Date: 2007-03-22 00:46 Message: Logged In: YES user_id=12364 Originator: NO >> I think it would also help if calling a method via super() didn't allow >> positional arguments. > > That's absurd, *except* for __init__(), where it could make sense > depending on the style of cooperation used. But not enough to enforce this > in the language; in Py3k you will be able to enforce this on a per-class > basis. The vast majority of "positional" arguments can also be given via name. The rare exceptions (primarily C functions) may not cooperate well anyway, so you're trading a relatively obscure limitation for better error detection. Perhaps not that important though, since it could be taught as bad style unless absolutely needed. >> Having two mixins with the same method name and >> without a common parent class is just not sane. > > Right. This is a cornerstone of cooperative multiple inheritance that > sometimes seems to be forgotten; there is a big difference between defining > a method and extending a method, and only extending methods can make super > calls. > > The __init__ case is an exception, because there's no requirement that a > subclass have a signature compatible with the superclass (if you don't get > this, read up on constructors in C++ or Java). I understand the desire for it to be an exception, I fail to see how it actually is one. The namespace/signature conflicts exist just the same. The only way I can see to handle incompatible signatures is to add a flag that says "I am the *ONLY* class allowed to subclass X" (triggering an error if violated), have super() entirely bypass it, and then call X.__init__() directly. Even that doesn't handle X's superclasses being subclassed more than once, and it looks pretty complicated/obscure anyway. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-22 00:28 Message: Logged In: YES user_id=6380 Originator: NO > I think it would also help if calling a method via super() didn't allow > positional arguments. That's absurd, *except* for __init__(), where it could make sense depending on the style of cooperation used. But not enough to enforce this in the language; in Py3k you will be able to enforce this on a per-class basis. > Having two mixins with the same method name and > without a common parent class is just not sane. Right. This is a cornerstone of cooperative multiple inheritance that sometimes seems to be forgotten; there is a big difference between defining a method and extending a method, and only extending methods can make super calls. The __init__ case is an exception, because there's no requirement that a subclass have a signature compatible with the superclass (if you don't get this, read up on constructors in C++ or Java). ---------------------------------------------------------------------- Comment By: Adam Olsen (rhamphoryncus) Date: 2007-03-21 20:44 Message: Logged In: YES user_id=12364 Originator: NO I think the avoidance of super() is largely *because* of this kind of leniency. Consider this snippet on python 2.3: class Base(object): def __init__(self, foo=None, *args, **kwargs): super(Base, self).__init__(foo, *args, **kwargs) Base(foo='bar') Base('bar', 42) Base('bar', 42, x=7) All pass silently, no error checking. Now consider a python 3.0 version, with a strict object.__init__: class Base: def __init__(self, foo=None, *, y='hi', **kwargs): super(Base, self).__init__(**kwargs) Base(foo='bar') # Valid, accepted Base('bar', 42) # Raises exception Base('bar', x=7) # Raises exception The error checking added by this bug/patch and the error checking added by PEP 3102 (keyword-only arguments) make super a lot more sane. I think it would also help if calling a method via super() didn't allow positional arguments. If the base class's arguments can't be given as keyword args then you probably should call it explicitly, rather than relying on super()'s MRO. I was also going to suggest super() should automagically create empty methods your parent classes don't have, but then I realized you really should have a base class that asserts the lack of such an automagic method: class Base(object): def mymethod(self, myonlyarg='hello world'): assert not hasattr(super(Base, self), 'mymethod') By the time you reach this base class you will have stripped off any extra arguments that your subclasses added, leaving you with nothing to pass up (and nothing to pass to). Having two mixins with the same method name and without a common parent class is just not sane. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2007-03-21 19:16 Message: Logged In: YES user_id=593130 Originator: NO I ask myself, what should I expect from the documentation... >>> object.__init__.__doc__ 'x.__init__(...) initializes x; see x.__class__.__doc__ for signature' >>> object.__class__ >>> type.__doc__ "type(object) -> the object's type\ntype(name, bases, dict) -> a new type" and I still don't know ;-). ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-21 18:48 Message: Logged In: YES user_id=1747060 Originator: YES Holding the strict version for 3 makes sense to me. Let me know if you need anything more on my end... thanks for the fast turnaround. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-21 18:42 Message: Logged In: YES user_id=6380 Originator: NO Well, but since it's been like this for a long time, I don't want to gratuitously break code. At least not in 2.6. So I'm rejecting the stricter patch for 2.6. (However, if you want to submit patches that would fix these breakages anyway, be my guest.) ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-21 18:03 Message: Logged In: YES user_id=1747060 Originator: YES Looks good. I skimmed briefly the tests you mentioned. The issue with test_array appears to be exactly the kind of bug this is intended to identify: it calls array.__init__(...), but array doesn't have its own initializer, so object's is used. I'd guess that the others are failing due to whatever the problem with pickling is (test_descr uses pickling). I haven't looked into that yet. I'm sure cooperative super calling of __init__ isn't all that common (it seems like the mechanism itself isn't used much yet, and may not be until it's done via keyword) but it doesn't seem like such a bad practice, especially when mixins are in the picture. There doesn't seem to be a great alternative. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-20 17:24 Message: Logged In: YES user_id=6380 Originator: NO I should mention that if we can't get the strict version of this in 2.6, we should be able to get it into 3.0. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-20 16:54 Message: Logged In: YES user_id=6380 Originator: NO Here's a stricter version. Unfortunately it breaks a couple of standard modules; this is a confirmation of my doubts whether the style of cooperative super calling of __init__ that you use is really the most common or "best practice". So far I have only fixed string.py (which would otherwise prevent extensions from being built); I haven't looked into why the other tests fail: test_array, test_cpickle, test_descr, test_pickle (and maybe more?). My conclusion: this would probably break too much code to be worth it. So I'll have to revert to the previous version. But anyway, here it is for your perusal. File Added: new_init_strict.patch ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-19 21:27 Message: Logged In: YES user_id=1747060 Originator: YES I think making the check more rigid is a good idea, since this should throw: class a(object): def __init__(self, foo): super(a, self).__init__(foo) def __new__(cls, foo): return object.__new__(cls) a(1) (minor typo in the patch: "solution it" -> "solution is") ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 19:35 Message: Logged In: YES user_id=6380 Originator: NO This smells enough like a new feature that it couldn't go into 2.5. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 19:31 Message: Logged In: YES user_id=6380 Originator: NO Attached is a patch that implements this proposal, adding copious commentary. It doesn't seem to break anything in the test suite. I wonder if we should even make the check more rigid: check the argument list if either the current method *is* overridden or the other one *is not* overridden. This would make super calls check the arguments even if the other method is overridden. What do you think? File Added: new_init.patch ---------------------------------------------------------------------- Comment By: Blake Ross (blakeross) Date: 2007-03-19 18:45 Message: Logged In: YES user_id=1747060 Originator: YES Makes sense. I don't think we can ever be completely correct here since we're inferring intent from the presence of __init__/__new__ that's liable to be wrong in some cases, but it's likely correct often enough that it's worth doing. If I understand correctly, we want to be more forgiving iff one of the two methods is used, so it seems like we should be complaining if both are used *or* if neither is used. After all, I could add a __new__ to my coop use case and I'd still want object to complain. If that's the case, both object_new and object_init should be complaining if ((tp->tp_new == object_new && tp->tp_init == object_init) || (tp->tp_new != object_new && tp->tp_init != object_init)). Of course, for the paranoid, there's always the risk that __new__ will modify these class functions and change the outcome :) For instance, if a class had a __new__ and no __init__ and its __new__ changed __new__ back to object.__new__, object_init on that run would be fooled into thinking it's using the defaults for both and would complain. I think this could only be fixed in type_call, which is rather ugly...but then, this *is* a special case of the "call __init__ after __new__" behavior, and we're trying to solve it within the methods themselves. Perhaps this last point is academic enough to be ignored...I don't know why anyone would do this, although the language makes it possible. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 16:01 Message: Logged In: YES user_id=6380 Originator: NO I'll try to explain why I did it this way. I was considering the single inheritance case implementing an Immutable object, which overrides __new__ but has no need to override __init__ (since it's too late to do anything in __init__ for an Immutable object). Since the __init__ still gets called it would be annoying to have to override it just to make the error go away if there was a check in __init__. The other case is overriding __init__ without overriding __new__, which is the most common way of doing Mutable objects; here you wouldn't want __new__ to complain about extra args. So the only time when you'd want complaints is if both __new__ and __init__ are the defaults, in which case it doesn't really matter whether you implement this in __init__ or in __new__, so I arbitrarily chose __new__. I wasn't thinking of your use case at the time though (cooperative super calls to __init__, which still isn't something I engage in on a day-to-day basis). I wonder if the right thing to do wouldn't be to implement the same check both in __init__ and in __new__. Am I makign sense? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-19 04:56 Message: Logged In: YES user_id=849994 Originator: NO I don't really understand either why object_new() checks the arguments, not object_init(): """ static int object_init(PyObject *self, PyObject *args, PyObject *kwds) { return 0; } /* If we don't have a tp_new for a new-style class, new will use this one. Therefore this should take no arguments/keywords. However, this new may also be inherited by objects that define a tp_init but no tp_new. These objects WILL pass argumets to tp_new, because it gets the same args as tp_init. So only allow arguments if we aren't using the default init, in which case we expect init to handle argument parsing. */ static PyObject * object_new(PyTypeObject *type, PyObject *args, PyObject *kwds) { if (type->tp_init == object_init && (PyTuple_GET_SIZE(args) || (kwds && PyDict_Check(kwds) && PyDict_Size(kwds)))) { PyErr_SetString(PyExc_TypeError, "default __new__ takes no parameters"); return NULL; } return type->tp_alloc(type, 0); } """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 From noreply at sourceforge.net Fri Mar 23 06:19:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 22:19:57 -0700 Subject: [ python-Bugs-1686200 ] logging package failure for NTEventLogHandler Message-ID: Bugs item #1686200, was opened at 2007-03-22 10:00 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686200&group_id=5470 Please note that this 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 Private: No Submitted By: j vickroy (jvickroy) >Assigned to: Vinay Sajip (vsajip) Summary: logging package failure for NTEventLogHandler Initial Comment: When using a configuration file to initialize a logger, a failure occurs in the logging.config.fileConfig() procedure such that the NTEventLogHandler is not created. The failure is not observed when the NTEventLogHandler is explicitly defined in a script. The attached script and two configuration initialization files demonstrate the failure as seen on a Microsoft Windows XP Pro computer running service pack 2 and Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)]. DETAILED DESCRIPTION: When the attached script is run with EventLog.ini, on my Windows XP computer, the failure appears to occur at line 118: h = apply(klass, args) in File "C:\Python24\lib\logging\config.py" because for: klass: logging.handlers.NTEventLogHandler local variable *args* is: ('logging.config.fileConfig bug test') after line 116: args = cp.get(sectname, "args") but local variable *args* is: logging.config.fileConfig bug test after line 117: args = eval(args, vars(logging)) The behavior for the other two handlers is as follows: klass = logging.StreamHandler args is: (sys.stdout,) ... after line 116 args is: (', mode 'w' at 0x00A1E068>,) ... after line 117 klass = logging.handlers.TimedRotatingFileHandler args is: ('fileConfig-test.log', 'midnight', 1, 3) ... after line 116 args is: ('fileConfig-test.log', 'midnight', 1, 3) ... after line 117 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-22 22:19 Message: Logged In: YES user_id=33168 Originator: NO Vinay, any ideas? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686200&group_id=5470 From noreply at sourceforge.net Fri Mar 23 08:56:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Mar 2007 00:56:37 -0700 Subject: [ python-Bugs-1686200 ] logging package failure for NTEventLogHandler Message-ID: Bugs item #1686200, was opened at 2007-03-22 17:00 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686200&group_id=5470 Please note that this 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 Private: No Submitted By: j vickroy (jvickroy) Assigned to: Vinay Sajip (vsajip) Summary: logging package failure for NTEventLogHandler Initial Comment: When using a configuration file to initialize a logger, a failure occurs in the logging.config.fileConfig() procedure such that the NTEventLogHandler is not created. The failure is not observed when the NTEventLogHandler is explicitly defined in a script. The attached script and two configuration initialization files demonstrate the failure as seen on a Microsoft Windows XP Pro computer running service pack 2 and Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)]. DETAILED DESCRIPTION: When the attached script is run with EventLog.ini, on my Windows XP computer, the failure appears to occur at line 118: h = apply(klass, args) in File "C:\Python24\lib\logging\config.py" because for: klass: logging.handlers.NTEventLogHandler local variable *args* is: ('logging.config.fileConfig bug test') after line 116: args = cp.get(sectname, "args") but local variable *args* is: logging.config.fileConfig bug test after line 117: args = eval(args, vars(logging)) The behavior for the other two handlers is as follows: klass = logging.StreamHandler args is: (sys.stdout,) ... after line 116 args is: (', mode 'w' at 0x00A1E068>,) ... after line 117 klass = logging.handlers.TimedRotatingFileHandler args is: ('fileConfig-test.log', 'midnight', 1, 3) ... after line 116 args is: ('fileConfig-test.log', 'midnight', 1, 3) ... after line 117 ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2007-03-23 07:56 Message: Logged In: YES user_id=308438 Originator: NO The problem is that the args line in the config file should evaluate to a tuple. You have, in EventLog.ini, the line args=('logging.config.fileConfig bug test') Which does not evaluate a tuple. If you add a trailing comma, args=('logging.config.fileConfig bug test',) then everything is fine. It's an easy mistake to make ;-) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-23 05:19 Message: Logged In: YES user_id=33168 Originator: NO Vinay, any ideas? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686200&group_id=5470 From noreply at sourceforge.net Fri Mar 23 11:15:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Mar 2007 03:15:20 -0700 Subject: [ python-Bugs-1686475 ] os.stat() WindowsError 13 when file in use Message-ID: Bugs item #1686475, was opened at 2007-03-23 02:31 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686475&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: d roberts (dcroberts) >Assigned to: Martin v. L?wis (loewis) Summary: os.stat() WindowsError 13 when file in use Initial Comment: Using 2.5 Sept 19, 2006 on Windows XP, 32-bit. os.stat() on an "in use" file (i.e., open by another process) erroneously returns WindowsError [Error 13]. The file stats should be available on an open file, even if you cannot read/write the file itself. Python 2.4 correctly returns the stats on the file. ---------------- CORRECT in 2.4: Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32 >>> import os >>> os.stat('c:\\hiberfil.sys') (33206, 0L, 2, 1, 0, 0, 804311040L, 1173962381, 1173962381, 1069302780) ----------------- ERROR in 2.5: Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 >>> import os >>> os.stat("c:\\hiberfil.sys") Traceback (most recent call last): File "", line 1, in WindowsError: [Error 13] The process cannot access the file because it is being used by another process: 'c:\\hiberfil.sys' ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-23 10:15 Message: Logged In: YES user_id=849994 Originator: NO May this be related to rev. 42230 - "Drop C library for stat/fstat on Windows." ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686475&group_id=5470 From noreply at sourceforge.net Fri Mar 23 10:47:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Mar 2007 02:47:15 -0700 Subject: [ python-Bugs-1686597 ] descrintro: error describing __new__ behavior Message-ID: Bugs item #1686597, was opened at 2007-03-23 06: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=1686597&group_id=5470 Please note that this 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 Private: No Submitted By: Gabriel Genellina (gagenellina) Assigned to: Nobody/Anonymous (nobody) Summary: descrintro: error describing __new__ behavior Initial Comment: descrintro (http://www.python.org/download/releases/2.2.3/descrintro/#__new__) linked from http://www.python.org/doc/newstyle/ still says: "__new__ must return an object. [...] If you return an object of a different class, its __init__ method will be called." But since Revision 26220 - Modified Sat Apr 6 01:05:01 2002 UTC (4 years, 11 months ago) by gvanrossum: "Changed new-style class instantiation so that when C's __new__ method returns something that's not a C instance, its __init__ is not called. [SF bug #537450]" That is, exactly the opposite as said on descrintro. The documentation for __new__ in the Reference manual, section 3.4.1, is correct and says: "If __new__() does not return an instance of cls, then the new instance's __init__() method will not be invoked." Note that the modified behavior was already present on version 2.2.3 (and later) so updating the document currently at /download/releases/2.2.3/ would be fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686597&group_id=5470 From noreply at sourceforge.net Fri Mar 23 11:24:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Mar 2007 03:24:56 -0700 Subject: [ python-Bugs-1686475 ] os.stat() WindowsError 13 when file in use Message-ID: Bugs item #1686475, was opened at 2007-03-23 03:31 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686475&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: d roberts (dcroberts) Assigned to: Martin v. L?wis (loewis) Summary: os.stat() WindowsError 13 when file in use Initial Comment: Using 2.5 Sept 19, 2006 on Windows XP, 32-bit. os.stat() on an "in use" file (i.e., open by another process) erroneously returns WindowsError [Error 13]. The file stats should be available on an open file, even if you cannot read/write the file itself. Python 2.4 correctly returns the stats on the file. ---------------- CORRECT in 2.4: Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32 >>> import os >>> os.stat('c:\\hiberfil.sys') (33206, 0L, 2, 1, 0, 0, 804311040L, 1173962381, 1173962381, 1069302780) ----------------- ERROR in 2.5: Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 >>> import os >>> os.stat("c:\\hiberfil.sys") Traceback (most recent call last): File "", line 1, in WindowsError: [Error 13] The process cannot access the file because it is being used by another process: 'c:\\hiberfil.sys' ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-23 11:24 Message: Logged In: YES user_id=21627 Originator: NO It certainly is; Python is likely opening the file in the wrong mode now. I'll investigate, although contributions would be welcome. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-23 11:15 Message: Logged In: YES user_id=849994 Originator: NO May this be related to rev. 42230 - "Drop C library for stat/fstat on Windows." ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686475&group_id=5470 From noreply at sourceforge.net Fri Mar 23 11:36:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Mar 2007 03:36:01 -0700 Subject: [ python-Bugs-1685773 ] tarfile file names under win32 Message-ID: Bugs item #1685773, was opened at 2007-03-22 04:12 Message generated for change (Comment added) made by gagenellina You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685773&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ralf (indi4source) Assigned to: Lars Gust?bel (gustaebel) Summary: tarfile file names under win32 Initial Comment: the tarfile module uses normpath() to store the file name in the archive. Under win32 this results in pathes with backslashes and possible a leading "\". This confuses the unix tar command. I suppose the following commands instead of just normpath(): path = normpath (path) path = path.replace ("\\", "/") path = path.lstrip ("/") ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-03-23 07:36 Message: Logged In: YES user_id=479790 Originator: NO tarfile already attempts to manage backslashes well, using os.path.normpath(path).replace(os.sep, "/") Can you provide a small script demonstrating the failure? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685773&group_id=5470 From noreply at sourceforge.net Fri Mar 23 14:35:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Mar 2007 06:35:34 -0700 Subject: [ python-Bugs-978833 ] SSL-ed sockets don't close correct? Message-ID: Bugs item #978833, was opened at 2004-06-24 11:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978833&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 8 Private: No Submitted By: kxroberto (kxroberto) Assigned to: Martin v. L?wis (loewis) Summary: SSL-ed sockets don't close correct? Initial Comment: When testing FTP over SSL I have strong doubt, that ssl-ed sockets are not closed correctly. (This doesn't show with https because nobody takes care about whats going on "after the party".) See the following : --- I need to run FTP over SSL from windows (not shitty sftp via ssh etc!) as explained on http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html (good variant 3: FTP_TLS ) I tried to learn from M2Crypto's ftpslib.py (uses OpenSSL - not Pythons SSL) and made a wrapper for ftplib.FTP using Pythons SSL. I wrap the cmd socket like: self.voidcmd('AUTH TLS') ssl = socket.ssl(self.sock, self.key_file, self.cert_file) import httplib self.sock = httplib.FakeSocket(self.sock, ssl) self.file = self.sock.makefile('rb') Everything works ok, if I don't SSL the data port connection, but only the If I SSL the data port connection too, it almosts work, but ... self.voidcmd('PBSZ 0') self.voidcmd('PROT P') wrap the data connection with SSL: ssl = socket.ssl(conn, self.key_file, self.cert_file) import httplib conn = httplib.FakeSocket(conn, ssl) than in retrbinary it hangs endless in the last 'return self.voidresp()'. all data of the retrieved file is already correctly in my basket! The ftp server just won't send the final '226 Transfer complete.' on the cmd socket. Why? def retrbinary(self, cmd, callback, blocksize=8192, rest=None): self.voidcmd('TYPE I') conn = self.transfercmd(cmd, rest) fp = conn.makefile('rb') while 1: #data = conn.recv(blocksize) data = fp.read() #blocksize) if not data: break callback(data) fp.close() conn.close() return self.voidresp() what could be reason? The server is a ProFTPD 1.2.9 Server. I debugged, that the underlying (Shared)socket of the conn object is really closed. (If I simly omit the self.voidresp(), I have one file in the box, but subsequent ftp communication on that connection is not anymore correct.) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-23 14:35 Message: Logged In: YES user_id=21627 Originator: NO Ok, I reverted this patch in r54543 and r54544. arigo, what do you think about the alternative patch (fakeclose.diff), which drops the ssl object in FakeSocket.close()? I don't think we can add an explicit close operation for 2.5.x to SSL objects, so we have to continue to rely on reference counting. File Added: fakeclose.diff ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-11-20 12:33 Message: Logged In: YES user_id=4771 Originator: NO Martin, I think the rev 50844 is wrong. To start with, it goes clearly against the documentation for makefile() which states that both the socket and the pseudo-file can be closed independently. What httplib.py was doing was correct. I could write a whole essay about the twisted history of socket.py. It would boil down to: in r43746, Georg removed a comment that was partially out-of-date, but that was essential in explaining why there was no self._sock.close() in _socketobject.close(): because the original purpose of _socketobject was to implement dup(), so that multiple _socketobjects could refer to the same underlying _sock. The latter would close automagically when its reference counter dropped to zero. (This means that your check-in also made dup() stop working on all platforms.) The real OP's problem is that the _ssl object keeps a reference to the underlying _sock as well, as kxroberto pointed out. We need somewhere code that closes the _ssl object... For reference, PyPy - which doesn't have strong refcounting guarantees - added the equivalent of an explicit usage counter in the C socket object, and socket.py calls methods on its underlying object to increment and decrement that counter. It looks like a solution for CPython too - at least, relying on refcounting is bad, if only because - as you have just proved - it creates confusion. (Also, httplib/urllib have their own explicitly-refcounted wrappers...) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-07-26 14:14 Message: Logged In: YES user_id=21627 This is now fixed in 50844. I won't backport it to 2.4, as it may cause working code to fail. For example, httplib would fail since it would already close the connection in getresponse, when the response object should still be able to read from the connection. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-07-03 14:03 Message: Logged In: YES user_id=21627 Can you please try the attached patch? It makes sure _socketobject.close really closes the socket, rather than relying on reference counting to close it. ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-05-11 14:05 Message: Logged In: YES user_id=972995 Testing it with Python2.5a2, the problem is still there. Without the .shutdown(2) (or .shutdown(1)) patch to the httplib.SharedSocket (base for FakeSocket), the ftps example freezes on the cmd channel, because the SSL'ed data channel doesn't close/terminate --> FTPS server doesn't respond on the cmd channel. The ftps example is most specific to show the bug. Yet you can also easily blow up a HTTPS-server with this decent test code who only opens (bigger!) files and closes without reading everything: Python 2.5a2 (r25a2:45740, May 11 2006, 11:25:30) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. Robert's Interactive Python - TAB=complete import sys,os,re,string,time,glob,thread,pdb >>> import urllib >>> l=[] >>> for i in range(10): ... f=urllib.urlopen('https://srv/big-Python-2.5a2.tgz') ... f.close() ... l.append(f) ... >>> => in the (apache) servers ssl_engine_log you can see that connections remain open (until apache times out after 2 minutes) and lots of extra apache daemons are started! => f.close() doesn't really close the connection (until it is __del__'ed ) Trying around I found that the original undeleted f.fp._ssl is most probably the cause and holds the real socket open. a f.fp._sock.close() doesn't close also - but only when del f.fp._ssl is done. (only a f.fp._sock._sock.close() would force the close). The original fp is held in closures of .readline(s)/__iter__/next... -- I now tried an alternative patch (instead of the shutdown(2)-patch), which also so far seems to cure everything . Maybe thats the right solution for the bug: --- httplib.py.orig 2006-05-11 11:25:32.000000000 +0200 +++ httplib.py 2006-05-11 13:45:07.000000000 +0200 @@ -970,6 +970,7 @@ self._shared.decref() self._closed = 1 self._shared = None + self._ssl = None class SSLFile(SharedSocketClient): """File-like object wrapping an SSL socket.""" @@ -1085,6 +1086,7 @@ def close(self): SharedSocketClient.close(self) self._sock = self.__class__._closedsocket() + self._ssl = None def makefile(self, mode, bufsize=None): if mode != 'r' and mode != 'rb': -------------- In another application with SSL'ed SMTP connections there arose similar problems. I also worked around the problem in smtplib.py so far in a similar style: def close(self): self.realsock.shutdown(2) self.realsock.close() --- Yet, the right patch maybe (not tested extensively so far): --- Lib-orig/smtplib.py 2006-05-03 13:10:40.000000000 +0200 +++ Lib/smtplib.py 2006-05-11 13:50:12.000000000 +0200 @@ -142,6 +142,7 @@ sendall = send def close(self): + self.sslobj = None self.realsock.close() class SSLFakeFile: @@ -161,7 +162,7 @@ return str def close(self): - pass + self.sslobj = None def quoteaddr(addr): """Quote a subset of the email addresses defined by RFC 821. ------------------ -robert ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2005-09-24 21:45 Message: Logged In: YES user_id=972995 Now I managed to solve the problem for me with attached patch of httplib.py: a explicit shutdown ( 2 or 1 ) of the (faked) ssl'ed socket solves it. I still guess the ssl'ed socket (ssl dll) should do that auto on sock.close() Thus I leave it as a bug HERE. Right? [ I also have the hope, that this also solves the ssl-eof-errors with https (of some of my users; will see this in future) *** \usr\src\py24old/httplib.py Sat Sep 24 21:35:28 2005 --- httplib.py Sat Sep 24 21:37:48 2005 *************** class SharedSocket: *** 899,904 **** --- 899,905 ---- self._refcnt -= 1 assert self._refcnt >= 0 if self._refcnt == 0: + self.sock.shutdown(2) self.sock.close() def __del__(self): ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2005-09-24 21:06 Message: Logged In: YES user_id=972995 I retried that again with py2.4.1. The problem/bug is still there. In attachment I supplied a full FTPS client test_ftpslib.py with simple test function - ready to run into the problem: At the end of ftp.retrlines 'return self.voidresp()' freezes : waiting eternally for response bytes at the command port. the same at the end of .storelines after the data is transfered on the data port. My preliminary guess is still, that python's ssl has a severe (EOF?) problem closing a socket/connection correctly. obviously this problem doesn't show up with https because everything is done on one connection - no dependency on a correct socket/connect close signal. (from other https communication with some proxies in between my users get ssl-eof-error errors also. I still can't solve that bug too. this shows python's ssl has a severe EOF bug with complex https also - or cannot handle certain situations correct.) I learned the FTPS/TLS client from M2crypto's ftpslib. the only difference in (transposed) logic, that I can see is, that M2crpyto uses an additional line "conn.set_session(self.sock.get_session())" during setup of the data port ssl connection. I don't know what it is, pythons ssl doesn't have sucht "session"-functions, but I think it has no severe meaning.? Robert ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-22 06:14 Message: Logged In: YES user_id=357491 Since I believe this was fixed with the patch Tino mentions and Roberto has not replied, I am closing as fixed. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-17 01:18 Message: Logged In: YES user_id=357491 Is this still a problem for you, Roberto, with Python 2.4a2? ---------------------------------------------------------------------- Comment By: Tino Lange (tinolange) Date: 2004-07-11 00:30 Message: Logged In: YES user_id=212920 Hi Roberto! Today a patch for _ssl.c was checked in (see #945642) that might solve your problem, too. Could you please grab the *next* alpha (this will be Python 2.4 Alpha 2) and test and report afterwards if it is solved? Thanks for your help! Tino ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978833&group_id=5470 From noreply at sourceforge.net Fri Mar 23 18:49:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Mar 2007 10:49:11 -0700 Subject: [ python-Bugs-1686475 ] os.stat() WindowsError 13 when file in use Message-ID: Bugs item #1686475, was opened at 2007-03-22 22:31 Message generated for change (Comment added) made by dcroberts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686475&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: d roberts (dcroberts) Assigned to: Martin v. L?wis (loewis) Summary: os.stat() WindowsError 13 when file in use Initial Comment: Using 2.5 Sept 19, 2006 on Windows XP, 32-bit. os.stat() on an "in use" file (i.e., open by another process) erroneously returns WindowsError [Error 13]. The file stats should be available on an open file, even if you cannot read/write the file itself. Python 2.4 correctly returns the stats on the file. ---------------- CORRECT in 2.4: Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32 >>> import os >>> os.stat('c:\\hiberfil.sys') (33206, 0L, 2, 1, 0, 0, 804311040L, 1173962381, 1173962381, 1069302780) ----------------- ERROR in 2.5: Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 >>> import os >>> os.stat("c:\\hiberfil.sys") Traceback (most recent call last): File "", line 1, in WindowsError: [Error 13] The process cannot access the file because it is being used by another process: 'c:\\hiberfil.sys' ---------------------------------------------------------------------- >Comment By: d roberts (dcroberts) Date: 2007-03-23 13:49 Message: Logged In: YES user_id=1750755 Originator: YES Taking your hint, I just looked at the code in 42230 which uses the Win32 GetFileAttributesEx() function. This function does indeed return an error for an in-use file. Not sure if this is a "feature" or "bug" in the underlying Windows function. I did try FindFirstFile(), which is able to return info on an in-use file. Not sure if this is a reasonable alternative to GFAE(), but wanted to make folks aware of the possibility. It's probably slower, since it can handle wild-cards, and returns a handle for subsequent calls to FindNextFile(). The handle must be closed with FindClose(). I'm not sure what underlying mechanism FindFirstFile() uses, but I'm assuming it accesses the "directory" to get its information, rather than trying to access the file itself. FWIW. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-23 06:24 Message: Logged In: YES user_id=21627 Originator: NO It certainly is; Python is likely opening the file in the wrong mode now. I'll investigate, although contributions would be welcome. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-23 06:15 Message: Logged In: YES user_id=849994 Originator: NO May this be related to rev. 42230 - "Drop C library for stat/fstat on Windows." ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686475&group_id=5470 From noreply at sourceforge.net Fri Mar 23 20:59:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Mar 2007 12:59:34 -0700 Subject: [ python-Bugs-1685000 ] DoS asyncore vulnerability Message-ID: Bugs item #1685000, was opened at 2007-03-21 02:15 Message generated for change (Comment added) made by rushing You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685000&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: billiejoex (billiejoex) Assigned to: Nobody/Anonymous (nobody) Summary: DoS asyncore vulnerability Initial Comment: DoS asyncore vulnerability asyncore, independently if used with select() or poll(), suffers a DoS-type vulnerability when a high number of simultaneous connections to handle simultaneously is reached. The number of maximum connections is system-dependent as well as the type of error raised. I attached two simple Proof of Concept scripts demonstrating such bug. If you want to try the behaviours listed below run the attached "asyncore_server.py" and "asyncore_client.py" scripts on your local workstation. On my Windows XP system (Python 2.5), independently if asyncore has been used to develop a server or a client, the error is raised by select() inside asyncore's "poll" function when 512 (socket_map's elements) simultaneous connections are reached. Here's the traceback I get: [...] connections: 510 connections: 511 connections: 512 Traceback (most recent call last): File "C:\scripts\asyncore_server.py", line 38, in asyncore.loop() File "C:\Python25\lib\asyncore.py", line 191, in loop poll_fun(timeout, map) File "C:\Python25\lib\asyncore.py", line 121, in poll r, w, e = select.select(r, w, e, timeout) ValueError: too many file descriptors in select() On my Linux Ubuntu 6.10 (kernel 2.6.17-10, Python 2.5) different type of errors are raised depending on the application (client or server). In an asyncore-based client the error is raised by socket module (dispatcher's "self.socket" attribute) inside 'connect' method of 'dispatcher' class: [...] connections: 1018 connections: 1019 connections: 1020 connections: 1021 Traceback (most recent call last): File "asyncore_client.py", line 31, in File "asyncore.py", line 191, in loop File "asyncore.py", line 138, in poll File "asyncore.py", line 80, in write File "asyncore.py", line 76, in write File "asyncore.py", line 395, in handle_write_event File "asyncore_client.py", line 24, in handle_connect File "asyncore_client.py", line 9, in __init__ File "asyncore.py", line 257, in create_socket File "socket.py", line 156, in __init__ socket.error: (24, 'Too many open files') On an asyncore-based server the error is raised by socket module (dispatcher's "self.socket" attribute) inside 'accept' method of 'dispatcher' class: [...] connections: 1019 connections: 1020 connections: 1021 Traceback (most recent call last): File "asyncore_server.py", line 38, in File "asyncore.py", line 191, in loop File "asyncore.py", line 132, in poll File "asyncore.py", line 72, in read File "asyncore.py", line 68, in read File "asyncore.py", line 384, in handle_read_event File "asyncore_server.py", line 16, in handle_accept File "asyncore.py", line 321, in accept File "socket.py", line 170, in accept socket.error: (24, 'Too many open files') ---------------------------------------------------------------------- Comment By: Sam Rushing (rushing) Date: 2007-03-23 12:59 Message: Logged In: YES user_id=73736 Originator: NO The problem is that there's no portable way to know what the limit on file descriptors is. The 'classic' for select/poll is the FD_SETSIZE macro. But on some operating systems there is no such limit. [e.g., win32 does not use the 'lowest-free-int' model common to unix]. I believe that in Medusa there was a derived class or extension that counted the number of open sockets, and limited it, using something like a semaphore. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685000&group_id=5470 From noreply at sourceforge.net Fri Mar 23 21:37:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Mar 2007 13:37:37 -0700 Subject: [ python-Bugs-978833 ] SSL-ed sockets don't close correct? Message-ID: Bugs item #978833, was opened at 2004-06-24 09:57 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978833&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 8 Private: No Submitted By: kxroberto (kxroberto) Assigned to: Martin v. L?wis (loewis) Summary: SSL-ed sockets don't close correct? Initial Comment: When testing FTP over SSL I have strong doubt, that ssl-ed sockets are not closed correctly. (This doesn't show with https because nobody takes care about whats going on "after the party".) See the following : --- I need to run FTP over SSL from windows (not shitty sftp via ssh etc!) as explained on http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html (good variant 3: FTP_TLS ) I tried to learn from M2Crypto's ftpslib.py (uses OpenSSL - not Pythons SSL) and made a wrapper for ftplib.FTP using Pythons SSL. I wrap the cmd socket like: self.voidcmd('AUTH TLS') ssl = socket.ssl(self.sock, self.key_file, self.cert_file) import httplib self.sock = httplib.FakeSocket(self.sock, ssl) self.file = self.sock.makefile('rb') Everything works ok, if I don't SSL the data port connection, but only the If I SSL the data port connection too, it almosts work, but ... self.voidcmd('PBSZ 0') self.voidcmd('PROT P') wrap the data connection with SSL: ssl = socket.ssl(conn, self.key_file, self.cert_file) import httplib conn = httplib.FakeSocket(conn, ssl) than in retrbinary it hangs endless in the last 'return self.voidresp()'. all data of the retrieved file is already correctly in my basket! The ftp server just won't send the final '226 Transfer complete.' on the cmd socket. Why? def retrbinary(self, cmd, callback, blocksize=8192, rest=None): self.voidcmd('TYPE I') conn = self.transfercmd(cmd, rest) fp = conn.makefile('rb') while 1: #data = conn.recv(blocksize) data = fp.read() #blocksize) if not data: break callback(data) fp.close() conn.close() return self.voidresp() what could be reason? The server is a ProFTPD 1.2.9 Server. I debugged, that the underlying (Shared)socket of the conn object is really closed. (If I simly omit the self.voidresp(), I have one file in the box, but subsequent ftp communication on that connection is not anymore correct.) ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2007-03-23 20:37 Message: Logged In: YES user_id=4771 Originator: NO The fakeclose.diff patch looks safe enough. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-23 13:35 Message: Logged In: YES user_id=21627 Originator: NO Ok, I reverted this patch in r54543 and r54544. arigo, what do you think about the alternative patch (fakeclose.diff), which drops the ssl object in FakeSocket.close()? I don't think we can add an explicit close operation for 2.5.x to SSL objects, so we have to continue to rely on reference counting. File Added: fakeclose.diff ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-11-20 11:33 Message: Logged In: YES user_id=4771 Originator: NO Martin, I think the rev 50844 is wrong. To start with, it goes clearly against the documentation for makefile() which states that both the socket and the pseudo-file can be closed independently. What httplib.py was doing was correct. I could write a whole essay about the twisted history of socket.py. It would boil down to: in r43746, Georg removed a comment that was partially out-of-date, but that was essential in explaining why there was no self._sock.close() in _socketobject.close(): because the original purpose of _socketobject was to implement dup(), so that multiple _socketobjects could refer to the same underlying _sock. The latter would close automagically when its reference counter dropped to zero. (This means that your check-in also made dup() stop working on all platforms.) The real OP's problem is that the _ssl object keeps a reference to the underlying _sock as well, as kxroberto pointed out. We need somewhere code that closes the _ssl object... For reference, PyPy - which doesn't have strong refcounting guarantees - added the equivalent of an explicit usage counter in the C socket object, and socket.py calls methods on its underlying object to increment and decrement that counter. It looks like a solution for CPython too - at least, relying on refcounting is bad, if only because - as you have just proved - it creates confusion. (Also, httplib/urllib have their own explicitly-refcounted wrappers...) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-07-26 12:14 Message: Logged In: YES user_id=21627 This is now fixed in 50844. I won't backport it to 2.4, as it may cause working code to fail. For example, httplib would fail since it would already close the connection in getresponse, when the response object should still be able to read from the connection. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-07-03 12:03 Message: Logged In: YES user_id=21627 Can you please try the attached patch? It makes sure _socketobject.close really closes the socket, rather than relying on reference counting to close it. ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-05-11 12:05 Message: Logged In: YES user_id=972995 Testing it with Python2.5a2, the problem is still there. Without the .shutdown(2) (or .shutdown(1)) patch to the httplib.SharedSocket (base for FakeSocket), the ftps example freezes on the cmd channel, because the SSL'ed data channel doesn't close/terminate --> FTPS server doesn't respond on the cmd channel. The ftps example is most specific to show the bug. Yet you can also easily blow up a HTTPS-server with this decent test code who only opens (bigger!) files and closes without reading everything: Python 2.5a2 (r25a2:45740, May 11 2006, 11:25:30) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. Robert's Interactive Python - TAB=complete import sys,os,re,string,time,glob,thread,pdb >>> import urllib >>> l=[] >>> for i in range(10): ... f=urllib.urlopen('https://srv/big-Python-2.5a2.tgz') ... f.close() ... l.append(f) ... >>> => in the (apache) servers ssl_engine_log you can see that connections remain open (until apache times out after 2 minutes) and lots of extra apache daemons are started! => f.close() doesn't really close the connection (until it is __del__'ed ) Trying around I found that the original undeleted f.fp._ssl is most probably the cause and holds the real socket open. a f.fp._sock.close() doesn't close also - but only when del f.fp._ssl is done. (only a f.fp._sock._sock.close() would force the close). The original fp is held in closures of .readline(s)/__iter__/next... -- I now tried an alternative patch (instead of the shutdown(2)-patch), which also so far seems to cure everything . Maybe thats the right solution for the bug: --- httplib.py.orig 2006-05-11 11:25:32.000000000 +0200 +++ httplib.py 2006-05-11 13:45:07.000000000 +0200 @@ -970,6 +970,7 @@ self._shared.decref() self._closed = 1 self._shared = None + self._ssl = None class SSLFile(SharedSocketClient): """File-like object wrapping an SSL socket.""" @@ -1085,6 +1086,7 @@ def close(self): SharedSocketClient.close(self) self._sock = self.__class__._closedsocket() + self._ssl = None def makefile(self, mode, bufsize=None): if mode != 'r' and mode != 'rb': -------------- In another application with SSL'ed SMTP connections there arose similar problems. I also worked around the problem in smtplib.py so far in a similar style: def close(self): self.realsock.shutdown(2) self.realsock.close() --- Yet, the right patch maybe (not tested extensively so far): --- Lib-orig/smtplib.py 2006-05-03 13:10:40.000000000 +0200 +++ Lib/smtplib.py 2006-05-11 13:50:12.000000000 +0200 @@ -142,6 +142,7 @@ sendall = send def close(self): + self.sslobj = None self.realsock.close() class SSLFakeFile: @@ -161,7 +162,7 @@ return str def close(self): - pass + self.sslobj = None def quoteaddr(addr): """Quote a subset of the email addresses defined by RFC 821. ------------------ -robert ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2005-09-24 19:45 Message: Logged In: YES user_id=972995 Now I managed to solve the problem for me with attached patch of httplib.py: a explicit shutdown ( 2 or 1 ) of the (faked) ssl'ed socket solves it. I still guess the ssl'ed socket (ssl dll) should do that auto on sock.close() Thus I leave it as a bug HERE. Right? [ I also have the hope, that this also solves the ssl-eof-errors with https (of some of my users; will see this in future) *** \usr\src\py24old/httplib.py Sat Sep 24 21:35:28 2005 --- httplib.py Sat Sep 24 21:37:48 2005 *************** class SharedSocket: *** 899,904 **** --- 899,905 ---- self._refcnt -= 1 assert self._refcnt >= 0 if self._refcnt == 0: + self.sock.shutdown(2) self.sock.close() def __del__(self): ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2005-09-24 19:06 Message: Logged In: YES user_id=972995 I retried that again with py2.4.1. The problem/bug is still there. In attachment I supplied a full FTPS client test_ftpslib.py with simple test function - ready to run into the problem: At the end of ftp.retrlines 'return self.voidresp()' freezes : waiting eternally for response bytes at the command port. the same at the end of .storelines after the data is transfered on the data port. My preliminary guess is still, that python's ssl has a severe (EOF?) problem closing a socket/connection correctly. obviously this problem doesn't show up with https because everything is done on one connection - no dependency on a correct socket/connect close signal. (from other https communication with some proxies in between my users get ssl-eof-error errors also. I still can't solve that bug too. this shows python's ssl has a severe EOF bug with complex https also - or cannot handle certain situations correct.) I learned the FTPS/TLS client from M2crypto's ftpslib. the only difference in (transposed) logic, that I can see is, that M2crpyto uses an additional line "conn.set_session(self.sock.get_session())" during setup of the data port ssl connection. I don't know what it is, pythons ssl doesn't have sucht "session"-functions, but I think it has no severe meaning.? Robert ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-22 05:14 Message: Logged In: YES user_id=357491 Since I believe this was fixed with the patch Tino mentions and Roberto has not replied, I am closing as fixed. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-16 23:18 Message: Logged In: YES user_id=357491 Is this still a problem for you, Roberto, with Python 2.4a2? ---------------------------------------------------------------------- Comment By: Tino Lange (tinolange) Date: 2004-07-10 22:30 Message: Logged In: YES user_id=212920 Hi Roberto! Today a patch for _ssl.c was checked in (see #945642) that might solve your problem, too. Could you please grab the *next* alpha (this will be Python 2.4 Alpha 2) and test and report afterwards if it is solved? Thanks for your help! Tino ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978833&group_id=5470 From noreply at sourceforge.net Fri Mar 23 21:50:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Mar 2007 13:50:12 -0700 Subject: [ python-Bugs-1687125 ] cannot catch KeyboardInterrupt when using curses getkey() Message-ID: Bugs item #1687125, was opened at 2007-03-23 20: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=1687125&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: al65536 (al65536) Assigned to: Nobody/Anonymous (nobody) Summary: cannot catch KeyboardInterrupt when using curses getkey() Initial Comment: #!/usr/bin/python import curses # Will works scr=curses.initscr() key=-1 try: try: key=scr.getkey() except: pass except KeyboardInterrupt: key="CTRL-C" curses.endwin() print key # Will fail scr=curses.initscr() key=-1 try: key=scr.getkey() except KeyboardInterrupt: key="CTRL-C" curses.endwin() print key ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1687125&group_id=5470 From noreply at sourceforge.net Fri Mar 23 21:51:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Mar 2007 13:51:55 -0700 Subject: [ python-Bugs-1687125 ] cannot catch KeyboardInterrupt when using curses getkey() Message-ID: Bugs item #1687125, was opened at 2007-03-23 20:50 Message generated for change (Comment added) made by al65536 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1687125&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: al65536 (al65536) Assigned to: Nobody/Anonymous (nobody) Summary: cannot catch KeyboardInterrupt when using curses getkey() Initial Comment: #!/usr/bin/python import curses # Will works scr=curses.initscr() key=-1 try: try: key=scr.getkey() except: pass except KeyboardInterrupt: key="CTRL-C" curses.endwin() print key # Will fail scr=curses.initscr() key=-1 try: key=scr.getkey() except KeyboardInterrupt: key="CTRL-C" curses.endwin() print key ---------------------------------------------------------------------- >Comment By: al65536 (al65536) Date: 2007-03-23 20:51 Message: Logged In: YES user_id=1751488 Originator: YES python file attached File Added: cursesbug.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1687125&group_id=5470 From noreply at sourceforge.net Fri Mar 23 22:51:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Mar 2007 14:51:18 -0700 Subject: [ python-Bugs-1687163 ] Inconsistent Exceptions for Readonly Attributes Message-ID: Bugs item #1687163, was opened at 2007-03-23 16:51 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=1687163&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent Exceptions for Readonly Attributes Initial Comment: Attempting assignment to a readonly attribute raises an Attribute error for pure Python attributes but raises a TypeError for C readonly attributes. I think the AttributeError is the correct exception. >>> class A(object): ... _x = [] ... ... @property ... def x(self): ... return self._x ... >>> a = A() >>> a.x = None Traceback (most recent call last): a.x = None AttributeError: can't set attribute >>> def f(): ... yield None >>> g = f() >>> g.gi_frame = None Traceback (most recent call last): g.gi_frame = None TypeError: readonly attribute ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1687163&group_id=5470 From noreply at sourceforge.net Fri Mar 23 23:12:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Mar 2007 15:12:01 -0700 Subject: [ python-Bugs-1687163 ] Inconsistent Exceptions for Readonly Attributes Message-ID: Bugs item #1687163, was opened at 2007-03-23 17:51 Message generated for change (Comment added) made by jackdied You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1687163&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent Exceptions for Readonly Attributes Initial Comment: Attempting assignment to a readonly attribute raises an Attribute error for pure Python attributes but raises a TypeError for C readonly attributes. I think the AttributeError is the correct exception. >>> class A(object): ... _x = [] ... ... @property ... def x(self): ... return self._x ... >>> a = A() >>> a.x = None Traceback (most recent call last): a.x = None AttributeError: can't set attribute >>> def f(): ... yield None >>> g = f() >>> g.gi_frame = None Traceback (most recent call last): g.gi_frame = None TypeError: readonly attribute ---------------------------------------------------------------------- >Comment By: Jack Diederich (jackdied) Date: 2007-03-23 18:12 Message: Logged In: YES user_id=591932 Originator: NO I think this has something peculiar to frames, for instance: Python 2.5 (r25:51908, Sep 25 2006, 17:50:07) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> f = 'asdf' >>> f.strip = 42 Traceback (most recent call last): File "", line 1, in AttributeError: 'str' object attribute 'strip' is read-only >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1687163&group_id=5470 From noreply at sourceforge.net Fri Mar 23 23:16:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Mar 2007 15:16:56 -0700 Subject: [ python-Bugs-1687163 ] Inconsistent Exceptions for Readonly Attributes Message-ID: Bugs item #1687163, was opened at 2007-03-23 16:51 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1687163&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent Exceptions for Readonly Attributes Initial Comment: Attempting assignment to a readonly attribute raises an Attribute error for pure Python attributes but raises a TypeError for C readonly attributes. I think the AttributeError is the correct exception. >>> class A(object): ... _x = [] ... ... @property ... def x(self): ... return self._x ... >>> a = A() >>> a.x = None Traceback (most recent call last): a.x = None AttributeError: can't set attribute >>> def f(): ... yield None >>> g = f() >>> g.gi_frame = None Traceback (most recent call last): g.gi_frame = None TypeError: readonly attribute ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-03-23 17:16 Message: Logged In: YES user_id=80475 Originator: YES Readonly methods throw an AttributeError, but readonly members (anything defined in PyMemberDef with an RO or READONLY flag) raise a TypeError. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2007-03-23 17:12 Message: Logged In: YES user_id=591932 Originator: NO I think this has something peculiar to frames, for instance: Python 2.5 (r25:51908, Sep 25 2006, 17:50:07) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> f = 'asdf' >>> f.strip = 42 Traceback (most recent call last): File "", line 1, in AttributeError: 'str' object attribute 'strip' is read-only >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1687163&group_id=5470 From noreply at sourceforge.net Sat Mar 24 00:52:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Mar 2007 16:52:37 -0700 Subject: [ python-Bugs-1687163 ] Inconsistent Exceptions for Readonly Attributes Message-ID: Bugs item #1687163, was opened at 2007-03-23 16:51 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1687163&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent Exceptions for Readonly Attributes Initial Comment: Attempting assignment to a readonly attribute raises an Attribute error for pure Python attributes but raises a TypeError for C readonly attributes. I think the AttributeError is the correct exception. >>> class A(object): ... _x = [] ... ... @property ... def x(self): ... return self._x ... >>> a = A() >>> a.x = None Traceback (most recent call last): a.x = None AttributeError: can't set attribute >>> def f(): ... yield None >>> g = f() >>> g.gi_frame = None Traceback (most recent call last): g.gi_frame = None TypeError: readonly attribute ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-03-23 18:52 Message: Logged In: YES user_id=80475 Originator: YES Here's the one line change: Index: Python/structmember.c =================================================================== --- Python/structmember.c (revision 54557) +++ Python/structmember.c (working copy) @@ -160,7 +160,7 @@ if ((l->flags & READONLY) || l->type == T_STRING) { - PyErr_SetString(PyExc_TypeError, "readonly attribute"); + PyErr_SetString(PyExc_AttributeError, "readonly attribute"); Four of the tests will need to be updated: test_csv test_descr test_generators test_os ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2007-03-23 17:16 Message: Logged In: YES user_id=80475 Originator: YES Readonly methods throw an AttributeError, but readonly members (anything defined in PyMemberDef with an RO or READONLY flag) raise a TypeError. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2007-03-23 17:12 Message: Logged In: YES user_id=591932 Originator: NO I think this has something peculiar to frames, for instance: Python 2.5 (r25:51908, Sep 25 2006, 17:50:07) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> f = 'asdf' >>> f.strip = 42 Traceback (most recent call last): File "", line 1, in AttributeError: 'str' object attribute 'strip' is read-only >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1687163&group_id=5470 From noreply at sourceforge.net Sat Mar 24 07:01:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Mar 2007 23:01:06 -0700 Subject: [ python-Feature Requests-1673203 ] add identity function Message-ID: Feature Requests item #1673203, was opened at 2007-03-03 19:21 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 Please note that this 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 Private: No Submitted By: paul rubin (phr) Assigned to: Raymond Hettinger (rhettinger) Summary: add identity function Initial Comment: Requested and assigned to Raymond at his suggestion: http://groups.google.com/group/comp.lang.python/msg/603870361743c85c There should be an identify function identity(x)=x. I suggest it also take and ignore an optional second arg: identity(x1,x2)=x1. The second arg can be useful in some generator expressions: foo = (x for x in bar if condition(x) and identity(True, memoize(x)) That allows calling memoize (or some other function) on the selected elements in the genexp, and disposing of the returned value. It's sort of like the const function (K combinator) to go along with the identity function's I combinator. OK, the above is not really in the functional spirit, but it's been useful. There could conceivably be also an actual const function const(k)=partial(identity,k) but I can't remember needing that in Python code. The two-arg identity function (uncurried version of const) is probably enough. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-24 02:01 Message: Logged In: YES user_id=1344176 Originator: NO -1 on adding the identity function anywhere in the stdlib. This isn't just a 1-line function, it's only 10 characters: "lambda x:x". ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 17:26 Message: Logged In: YES user_id=1679533 Originator: NO > Neither will submitting a patch with a reference count bug :-). Bleh, generational garbage collectors are where its at anyways. ;P ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2007-03-22 16:57 Message: Logged In: YES user_id=591932 Originator: NO Let's put this thread on hold until we get a pronouncement. I don't think there is anything additional to be said. Alexander, don't worry, I didn't think you were talking about my patch ;) and don't worry about people writing sub-optimal code. If you start doing that you'll never get any sleep. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-22 16:34 Message: Logged In: YES user_id=835142 Originator: NO I need to clarify that my comment about a buggy patch was responding to twobitsprite, not to jackdied whose post I noticed only after I hit submit. Jackdied's patch is correct, but my concern is that with identity in operators, functional programmers will start passing identity instead of None as func to map(func, ..) that will result in much slower code. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 16:31 Message: Logged In: YES user_id=1679533 Originator: NO josiah, My appologies for not being hip to the latest python dev news. I would have no problem with putting the function in a module like functools/itertools/operator/whatever, I just thought something like that might belong with map/filter/etc... so, if that's where they're going, I can just from functools import * and go on my merry way. I was just responding to your argument that defining it yourself would be just as easy as importing from a module. +1 on Raymond's patch (not that I expect my vote to count much, being some random guy :P) execpt for it going into operator, being as map/etc are going somewhere else... either way, I think it's silly to mobe map/etc out of builtins, but hey... what am I gonna do about it? :P ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-22 16:18 Message: Logged In: YES user_id=835142 Originator: NO Raising "Haskel is better than Python" argument is unlikely to win you friends here. Neither will submitting a patch with a reference count bug :-). ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2007-03-22 16:15 Message: Logged In: YES user_id=591932 Originator: NO Raymond, please make a pronouncement. +1 on adding it to the operator module. Lots of one liners go there. -1000 to having it take more than one argument. If I saw this identity(ob, 42) for the first time (or second, or ...) I would have to look up what it does. As a plain identity function it is obvious. Patch to operator.c, liboperator.tex, test_operator.py, NEWS attached. Raymond, there isn't a good section in the doc for this function so I added it to the logical operators. The fact that there isn't a good section for it might be a mark against it being included. It is a couple times faster than the python version which isn't exciting. sprat:~/src/python-rw> ./python Lib/timeit.py -s "from operator import identity" "identity(None)" 10000000 loops, best of 3: 0.161 usec per loop sprat:~/src/python-rw> ./python Lib/timeit.py -s "def identity(ob): return ob" "identity(None)" 1000000 loops, best of 3: 0.421 usec per loop File Added: identity.patch ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-22 16:13 Message: Logged In: YES user_id=341410 Originator: NO Your patch isn't what was asked for by other users. The Python equivalent to what was asked for was: identity = lambda arg0, *args: arg0 Regardless, being that it is a functional language construct, it's not going to make it into __builtins__. Never mind that adding to __builtins__ has a higher requirement than in other portions of the standard library. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-22 16:06 Message: Logged In: YES user_id=341410 Originator: NO > Well, I'm suggesting that it be in __builtins__, but whatever... You apparently didn't get the memo; map, filter, reduce, etc., are all going to be placed into functools and removed from __builtins__. Adding identity to __builtins__ is not going to happen. Further, your preferred programming language not being Python is not topical to the discussion. If you want Haskell, and your boss isn't letting you use it, please don't complain here. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 16:06 Message: Logged In: YES user_id=1679533 Originator: NO --- bltinmodule-orig.c 2007-03-22 16:00:21.452245559 -0400 +++ bltinmodule.c 2007-03-22 15:56:19.353115310 -0400 @@ -69,6 +69,17 @@ return PyNumber_Absolute(v); } +static PyObject * +builtin_identity(PyObject *self, PyObject *v) +{ + return v; +} + +PyDoc_STRVAR(identity_doc, +"identity(x) -> x\n\ +\n\ +The identity function. Simply returns is first argument."); + PyDoc_STRVAR(abs_doc, "abs(number) -> number\n\ \n\ @@ -2281,6 +2292,7 @@ #endif {"vars", builtin_vars, METH_VARARGS, vars_doc}, {"zip", builtin_zip, METH_VARARGS, zip_doc}, + {"identity", builtin_identity, METH_O, identity_doc}, {NULL, NULL}, }; ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 15:37 Message: Logged In: YES user_id=1679533 Originator: NO Well, I'm suggesting that it be in __builtins__, but whatever... If I had it my way I'd program in Haskell every chance I got anyways, I only use python because my boss/co-workers prefer it. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-22 15:32 Message: Logged In: YES user_id=835142 Originator: NO > I can't believe there is such resistance for something > as trivial as a function which returns it's first argument. The resistance is precisely because it is so trivial. As josiahcarlson suggested before, "Not all x line functions should be built into Python." Compare the following two alternatives: def identity(*args): return args[0] and from functools import identity The first option is only slightly longer than the second, but it is actually much clearer. With the second option, it is not obvious that identity takes an arbitrary number of arguments and if it does, which argument it will return. The only advantage is that if coded in C, functools.identity may be slightly faster. However, given that >>> dis(lambda x: x) 1 0 LOAD_FAST 0 (x) 3 RETURN_VALUE I am not sure a C coded identity can significantly beat it. The real savings would come if python compiler could optimize away calls to identity altogether, but nobody has explained how that could be done or why it would be easier to optimize away identity that lambda x:x. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 15:25 Message: Logged In: YES user_id=1679533 Originator: NO Also, map like functions start to look a bit ugly (of course, this is overly simplistic, but serves as an example): def my_map(func, items): acc = [] for item in items: if func == None: acc.append(item) else: acc.append(func(item)) return acc which has the obvious overhead of a test for every iteration. Of course, you could just make two versions of the for loop, one which applies and one which doesn't, but that immetiately violates once-and-only-once and also forces the function to be overly concerned with what it is passed. this is _much_ cleaner: def my_map2(func, items): return [func(i) for i in items] and the user of the function can simply pass as and this keeps the details of what to do with the items outside of the function. Without identity, whenever I want to allow the user to inject code to modify data, I have to account for the fact that they might want to do nothing with it, and so I have to test for None constantly. This is simply bad practice and, IMHO, violates everything python stands for, which is elegance, simplicity and "batteries included", right? If you want I patch, I can try to provide one; however I have very minimal knowledge of how the vm works, and I've only looked at the code a couple of times. In fact, I might even go ahead and do that, it can't be that difficult. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 15:06 Message: Logged In: YES user_id=1679533 Originator: NO It still feels like an ugly hack for something so simple. I can't believe there is such resistance for something as trivial as a function which returns it's first argument. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-22 13:49 Message: Logged In: YES user_id=341410 Originator: NO twobitsprite: your use-case is different from that of others. While you could use an identity function for your purposes, a lambda would work just fine. Regardless, there is call overhead, which can only be reduced by not performing a call at all. In terms of an identity function versus tuple creation and indexing as per belopolsky's suggestion... >>> timeit.Timer("x(1+2,3+4)", "x = lambda *args:args[-1]").timeit() 0.99381552025397468 >>> timeit.Timer("(1+2,3+4)[-1]", "").timeit() 0.49153579156927663 Tuple is faster. Just use a tuple. ---------------------------------------------------------------------- Comment By: Memotype (twobitsprite) Date: 2007-03-22 09:06 Message: Logged In: YES user_id=1679533 Originator: NO I also would like to have a built-in identity function (in fact, I found this by googling "python identity function"). My use-case is a bit different. I ofter find myself wanting to simply specify a function for be used in a loop, something like: def f(items): if something: wrapper = int else: wrapper = identity for item in items: yield wrapper(item) of course, usually it's a bit more complex than that, but you get the idea... and I supposed its actually more like the previous use-case than I thought. I realize I could just use "lambda x: x", but I feel that comes with an unnecessary performance impact for something so trivial. I don't know how much python does to compile built-in functions, but I imagine that the identity function can be mostly optimized out at compile time if it were built-in. Just my two-cents. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-19 15:57 Message: Logged In: YES user_id=835142 Originator: NO I have just realized that the requested functionality is known in C as the comma operator. I often find myself writing "return Py_INCREF(o),o;" in my C code, but I cannot really defend that idiom against "Py_INCREF(o); return o;" alternative. My personal reason is entirely C-specific, if followed an if(), the first form does not require curly braces. In any case, comma operator can be emulated in python as exp1,expr2,expr3 -> (exp1,expr2,expr3)[-1] Since multi-argument "identity" is likely to be rejected, my proposal to alter the order of arguments is moot. My other suggestion that with identity, map(None, ..) should be deprecated in favor of map(identity, ..) is probably an arument against the identity proposal now. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-19 15:05 Message: Logged In: YES user_id=1344176 Originator: NO I can see adding the 1-argument form to operator or functools (as it's useful in functional programming), but the 2-argument form you've suggested is right out. If you really feel the need to torture a "for" loop into a genexp/listcomp like that, foo = (x for x in bar if condition(x) and [memoize(x)]) does the same thing using today's capabilities. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-12 16:06 Message: Logged In: YES user_id=341410 Originator: NO Not all x line functions should be built into Python. Further, Python's standard syntax offers an infix operator that does the same thing (though in slightly different order as described below, you can reorder with minimal effort). identity(X, Y) -> (Y and False) or X Also, the only use-case that you are provided and that I can imagine, are examples like you provide where one is changing state within a statement (if, elif, while, etc.) or expression (generator, list comprehension, conditional, etc.). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 09:21 Message: Logged In: YES user_id=835142 Originator: NO 1. If this proposal is accepted, it will make sense to deprecate the use of None as an identity function in map: >>> map(None, range(10)) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] 2. Some other languages have an dyadic identity function that returns the *second* argument. For example, K has : primitive: identity:(:) identity[1;2] 2 The rationale in K is that it is useful in an ammed function that replaces entries of an an array with a result of a dyadic function applied to the old and the supplied value and it is natural to have old value first: @[1 2 3;1;-;20] 1 -18 3 @[1 2 3;1;:;20] 1 20 3 This rationale does not apply to Python, but in the absence of other reasons to choose the order of arguments, Python may as well follow the precedent. Does anyone know a less exotic language that has a dyadic identity? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 From noreply at sourceforge.net Sat Mar 24 12:02:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Mar 2007 04:02:59 -0700 Subject: [ python-Bugs-1687314 ] Round funcion Message-ID: Bugs item #1687314, was opened at 2007-03-24 11: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=1687314&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gust1 (gust1) Assigned to: Nobody/Anonymous (nobody) Summary: Round funcion Initial Comment: I don't quite know if it is a bug, but when I do this in the interpreter (see blow) the third return is not what i wanted. >>> round(5.5, 3) 5.5 >>> round(5.5555555555, 3) 5.556 >>> round(5.5555555555, 2) 5.5599999999999996 I created a function to solve this. It can be found attached to this report. I'm sorry but I'm not English so I don't speak this language very good. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1687314&group_id=5470 From noreply at sourceforge.net Sat Mar 24 12:37:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Mar 2007 04:37:02 -0700 Subject: [ python-Bugs-1687314 ] Round funcion Message-ID: Bugs item #1687314, was opened at 2007-03-24 11:02 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1687314&group_id=5470 Please note that this 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.5 >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Gust1 (gust1) Assigned to: Nobody/Anonymous (nobody) Summary: Round funcion Initial Comment: I don't quite know if it is a bug, but when I do this in the interpreter (see blow) the third return is not what i wanted. >>> round(5.5, 3) 5.5 >>> round(5.5555555555, 3) 5.556 >>> round(5.5555555555, 2) 5.5599999999999996 I created a function to solve this. It can be found attached to this report. I'm sorry but I'm not English so I don't speak this language very good. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-24 11:37 Message: Logged In: YES user_id=849994 Originator: NO This is invalid. See http://www.python.org/doc/faq/general/#why-are-floating-point-calculations-so-inaccurate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1687314&group_id=5470 From noreply at sourceforge.net Sat Mar 24 15:39:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Mar 2007 07:39:41 -0700 Subject: [ python-Bugs-1619641 ] format error in 2.5 ref.pdf in section 5.3.4 Calls Message-ID: Bugs item #1619641, was opened at 2006-12-20 19:12 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619641&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: cwm42 (cwm42) Assigned to: Nobody/Anonymous (nobody) Summary: format error in 2.5 ref.pdf in section 5.3.4 Calls Initial Comment: Formatting error in Python 2.5 ref.pdf page 41, section 5.3.4 Calls, downloaded from docs.python.org on 12/20/06. The first part of the table which is centered in the html version is shifted off the right side of page and clipped. This problem occurs with both kpdf and kghostview. ---------------------------------------------------------------------- >Comment By: ?iga Seilnacht (zseil) Date: 2007-03-24 15:39 Message: Logged In: YES user_id=1326842 Originator: NO This was fixed with patch #1489771 in rev. 54559, 54560 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619641&group_id=5470 From noreply at sourceforge.net Sat Mar 24 17:38:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Mar 2007 09:38:14 -0700 Subject: [ python-Bugs-1595164 ] texinfo library documentation fails to build Message-ID: Bugs item #1595164, was opened at 2006-11-12 20:15 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595164&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Diekhans (diekhans) Assigned to: Nobody/Anonymous (nobody) Summary: texinfo library documentation fails to build Initial Comment: Attempting to build the texinfo documentation generates the error (args-out-of-range 2931944 2931946). This occurs in download of 2.5 latex doc and from trunk of svn tree. elisp stack trace attached. It would be really nice if texinfo doc was still available for download. ---------------------------------------------------------------------- >Comment By: ?iga Seilnacht (zseil) Date: 2007-03-24 17:38 Message: Logged In: YES user_id=1326842 Originator: NO This should be fixed with r52974 and r52975: http://svn.python.org/view?view=rev&rev=52974 I can't test it on Windows, so someone else should close this bug if it is fixed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-30 21:59 Message: Logged In: YES user_id=21627 Originator: NO pekon, it would be quite helpful if you could resolve this. It would be best if you could check out the subversion trunk or release25-maint branch, and then provide a patch that solves it all :-) After applying your (correct) patch, I still get such an error, so I guess there are more problems in the tex source. ---------------------------------------------------------------------- Comment By: Petr Konecny (pekon) Date: 2006-11-30 21:55 Message: Logged In: YES user_id=828085 Originator: NO After changing libmsilib.tex I made some manual fixes in python-lib.texi and was able to get .info files. I am attaching diff, which shows what is broken. --- python-lib.texi 2006-11-30 12:54:04.626177825 -0800 +++ python-lib.texi.fixed 2006-11-30 12:53:28.767367718 -0800 @@ -30395,7 +30395,7 @@ QName wrapper. This can be used to wrap a QName attribute value, in order to get proper namespace handling on output. @var{text_or_uri} is a string containing the QName value, -in the form @{@{}uri{@}@}local, or, if the tag argument is given, +in the form @{uri@}local, or, if the tag argument is given, the URI part of a QName. If @var{tag} is given, the first argument is interpreted as an URI, and this argument is interpreted as a local name. @@ -49305,8 +49305,6 @@ @findex EDQUOT Quota exceeded @end table -\ifx\locallinewidth\undefined\newlength@{\locallinewidth@}@end ifinfo -\setlength@{\locallinewidth@}@{\linewidth@} @node ctypes, , errno, Generic Operating System Services @section A foreign function library for Python. @@ -51073,12 +51071,14 @@ Here is the wrapping with @code{ctypes}: - at example>>> from ctypes import c_int, WINFUNCTYPE, windll + at example +>>> from ctypes import c_int, WINFUNCTYPE, windll >>> from ctypes.wintypes import HWND, LPCSTR, UINT >>> prototype = WINFUNCTYPE(c_int, HWND, LPCSTR, LPCSTR, c_uint) >>> paramflags = (1, "hwnd", 0), (1, "text", "Hi"), (1, "caption", None), (1, "flags", 0) >>> MessageBox = prototype(("MessageBoxA", windll.user32), paramflags) ->>>@end example +>>> + at end example The MessageBox foreign function can now be called in these ways: @example @@ -51101,12 +51101,14 @@ Here is the wrapping with @code{ctypes}: - at example>>> from ctypes import POINTER, WINFUNCTYPE, windll + at example +>>> from ctypes import POINTER, WINFUNCTYPE, windll >>> from ctypes.wintypes import BOOL, HWND, RECT >>> prototype = WINFUNCTYPE(BOOL, HWND, POINTER(RECT)) >>> paramflags = (1, "hwnd"), (2, "lprect") >>> GetWindowRect = prototype(("GetWindowRect", windll.user32), paramflags) ->>>@end example +>>> + at end example Functions with output parameters will automatically return the output parameter value if there is a single one, or a tuple containing the @@ -59352,7 +59354,8 @@ . Example usage: - at examplefrom wsgiref.simple_server import make_server, demo_app + at example +from wsgiref.simple_server import make_server, demo_app httpd = make_server('', 8000, demo_app) print "Serving HTTP on port 8000..." ---------------------------------------------------------------------- Comment By: Petr Konecny (pekon) Date: 2006-11-30 21:42 Message: Logged In: YES user_id=828085 Originator: NO I believe this problem is triggered by a typo in lib/libmsilib.tex:347 \begin{classdesc}{Feature}{database, id, title, desc, display\optional{, level=1\optional{, parent\optional\{, directory\optional{, attributes=0}}}} I think it should look like this: \begin{classdesc}{Feature}{database, id, title, desc, display\optional{, level=1\optional{, parent\optional{, directory\optional{, attributes=0}}}}} With this change I am able to build python-lib.texi. However makeinfo fails: makeinfo --footnote-style end --fill-column 72 --paragraph-indent 0 --output=python-lib.info python-lib.texi python-lib.texi:30398: Unmatched }. python-lib.texi:30398: Misplaced {. python-lib.texi:36389: warning: @strong{Note...} produces a spurious cross-reference in Info; reword to avoid that. python-lib.texi:49309: Unmatched `@end'. python-lib.texi:51076: Unknown command `example>>>'. python-lib.texi:51082: Unmatched `@end'. python-lib.texi:51104: Unknown command `example>>>'. python-lib.texi:51110: Unmatched `@end'. python-lib.texi:59355: Unknown command `examplefrom'. python-lib.texi:59366: `@end' expected `table', but saw `example'. makeinfo: Removing output file `python-lib.info' due to errors; use --force to preserve. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 22:47 Message: Logged In: YES user_id=21627 Can you find out what is causing this error? If not, would you be interested in rewriting this in Python? (AFAICT, there really is no reason that this conversion is written in elisp) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595164&group_id=5470 From noreply at sourceforge.net Sat Mar 24 17:40:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Mar 2007 09:40:15 -0700 Subject: [ python-Bugs-1568429 ] broken info files generation Message-ID: Bugs item #1568429, was opened at 2006-09-30 20:49 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568429&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Arkadiusz Miskiewicz (arekm) Assigned to: Nobody/Anonymous (nobody) Summary: broken info files generation Initial Comment: Hi, Currently make -C Doc/info will not work. There are bugs in *.tex files which prevent py2texinfo from working. Also even after fixing these there are some weird constructs which later make makeinfo go mad. Take a look at http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/python- info.patch which has some fixes for that. This one is important: - level=1\optional{, parent\optional\{, directory\optional{, - attributes=0}}}} + level=1\optional{, parent\optional{, directory\optional{, + attributes=0}}}}} - unmatched {} + one wrongly quoted { The other thing is using quote enviroment which is unknown to py2texinfo - change it to quotation. ---------------------------------------------------------------------- >Comment By: ?iga Seilnacht (zseil) Date: 2007-03-24 17:40 Message: Logged In: YES user_id=1326842 Originator: NO This is a duplicate of bug #1595164: http://www.python.org/sf/1595164 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-02 17:06 Message: Logged In: YES user_id=21627 Can you please attach your proposed change as an "svn diff" for the version you are referring to? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568429&group_id=5470 From noreply at sourceforge.net Sat Mar 24 18:26:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Mar 2007 10:26:25 -0700 Subject: [ python-Bugs-1647489 ] zero-length match confuses re.finditer() Message-ID: Bugs item #1647489, was opened at 2007-01-29 22:35 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1647489&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jacques Frechet (jfrechet) >Assigned to: Nobody/Anonymous (nobody) Summary: zero-length match confuses re.finditer() Initial Comment: Hi! re.finditer() seems to incorrectly increment the current position immediately after matching a zero-length substring. For example: >>> [m.groups() for m in re.finditer(r'(^z*)|(\w+)', 'abc')] [('', None), (None, 'bc')] What happened to the 'a'? I expected this result: [('', None), (None, 'abc')] Perl agrees with me: % perl -le 'print defined($1)?"\"$1\"":"undef",",",defined($2)?"\"$2\"":"undef" while "abc" =~ /(z*)|(\w+)/g' "",undef undef,"abc" "",undef Similarly, if I remove the ^: >>> [m.groups() for m in re.finditer(r'(z*)|(\w+)', 'abc')] [('', None), ('', None), ('', None), ('', None)] Now all of the letters have fallen through the cracks! I expected this result: [('', None), (None, 'abc'), ('', None)] Again, perl agrees: % perl -le 'print defined($1)?"\"$1\"":"undef",",",defined($2)?"\"$2\"":"undef" while "abc" =~ /(z*)|(\w+)/g' "",undef undef,"abc" "",undef If this bug has already been reported, I apologize -- I wasn't able to find it here. I haven't looked at the code for the re module, but this seems like the sort of bug that might have been accidentally introduced in order to try to prevent the same zero-length match from being returned forever. Thanks, Jacques ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1647489&group_id=5470 From noreply at sourceforge.net Sat Mar 24 19:07:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Mar 2007 11:07:06 -0700 Subject: [ python-Bugs-1666318 ] shutil.copytree doesn't preserve directory permissions Message-ID: Bugs item #1666318, was opened at 2007-02-22 17:26 Message generated for change (Comment added) made by thomaswaldmann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666318&group_id=5470 Please note that this 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 Private: No Submitted By: Jeff McNeil (j_mcneil) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.copytree doesn't preserve directory permissions Initial Comment: I am using shutil.copytree to setup new user home directories within an automated system. The copy2 function is called in order to copy individual files and preserve stat data. However, copytree simply calls os.mkdir and leaves directory creation at the mercy of my current umask (in my case, that's daemon context - 0). I've got to then iterate through the newly copied tree and set permissions on each individual subdirectory. Adding a simple copystat(src, dst) on line 112 of shutil.py fixes the problem. The result should be uniform; either preserve permissions across the board, or leave it to the mercy of the caller. I know there's an enhancement request already open to supply a 'func=' kw argument to copytree. ---------------------------------------------------------------------- Comment By: Thomas Waldmann (thomaswaldmann) Date: 2007-03-24 19:07 Message: Logged In: YES user_id=100649 Originator: NO I can confirm this bug. For MoinMoin wiki, we solved that by duplicating this function to our own tree and we did exactly the proposed change: Adding a simple copystat(src, dst) on line 112 of shutil.py (right below os.mkdir) fixes this problem. I also suggest to remove that XXX comment in that function. With the proposed fix, it gets usable and thus is not only example code any more. BUT: for avoiding problems on win32, a second fix needs to be done. For MoinMoin, we call this wrapper around shutil.copystat from our copytree function: def copystat(src, dst): """Copy stat bits from src to dst This should be used when shutil.copystat would be used on directories on win32 because win32 does not support utime() for directories. According to the official docs written by Microsoft, it returns ENOACCES if the supplied filename is a directory. Looks like a trainee implemented the function. """ if sys.platform == 'win32' and S_ISDIR(os.stat(dst)[ST_MODE]): if os.name == 'nt': st = os.stat(src) mode = S_IMODE(st[ST_MODE]) if hasattr(os, 'chmod'): os.chmod(dst, mode) # KEEP THIS ONE! #else: pass # we are on Win9x,ME - no chmod here else: shutil.copystat(src, dst) As you see, some special treatment is needed for win32/nt and directories - and directories are exactly the use case used by the fixed copytree, so a fixed copystat is needed or copytree will crash on win32/nt. ---------------------------------------------------------------------- Comment By: Jeff McNeil (j_mcneil) Date: 2007-02-22 17:28 Message: Logged In: YES user_id=1726175 Originator: YES python -V Python 2.4.3 on Linux marvin 2.6.18-1.2257.fc5smp #1 SMP Fri Dec 15 16:33:51 EST 2006 i686 i686 i386 GNU/Linux ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666318&group_id=5470 From noreply at sourceforge.net Sat Mar 24 19:25:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Mar 2007 11:25:11 -0700 Subject: [ python-Bugs-1595164 ] texinfo library documentation fails to build Message-ID: Bugs item #1595164, was opened at 2006-11-12 20:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595164&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Mark Diekhans (diekhans) Assigned to: Nobody/Anonymous (nobody) Summary: texinfo library documentation fails to build Initial Comment: Attempting to build the texinfo documentation generates the error (args-out-of-range 2931944 2931946). This occurs in download of 2.5 latex doc and from trunk of svn tree. elisp stack trace attached. It would be really nice if texinfo doc was still available for download. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-24 19:25 Message: Logged In: YES user_id=21627 Originator: NO There is no need that the documentation builds on Windows, so closing this as fixed. zseil, thanks for looking into it. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-24 17:38 Message: Logged In: YES user_id=1326842 Originator: NO This should be fixed with r52974 and r52975: http://svn.python.org/view?view=rev&rev=52974 I can't test it on Windows, so someone else should close this bug if it is fixed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-30 21:59 Message: Logged In: YES user_id=21627 Originator: NO pekon, it would be quite helpful if you could resolve this. It would be best if you could check out the subversion trunk or release25-maint branch, and then provide a patch that solves it all :-) After applying your (correct) patch, I still get such an error, so I guess there are more problems in the tex source. ---------------------------------------------------------------------- Comment By: Petr Konecny (pekon) Date: 2006-11-30 21:55 Message: Logged In: YES user_id=828085 Originator: NO After changing libmsilib.tex I made some manual fixes in python-lib.texi and was able to get .info files. I am attaching diff, which shows what is broken. --- python-lib.texi 2006-11-30 12:54:04.626177825 -0800 +++ python-lib.texi.fixed 2006-11-30 12:53:28.767367718 -0800 @@ -30395,7 +30395,7 @@ QName wrapper. This can be used to wrap a QName attribute value, in order to get proper namespace handling on output. @var{text_or_uri} is a string containing the QName value, -in the form @{@{}uri{@}@}local, or, if the tag argument is given, +in the form @{uri@}local, or, if the tag argument is given, the URI part of a QName. If @var{tag} is given, the first argument is interpreted as an URI, and this argument is interpreted as a local name. @@ -49305,8 +49305,6 @@ @findex EDQUOT Quota exceeded @end table -\ifx\locallinewidth\undefined\newlength@{\locallinewidth@}@end ifinfo -\setlength@{\locallinewidth@}@{\linewidth@} @node ctypes, , errno, Generic Operating System Services @section A foreign function library for Python. @@ -51073,12 +51071,14 @@ Here is the wrapping with @code{ctypes}: - at example>>> from ctypes import c_int, WINFUNCTYPE, windll + at example +>>> from ctypes import c_int, WINFUNCTYPE, windll >>> from ctypes.wintypes import HWND, LPCSTR, UINT >>> prototype = WINFUNCTYPE(c_int, HWND, LPCSTR, LPCSTR, c_uint) >>> paramflags = (1, "hwnd", 0), (1, "text", "Hi"), (1, "caption", None), (1, "flags", 0) >>> MessageBox = prototype(("MessageBoxA", windll.user32), paramflags) ->>>@end example +>>> + at end example The MessageBox foreign function can now be called in these ways: @example @@ -51101,12 +51101,14 @@ Here is the wrapping with @code{ctypes}: - at example>>> from ctypes import POINTER, WINFUNCTYPE, windll + at example +>>> from ctypes import POINTER, WINFUNCTYPE, windll >>> from ctypes.wintypes import BOOL, HWND, RECT >>> prototype = WINFUNCTYPE(BOOL, HWND, POINTER(RECT)) >>> paramflags = (1, "hwnd"), (2, "lprect") >>> GetWindowRect = prototype(("GetWindowRect", windll.user32), paramflags) ->>>@end example +>>> + at end example Functions with output parameters will automatically return the output parameter value if there is a single one, or a tuple containing the @@ -59352,7 +59354,8 @@ . Example usage: - at examplefrom wsgiref.simple_server import make_server, demo_app + at example +from wsgiref.simple_server import make_server, demo_app httpd = make_server('', 8000, demo_app) print "Serving HTTP on port 8000..." ---------------------------------------------------------------------- Comment By: Petr Konecny (pekon) Date: 2006-11-30 21:42 Message: Logged In: YES user_id=828085 Originator: NO I believe this problem is triggered by a typo in lib/libmsilib.tex:347 \begin{classdesc}{Feature}{database, id, title, desc, display\optional{, level=1\optional{, parent\optional\{, directory\optional{, attributes=0}}}} I think it should look like this: \begin{classdesc}{Feature}{database, id, title, desc, display\optional{, level=1\optional{, parent\optional{, directory\optional{, attributes=0}}}}} With this change I am able to build python-lib.texi. However makeinfo fails: makeinfo --footnote-style end --fill-column 72 --paragraph-indent 0 --output=python-lib.info python-lib.texi python-lib.texi:30398: Unmatched }. python-lib.texi:30398: Misplaced {. python-lib.texi:36389: warning: @strong{Note...} produces a spurious cross-reference in Info; reword to avoid that. python-lib.texi:49309: Unmatched `@end'. python-lib.texi:51076: Unknown command `example>>>'. python-lib.texi:51082: Unmatched `@end'. python-lib.texi:51104: Unknown command `example>>>'. python-lib.texi:51110: Unmatched `@end'. python-lib.texi:59355: Unknown command `examplefrom'. python-lib.texi:59366: `@end' expected `table', but saw `example'. makeinfo: Removing output file `python-lib.info' due to errors; use --force to preserve. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 22:47 Message: Logged In: YES user_id=21627 Can you find out what is causing this error? If not, would you be interested in rewriting this in Python? (AFAICT, there really is no reason that this conversion is written in elisp) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595164&group_id=5470 From noreply at sourceforge.net Sat Mar 24 19:51:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Mar 2007 11:51:11 -0700 Subject: [ python-Bugs-1438480 ] shutil.move raises OSError when copystat fails Message-ID: Bugs item #1438480, was opened at 2006-02-25 06:26 Message generated for change (Comment added) made by thomaswaldmann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1438480&group_id=5470 Please note that this 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 Private: No Submitted By: Joe Wreschnig (piman) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.move raises OSError when copystat fails Initial Comment: If you are on a Linux system, and shutil.move a file from anywhere onto a partition where you have write permission but are not the owner, os.utime will fail with an EPERM OSError. This can (and did) happen moving a file on a vfat partition mounted with umask=0000, so every user had read/write/execute but all files were owned by root. This happens in shutil.copystat, so shutil.move doesn't remove the old file. The resulting error code (OSError, EPERM) is not distinguishable from several other permission errors that can happen during shutil.move, even though a failure to set a utime is not fatal for most move operations (mv(1) succeeds, for example). I would suggest either ignoring an EPERM from copystat, or catching it in shutil.copy2 and raising a more specific exception so that it can be easily distinguished from genuine failure due to permissions. ---------------------------------------------------------------------- Comment By: Thomas Waldmann (thomaswaldmann) Date: 2007-03-24 19:51 Message: Logged In: YES user_id=100649 Originator: NO See also http://sourceforge.net/tracker/index.php?func=detail&aid=1666318&group_id=5470&atid=105470 for a similar problem with copystat. ---------------------------------------------------------------------- Comment By: Joe Wreschnig (piman) Date: 2006-02-26 06:08 Message: Logged In: YES user_id=796 The attached patch causes shutil.copy and shutil.copy2 (and so copytree, and move) to ignore EACCES and EPERM from copymode and copystat respectively. Other errors are reraised with the original traceback. Any error copying the file, rather than the metadata, is still considered fatal. User calls to copymode and copystat still fail as before. Justification: On Linux, utime(2) says the distinction between EACCES and EPERM is blurry and "Linux is not careful to distinguish between the EACCES and EPERM" so the patch ignores both. In my opinion, anyone wanting to deal with low-level details like mtimes and modes is probably not using shutil, so ignoring is better than a new exception (which would just result in complicated new code, and surprise old code). It's also easy for a caller to check if the mode/utimes were copied, if it's important to them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1438480&group_id=5470 From noreply at sourceforge.net Sat Mar 24 20:06:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Mar 2007 12:06:56 -0700 Subject: [ python-Bugs-1145257 ] shutil.copystat() may fail... Message-ID: Bugs item #1145257, was opened at 2005-02-21 10:02 Message generated for change (Comment added) made by thomaswaldmann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1145257&group_id=5470 Please note that this 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 Private: No Submitted By: Petr Prikryl (prikryl) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.copystat() may fail... Initial Comment: Hi, The shutil.copystat() may fail in case when the destination file has read-only attribute. It's because the implementation calls the os.utime() first and os.chmod() later. In Windows (I am not sure if also in Unix-based system), the os.utime() fails for read-only files. The implementation should ensure the read/write access by " try: os.chmod(dst, 0600)..." before calling the os.utime(). The file mode will be copied from the source file in the next step anyway. The simplistic test attached (Unix line ending used inside the tst.py zipped inside). Petr ---------------------------------------------------------------------- Comment By: Thomas Waldmann (thomaswaldmann) Date: 2007-03-24 20:06 Message: Logged In: YES user_id=100649 Originator: NO See http://sourceforge.net/tracker/index.php?func=detail&aid=1666318&group_id=5470&atid=105470 for another problem with utime() on win32/nt with directories. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1145257&group_id=5470 From noreply at sourceforge.net Mon Mar 26 00:10:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Mar 2007 15:10:04 -0700 Subject: [ python-Bugs-1050828 ] reindent.py strips execute permission on Unix Message-ID: Bugs item #1050828, was opened at 2004-10-20 12:48 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1050828&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Ripton (dripton) Assigned to: Facundo Batista (facundobatista) Summary: reindent.py strips execute permission on Unix Initial Comment: Tools/scripts/reindent.py strips execute permission from its target file. If the tool detects that changes need to be made, then the target file is renamed to its original name + '.bak', then a new file is created with the original file's name and its whitespace-modified contents. No manipulation of the new file's permissions is done, so it ends up with the default for the user's umask. This makes reindent.py annoying to run in an automated fashion, if you rely on execute permission. The fix is trivial, except for portability. Here's the Posix-only version: + if os.name == "posix": + mode = os.stat(bak).st_mode + os.chmod(file, mode) Patch available upon request. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2007-03-25 19:10 Message: Logged In: YES user_id=752496 Originator: NO Lot of time passed, I want to finish this. I propose to make the following: - Copy the file to .bak, change the file in place: this preserves the file metadata, actually fixing the bug. It does not solve the security problem, but it does not make things worse (actually, this moves the security issue from the original file to the .bak one). - Add an option -n (--nobackup), to the program not to make the .bak copy, and explicity saying in the docs that this option is useful if you have security concerns. - Not move the functionality to another library: it will be something nice to have, but these security issues will need more thoughts. Anyway, this goes far beyond this bug. What do you think? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-04 23:29 Message: Logged In: YES user_id=31435 That's a good plan, and for another reason too: this shouldn't be confined to reindent.py. There *should* be a standard module/package in the library to handle: 1. Searching a directory subtree for files with names matching a set of patterns, dealing intelligently with symlinks and whatever other OS-specific crud gets in the way. 2. Feeding the files that match to a filter. 3. If the filter decides to replace the file, dealing with making a backup "correctly", whatever that means across OSes. None of that code should be *in* reindent.py to begin with. Filter programs keep reinventing this crud because there's nothing standard to build on. There are many filter programs under the Tools directory. For example, cleanfuture.py is going to become popular soon, as people lose interest in ancient Pythons and want to get rid of their old __future__ statements. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-11-04 22:36 Message: Logged In: YES user_id=752496 I'll just let this bug live, don't want to commit it for 2.4 without bigger consensus. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-10-28 21:49 Message: Logged In: YES user_id=752496 I could touch the permissions of the copy to be only readable, but with os.chmod() it'll be portable only to Windows and Unix (according to the docs). And in Mac? Take note that in this very moment, the copy is created via the open(..., "w") which leaves the copy with the same permissions that with the patch. We're not creating a problem... maybe just don't solving it! ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2004-10-27 14:34 Message: Logged In: YES user_id=43607 Now that I looked at the patch, I have one concern. I don't mind if the backup copy doesn't have the same permissions as the original, especially not if you can't guarantee that the owner/group doesn't change. However, I do mind if the backup copy has *more* permissions than the original. Consider a file that was only readable by the owner (probably for some good reason), and because of a permissive umask, the backup copy all of a sudden is world-readable. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-10-27 13:07 Message: Logged In: YES user_id=752496 That is *exactly* what the patch does, but David complained about the metadata of the copy. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2004-10-27 12:29 Message: Logged In: YES user_id=43607 Then perhaps it should do in-place replacement, so first *copy* the original to the backup, and then overwrite the original. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-10-27 11:56 Message: Logged In: YES user_id=752496 I thought about it. The problem with this approach is that it also copies the permissions, but not the owner/group ids (you get the defaults there). So, I think is better to leave the user defaults than mix the old permissions with new owner/group (which may lead to a security risk in some combinations). There's a better approach: to copy *all* the file metadata. But don't know how to do it in a portable way... ---------------------------------------------------------------------- Comment By: David Ripton (dripton) Date: 2004-10-27 11:47 Message: Logged In: YES user_id=9425 s/wrong/right/ in my last comment. The target is more important than the backup, but we should go for the win/win and give both of them the correct permissions, since it's easy. ---------------------------------------------------------------------- Comment By: David Ripton (dripton) Date: 2004-10-27 11:45 Message: Logged In: YES user_id=9425 The patch is an improvement (better to have the wrong permissions on the target file than on the backup file), but I think it would be even better if the .bak file had the same permissions as the target file. How about using shutil.copy2 (which preserves permissions, among other things) instead of shutil.copy? Thanks. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-10-27 09:38 Message: Logged In: YES user_id=469548 The patch works for me (Linux 2.6.8-1-686 i686 GNU/Linux) and a coworker (Mac OS X 10.3). ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-10-26 21:44 Message: Logged In: YES user_id=752496 This fixes the problem: the original file metadata (permisions, etc) stays unchanged. The issue with the metadata of the bak file is none: the new file has the user defaults permissions, group and owner. In the previous version, the original file left with those defaults permissions, so security is not getting worse. The only left issue is, if the user wants to recover the data from the bak file, he would need to change its metadata (this is minor, if something goes wrong and the bak is needed, it's likely that the user will need a manual approach). My primary concern is that I don't want to commit the changes now that we're beta without testing the changes in other platforms (however, I'll ask this on python-dev). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-10-26 00:19 Message: Logged In: YES user_id=31435 Sorry, I don't normally run on Unix, so I have no way to tell whether this fixes whatever the complaint is. Offhand it doesn't seem right to create a .bak file with default permissions either. For example, if only the user had permission to get at the original, letting the .bak file have broader permissions seems wrong too. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-10-25 23:57 Message: Logged In: YES user_id=752496 Attaching the file. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-10-24 18:20 Message: Logged In: YES user_id=752496 Instead of renaming the file and creating a new one, just copied the original and that's all (the target file is open with write mode, the content replaced, but the permissions stay). A patch is attached. Tim, I'm assigning this to you to doublecheck (not found unit tests for this script). . Facundo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1050828&group_id=5470 From noreply at sourceforge.net Mon Mar 26 13:24:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Mar 2007 04:24:40 -0700 Subject: [ python-Bugs-1688274 ] Python/C PyClass_* are not documented Message-ID: Bugs item #1688274, was opened at 2007-03-26 14: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=1688274&group_id=5470 Please note that this 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 Private: No Submitted By: Tommi Vainikainen (tvainika) Assigned to: Nobody/Anonymous (nobody) Summary: Python/C PyClass_* are not documented Initial Comment: Python/C API Reference Manual chapter 7.5 Other Objects does not contain subchapter for Class objects, but only Instance objects and many other are documented there. >From header I can find that at least PyClass_Check and PyClass_New exist, I just don't know what those do until I take time to read source code... :( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1688274&group_id=5470 From noreply at sourceforge.net Mon Mar 26 14:36:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Mar 2007 05:36:22 -0700 Subject: [ python-Bugs-542314 ] long file name support broken in windows Message-ID: Bugs item #542314, was opened at 2002-04-11 06:23 Message generated for change (Comment added) made by titty You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=542314&group_id=5470 Please note that this 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: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Hammond (mhammond) Assigned to: Nobody/Anonymous (nobody) Summary: long file name support broken in windows Initial Comment: >From c.l.py, thread "" Peter D: I'm using windows and trying to call os.path.getmtime () after using os.path.walk... However, I'm choking with "[Errno 38] Filename too long" on paths with len > ~260 Adding Martin's reply in a new comment (so it is not at the top of each and every mail I get on this bug :) ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2007-03-26 14:36 Message: Logged In: YES user_id=17929 Originator: NO or if the c library is just insane: from http://msdn2.microsoft.com/en-us/library/aa365247.aspx: Maximum Path Length In the Windows API, the maximum length for a path is MAX_PATH, which is defined as 260 characters. A path is structured in the following order: drive letter, colon, backslash, components separated by backslashes, and a null-terminating character, for example, the maximum path on the D drive is D:\<256 chars>NUL. The Unicode versions of several functions permit a maximum path length of approximately 32,000 characters composed of components up to 255 characters in length. To specify that kind of path, use the "\\?\" prefix. Note The maximum path of 32,000 characters is approximate, because the "\\?\" prefix can be expanded to a longer string, and the expansion applies to the total length. For example, "\\?\D:\". To specify such a UNC path, use the "\\?\UNC\" prefix. For example, "\\?\UNC\\". These prefixes are not used as part of the path itself. They indicate that the path should be passed to the system with minimal modification, which means that you cannot use forward slashes to represent path separators, or a period to represent the current directory. Also, you cannot use the "\\?\" prefix with a relative path. Relative paths are limited to MAX_PATH characters. When using the API to create a directory, the specified path cannot be so long that you cannot not append an 8.3 file name. The shell and the file system may have different requirements. It is possible to create a path with the API that the shell UI cannot handle. ----- the explicit checks for pathnames longer than 260 characters seem to be removed in python 2.5 and one can use the "magic prefix" to stat/create files with pathnames longer than 260 characters. ---------------------------------------------------------------------- Comment By: Stuart Norton (stunorton) Date: 2005-03-30 18:54 Message: Logged In: YES user_id=1152606 I came across this suggestion while googling... and I would have expected it to work, but this code: import os os.chdir("\\\\ussvs-file02 \\radpubs\\wip\\zStaging\\translation\\D10 \\previous_test\\cumulative\\Common\\Reference\\API\\Borland .Eco.Persistence.Configuration\\classes\\PersistenceMapper DefinitionCollection\\Methods") for filename in os.listdir("."): print filename infile = file(filename) gives me C:\Documents and Settings\snorton\Desktop\h2build\buildtools>test.py PersistenceMapperDefinitionCollection.AddRange.xml PersistenceMapperDefinitionCollection.Assign.xml PersistenceMapperDefinitionCollection.FindByName.xml PersistenceMapperDefinitionCollection.NameExists.xml PersistenceMapperDefinitionCollection.PersistenceMapperDefi nitionCollection.xml Traceback (most recent call last): File "C:\Documents and Settings\snorton\Desktop\h2build\buildtools\test.py", line 6, in ? infile = file(filename) IOError: [Errno 2] No such file or directory: 'PersistenceMapperDefinitionCollection.Persistence MapperDefinitionCollection.xml' ... funny that the file with the long path comes up in listdir() but isn't found with file()... ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-04-11 06:26 Message: Logged In: YES user_id=14198 Martin v. Loewis's reply on c.l.py: Since you are asking for a work-around: cd into one of the more nested directories when the path gets longer (os.chdir), and use relative paths from then on. If you want to study how to solve the problem: the relevant code snippet is in Modules/posixmodule.c /* the library call can blow up if the file name is too long! */ if (pathlen > MAX_PATH) { PyMem_Free(pathfree); errno = ENAMETOOLONG; return posix_error(); } There might be different ways to approach this: - challenge the correctness of the comment: - try to establish why the author of that code thought that the C library could blow up - analyse whether these arguments are still true with the current compiler version -or- - prove the argument wrong by analysing the source code of the C library - then remove the constraint -or- - use different API to achieve the same effect without suffering from the constraint. I'm serious about these suggestions: users would appreciate if this gets fixed somehow - apparently, the system allows longer file names, and apparently, the system itself can deal with that quite well. This can be only true if the system either doesn't use its C library, or if the C library does not have this restriction. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=542314&group_id=5470 From noreply at sourceforge.net Mon Mar 26 16:13:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Mar 2007 07:13:14 -0700 Subject: [ python-Bugs-1688393 ] sock.recvfrom(-24) crashes Message-ID: Bugs item #1688393, was opened at 2007-03-27 00: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=1688393&group_id=5470 Please note that this 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 Private: No Submitted By: Andrew Bennetts (spiv) Assigned to: Nobody/Anonymous (nobody) Summary: sock.recvfrom(-24) crashes Initial Comment: Actually sock.recvfrom(x) crashes or causes memory corruption for all values in -sizeof(PyStringObject) <= x < 0, I think. This script demonstrates the problem: import socket, sys s1 = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) s1.bind(('127.0.0.1', 9999)) s2 = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) s2.sendto('fdsjkldsfkj', ('127.0.0.1', 9999)) print s1.recvfrom(-24) Try e.g. -1 instead of -24 as well. I'm attaching a patch that fixes this bug, and adds a simple test for it too. Other sock_recv* functions in socketmodule.c seem to already catch negative recvlen values and raise ValueError, but for some reason recvfrom missed out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1688393&group_id=5470 From noreply at sourceforge.net Mon Mar 26 19:12:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Mar 2007 10:12:32 -0700 Subject: [ python-Bugs-1688564 ] os.path.join.__doc__ should mention absolute paths Message-ID: Bugs item #1688564, was opened at 2007-03-26 10:12 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=1688564&group_id=5470 Please note that this 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 Private: No Submitted By: Eugene Kramer (zdes) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.join.__doc__ should mention absolute paths Initial Comment: Currently, automatically generated docs from os.path.join do not mention that all paths prior to the last absolute path are discarded. The __doc__ says: "Join two or more pathname components, inserting '/' as needed" >From this documentation, it is not obvious that os.path.join("abc", "/cde", "fgh") results in "/cde/fgh". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1688564&group_id=5470 From noreply at sourceforge.net Mon Mar 26 22:18:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Mar 2007 13:18:57 -0700 Subject: [ python-Bugs-1687163 ] Inconsistent Exceptions for Readonly Attributes Message-ID: Bugs item #1687163, was opened at 2007-03-23 16:51 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1687163&group_id=5470 Please note that this 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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Collin Winter (collinwinter) Summary: Inconsistent Exceptions for Readonly Attributes Initial Comment: Attempting assignment to a readonly attribute raises an Attribute error for pure Python attributes but raises a TypeError for C readonly attributes. I think the AttributeError is the correct exception. >>> class A(object): ... _x = [] ... ... @property ... def x(self): ... return self._x ... >>> a = A() >>> a.x = None Traceback (most recent call last): a.x = None AttributeError: can't set attribute >>> def f(): ... yield None >>> g = f() >>> g.gi_frame = None Traceback (most recent call last): g.gi_frame = None TypeError: readonly attribute ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-03-26 15:18 Message: Logged In: YES user_id=80475 Originator: YES Collin, would you please apply this to the Py3K code. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2007-03-23 18:52 Message: Logged In: YES user_id=80475 Originator: YES Here's the one line change: Index: Python/structmember.c =================================================================== --- Python/structmember.c (revision 54557) +++ Python/structmember.c (working copy) @@ -160,7 +160,7 @@ if ((l->flags & READONLY) || l->type == T_STRING) { - PyErr_SetString(PyExc_TypeError, "readonly attribute"); + PyErr_SetString(PyExc_AttributeError, "readonly attribute"); Four of the tests will need to be updated: test_csv test_descr test_generators test_os ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2007-03-23 17:16 Message: Logged In: YES user_id=80475 Originator: YES Readonly methods throw an AttributeError, but readonly members (anything defined in PyMemberDef with an RO or READONLY flag) raise a TypeError. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2007-03-23 17:12 Message: Logged In: YES user_id=591932 Originator: NO I think this has something peculiar to frames, for instance: Python 2.5 (r25:51908, Sep 25 2006, 17:50:07) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> f = 'asdf' >>> f.strip = 42 Traceback (most recent call last): File "", line 1, in AttributeError: 'str' object attribute 'strip' is read-only >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1687163&group_id=5470 From noreply at sourceforge.net Tue Mar 27 08:18:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Mar 2007 23:18:49 -0700 Subject: [ python-Bugs-1662529 ] [2.5 regression?] failure to import the ORBit extension Message-ID: Bugs item #1662529, was opened at 2007-02-17 13:38 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1662529&group_id=5470 Please note that this 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: Invalid Priority: 5 Private: No Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: [2.5 regression?] failure to import the ORBit extension Initial Comment: seen with 2.5 SVN 20070216, with an interpreter built with --enable-pydebug, succeeds with a 2.4.4 interpreter built with --enable-pydebug: pyorbit is version 2.14.1. $ python-dbg -c 'import ORBit' [26750 refs] Fatal Python error: ../Objects/tupleobject.c:169 object at 0x8186bdc has negative ref count -1 Aborted (core dumped) (gdb) bt #0 0xb7f89410 in __kernel_vsyscall () #1 0xb7e11df0 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7e13641 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0x081174f8 in Py_FatalError ( msg=0xbfd0ef78 "../Objects/tupleobject.c:169 object at 0x8186bdc has negative ref count -1") at ../Python/pythonrun.c:1555 #4 0x08093305 in _Py_NegativeRefcount (fname=0x816f958 "../Objects/tupleobject.c", lineno=169, op=0x8186bdc) at ../Objects/object.c:193 #5 0x080add27 in tupledealloc (op=0xb7a1bd1c) at ../Objects/tupleobject.c:169 #6 0x080973a6 in _Py_Dealloc (op=0xb7a1bd1c) at ../Objects/object.c:1928 #7 0x0814d037 in func_dealloc (op=0xb7a1d1c4) at ../Objects/funcobject.c:451 #8 0x080973a6 in _Py_Dealloc (op=0xb7a1d1c4) at ../Objects/object.c:1928 #9 0x0808eb99 in dict_dealloc (mp=0xb7a1c494) at ../Objects/dictobject.c:819 #10 0x080973a6 in _Py_Dealloc (op=0xb7a1c494) at ../Objects/object.c:1928 #11 0x0806459e in class_dealloc (op=0xb7a0bdb4) at ../Objects/classobject.c:184 #12 0x080973a6 in _Py_Dealloc (op=0xb7a0bdb4) at ../Objects/object.c:1928 #13 0x080add3b in tupledealloc (op=0xb7a22edc) at ../Objects/tupleobject.c:169 #14 0x080973a6 in _Py_Dealloc (op=0xb7a22edc) at ../Objects/object.c:1928 #15 0x08064540 in class_dealloc (op=0xb7a2446c) at ../Objects/classobject.c:183 #16 0x080973a6 in _Py_Dealloc (op=0xb7a2446c) at ../Objects/object.c:1928 #17 0x080add3b in tupledealloc (op=0xb7a243dc) at ../Objects/tupleobject.c:169 #18 0x080b13fe in subtype_dealloc (self=0xb7a243dc) at ../Objects/typeobject.c:709 #19 0x080973a6 in _Py_Dealloc (op=0xb7a243dc) at ../Objects/object.c:1928 #20 0x0808eb99 in dict_dealloc (mp=0xb7dcf214) at ../Objects/dictobject.c:819 #21 0x080973a6 in _Py_Dealloc (op=0xb7dcf214) at ../Objects/object.c:1928 #22 0x08112acb in PyInterpreterState_Clear (interp=0x81b8020) at ../Python/pystate.c:107 #23 0x081145be in Py_Finalize () at ../Python/pythonrun.c:441 #24 0x08059eb0 in Py_Main (argc=3, argv=0xbfd0f5b4) at ../Modules/main.c:545 #25 0x08058da6 in main (argc=Cannot access memory at address 0x155c ) at ../Modules/python.c:23 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-26 23:18 Message: Logged In: YES user_id=33168 Originator: NO These problems are almost always issues in the third party modules. I'm closing this on the basis that the problem is likely in ORBit. If you have more information that points to the core as the likely cause, please reopen this report. Without more info, we can't help with this problem. Note another problem could be that Python 2.5 does not allow the memory APIs to be mixed as they used to. This could also lead to a problem like this (though I think it often leads to a crash earlier IIRC.) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-09 19:51 Message: Logged In: YES user_id=1344176 Originator: NO The error message and backtrace here don't prove that it's a regression in Python: it could easily be a problem with an extension module. Do you get this error if you compile Python 2.5 without --with-pydebug? Is "ORBit" provided by the project at http://sourceforge.net/projects/orbit-python/ or the one at http://ftp.gnome.org/pub/GNOME/sources/pyorbit/? If the former, the project's SF page says active development stopped in 2004, so there's no way it could support Python 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1662529&group_id=5470 From noreply at sourceforge.net Tue Mar 27 10:25:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Mar 2007 01:25:01 -0700 Subject: [ python-Bugs-1685773 ] tarfile file names under win32 Message-ID: Bugs item #1685773, was opened at 2007-03-22 08:12 Message generated for change (Comment added) made by indi4source You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685773&group_id=5470 Please note that this 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.5 >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: ralf (indi4source) Assigned to: Lars Gust?bel (gustaebel) Summary: tarfile file names under win32 Initial Comment: the tarfile module uses normpath() to store the file name in the archive. Under win32 this results in pathes with backslashes and possible a leading "\". This confuses the unix tar command. I suppose the following commands instead of just normpath(): path = normpath (path) path = path.replace ("\\", "/") path = path.lstrip ("/") ---------------------------------------------------------------------- >Comment By: ralf (indi4source) Date: 2007-03-27 10:25 Message: Logged In: YES user_id=1182990 Originator: YES Sorry, I was using an derived class of TarFile and didn't realize that tarfile has defined its own normpath() function. When using tarfile.normpath() in my class it is working, too. ---------------------------------------------------------------------- Comment By: Gabriel Genellina (gagenellina) Date: 2007-03-23 11:36 Message: Logged In: YES user_id=479790 Originator: NO tarfile already attempts to manage backslashes well, using os.path.normpath(path).replace(os.sep, "/") Can you provide a small script demonstrating the failure? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685773&group_id=5470 From noreply at sourceforge.net Tue Mar 27 13:41:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Mar 2007 04:41:01 -0700 Subject: [ python-Bugs-1495754 ] os.listdir(): inconsistent behavior with trailing spaces Message-ID: Bugs item #1495754, was opened at 2006-05-26 23:28 Message generated for change (Comment added) made by jerrykhan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495754&group_id=5470 Please note that this 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: Closed Resolution: Wont Fix Priority: 5 Private: No Submitted By: Kenneth J. Pronovici (pronovic) Assigned to: Nobody/Anonymous (nobody) Summary: os.listdir(): inconsistent behavior with trailing spaces Initial Comment: I've noticed some inconsistent behavior around os.listdir() and paths that contain trailing spaces on the Windows platform. Take this example code: import os import tempfile tmpdir = tempfile.mkdtemp() newdir = os.path.join(tmpdir, " collect dir ") os.mkdir(newdir) print os.path.exists(newdir) print os.listdir(newdir) If I run this code on Windows 2000 Pro using Python 2.4.2, I get this: True [Errno 3] The system cannot find the path specified: 'c:\\docume~1\\a0clu0~1.bcb\\locals~1 \\temp\\tmpfd7j3t\\ collect dir /*.*' It seems to me that if os.path.exists() tells me that a file or directory exists, that os.listdir() should be able to operate on it. ---------------------------------------------------------------------- Comment By: JerryKhan (jerrykhan) Date: 2007-03-27 13:41 Message: Logged In: YES user_id=867168 Originator: NO I agree with the fact that this inconsistent behaviour is disturbing. I tried it with a simple example "lib ", if it exists, we must be able to browse it. Example: open the idle, import os os.path.exists("lib ") ==> True os.path.listdir('lib ') Traceback (most recent call last): File "", line 1, in -toplevel- os.listdir('lib ') WindowsError: [Errno 3] Le chemin d'acc?s sp?cifi? est introuvable: 'lib /*.*' os.stat('lib ') works ... os.stat(' lib') does not work (that ok to me) I disagree with the argument that since Windows is bugged then Python is bugged too. It should be possible to rightstrip the folder name before asking for the resolution of abspath/the_dir_with_space_at_the_end /*.* Or to deactivate the rightstriping done on the stat builtin function. I imagine that this is located in nt builtin module. I have done it in my own program .. but this should be coded in interfaces modules. Jerrykhan ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-29 22:59 Message: Logged In: YES user_id=849994 Since Python only calls the underlying Win32 function FindFirstFile, I think there can nothing be done since that function seems to be buggy in this respect. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495754&group_id=5470 From noreply at sourceforge.net Tue Mar 27 18:19:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Mar 2007 09:19:51 -0700 Subject: [ python-Bugs-1668596 ] distutils chops the first character of filenames Message-ID: Bugs item #1668596, was opened at 2007-02-25 17:15 Message generated for change (Comment added) made by draghuram You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668596&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sam Pointon (freecondiments) Assigned to: Nobody/Anonymous (nobody) Summary: distutils chops the first character of filenames Initial Comment: Python 2.5c1, Windows XP SP2. distutils chops the first character from some filenames if the package_data key is ''. Minimal example: The setup.py attached, and a directory named 'doc' in the same directory as setup.py with files in it. Running "python setup.py bdist" triggers the error. On my box, this fails with: running bdist running bdist_dumb running build running build_py error: can't copy 'oc\architecture.rst': doesn't exist or not a regular file http://mail.python.org/pipermail/distutils-sig/2005-April/004453.html describes the same problem, and http://mail.python.org/pipermail/distutils-sig/2005-April/004458.html has a commentary on the code in distutils/commands/build_py.py which causes the error. On lines 117-122, it tries to chop the directory path from the files it has found, using len() and slicing. This job is better done by os.path.split (and is probably more portable, too). ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-03-27 12:19 Message: Logged In: YES user_id=984087 Originator: NO Hi, I reproduced the problem with the latest build on linux. The "fix" may be trivial but I am not entirely sure if there is a problem in the first place. The distutils document does not mention about having null value for package_dir as is the case in your setup.py. I may be missing something here but can you please explain the conclusion that "" is a perfectly valid value for package_dir (as mentioned in one of the threads in mailing list)? I am assuming that you mean "distribution root" directory by "". If this is found to be valid usage, the document should be updated along with the code fix. Otherwise, a check can be put in to disallow null values. Raghu. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668596&group_id=5470 From noreply at sourceforge.net Tue Mar 27 23:07:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Mar 2007 14:07:12 -0700 Subject: [ python-Bugs-1689458 ] pdb unable to jump to first statement Message-ID: Bugs item #1689458, was opened at 2007-03-27 16:07 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=1689458&group_id=5470 Please note that this 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 Private: No Submitted By: gotgenes (gotgenes) Assigned to: Nobody/Anonymous (nobody) Summary: pdb unable to jump to first statement Initial Comment: The Python debugger is unable to "jump" back to the first executable statement in a frame once that statement has been executed. For example: chris at feathers:~/development/playground$ python -m pdb simple.py > /home/chris/development/playground/simple.py(3)?() -> a = 1 (Pdb) next > /home/chris/development/playground/simple.py(4)?() -> b = 2 (Pdb) jump 3 > /home/chris/development/playground/simple.py(3)?() -> a = 1 (Pdb) list 1 #!/usr/bin/env python 2 3 a = 1 4 -> b = 2 5 6 c = a + b 7 8 print c [EOF] (Pdb) next > /home/chris/development/playground/simple.py(6)?() -> c = a + b One can see that after supposedly "jump"ing to line 3 at the second command, when "list"ing the line, the debugger is actually at line 4. The "next" command further demonstrates this since it re-executes line 4 and moves to line 6. This issue was raised on comp.lang.python. (For example, see or if that link is munged, refer to Duncan Booth offers the following: [quote] I verified (with a print statement in pdb) that assigning to self.curframe.f_lineno sets self.curframe.f_lineno and sel.curframe.f_lasti incorrectly ... The problem looks to be in frameobject.c: addr = 0; line = f->f_code->co_firstlineno; new_lasti = -1; for (offset = 0; offset < lnotab_len; offset += 2) { addr += lnotab[offset]; line += lnotab[offset+1]; if (line >= new_lineno) { new_lasti = addr; new_lineno = line; break; } } The first bytes in lnotab are the length and line increment for line 3 (i.e. 6, 1). If line==f->f_code->co_firstlineno it should set new_lasti=0, new_lineno=line but the loop still executes once which increments new_lasti and new_lineno to the next line (6, 4). [/quote] And Rocky Bernstein offers the following: [quote] Best as I can tell, it looks like a bug in Python. pdb, pydb, rpdb2 all handle the "jump" command by changing the frame f_lineno value. When the corresponding code pointer has offset 0 (or equivalently and more simlply as you put it, is the first statement) this doesn't seem to work properly. [/quote] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689458&group_id=5470 From noreply at sourceforge.net Wed Mar 28 03:06:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Mar 2007 18:06:42 -0700 Subject: [ python-Bugs-1290505 ] strptime(): can't switch locales more than once Message-ID: Bugs item #1290505, was opened at 2005-09-14 00:50 Message generated for change (Comment added) made by kovan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470 Please note that this 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: Fixed Priority: 5 Private: No Submitted By: Adam Monsen (meonkeys) Assigned to: Brett Cannon (bcannon) Summary: strptime(): can't switch locales more than once Initial Comment: After calling strptime() once, it appears that subsequent efforts to modify the locale settings (so dates strings in different locales can be parsed) throw a ValueError. I'm pasting everything here since spacing is irrelevant: import locale, time print locale.getdefaultlocale() # ('en_US', 'utf') print locale.getlocale(locale.LC_TIME) # (None, None) # save old locale old_loc = locale.getlocale(locale.LC_TIME) locale.setlocale(locale.LC_TIME, 'nl_NL') print locale.getlocale(locale.LC_TIME) # ('nl_NL', 'ISO8859-1') # parse local date date = '10 augustus 2005 om 17:26' format = '%d %B %Y om %H:%M' dateTuple = time.strptime(date, format) # switch back to previous locale locale.setlocale(locale.LC_TIME, old_loc) print locale.getlocale(locale.LC_TIME) # (None, None) date = '10 August 2005 at 17:26' format = '%d %B %Y at %H:%M' dateTuple = time.strptime(date, format) The output I get from this script is: ('en_US', 'utf') (None, None) ('nl_NL', 'ISO8859-1') (None, None) Traceback (most recent call last): File "switching.py", line 17, in ? dateTuple = time.strptime(date, format) File "/usr/lib/python2.4/_strptime.py", line 292, in strptime raise ValueError("time data did not match format: data=%s fmt=%s" % ValueError: time data did not match format: data=10 August 2005 at 17:26 fmt=%d %B %Y at %H:%M One workaround I found is by manually busting the regular expression cache in _strptime: import _strptime _strptime._cache_lock.acquire() _strptime._TimeRE_cache = _strptime.TimeRE() _strptime._regex_cache = {} _strptime._cache_lock.release() If I do all that, I can change the LC_TIME part of the locale as many times as I choose. If this isn't a bug, this should at least be in the documentation for the locale module and/or strptime(). ---------------------------------------------------------------------- Comment By: kovan (kovan) Date: 2007-03-28 03:06 Message: Logged In: YES user_id=1426755 Originator: NO I think I'm having this issue with Python 2.5, as I can only make strptime take into account locale.setlocale() calls if I clear strptime's internal regexp cache between the calls to setlocal() and strptime(). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-09-15 04:42 Message: Logged In: YES user_id=357491 OK, the problem was that the cache for the locale information in terms of dates and time was being invalidated and recreated, but the regex cache was not being touched. I has now been fixed in rev. 1.41 for 2.5 and in rev. 1.38.2.3 for 2.4 . Thanks for reporting this, Adam. ---------------------------------------------------------------------- Comment By: Adam Monsen (meonkeys) Date: 2005-09-14 00:57 Message: Logged In: YES user_id=259388 I think there were some long lines in my code. Attaching test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470 From noreply at sourceforge.net Wed Mar 28 04:35:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Mar 2007 19:35:11 -0700 Subject: [ python-Bugs-1290505 ] strptime(): can't switch locales more than once Message-ID: Bugs item #1290505, was opened at 2005-09-13 15:50 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470 Please note that this 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: Fixed Priority: 5 Private: No Submitted By: Adam Monsen (meonkeys) Assigned to: Brett Cannon (bcannon) Summary: strptime(): can't switch locales more than once Initial Comment: After calling strptime() once, it appears that subsequent efforts to modify the locale settings (so dates strings in different locales can be parsed) throw a ValueError. I'm pasting everything here since spacing is irrelevant: import locale, time print locale.getdefaultlocale() # ('en_US', 'utf') print locale.getlocale(locale.LC_TIME) # (None, None) # save old locale old_loc = locale.getlocale(locale.LC_TIME) locale.setlocale(locale.LC_TIME, 'nl_NL') print locale.getlocale(locale.LC_TIME) # ('nl_NL', 'ISO8859-1') # parse local date date = '10 augustus 2005 om 17:26' format = '%d %B %Y om %H:%M' dateTuple = time.strptime(date, format) # switch back to previous locale locale.setlocale(locale.LC_TIME, old_loc) print locale.getlocale(locale.LC_TIME) # (None, None) date = '10 August 2005 at 17:26' format = '%d %B %Y at %H:%M' dateTuple = time.strptime(date, format) The output I get from this script is: ('en_US', 'utf') (None, None) ('nl_NL', 'ISO8859-1') (None, None) Traceback (most recent call last): File "switching.py", line 17, in ? dateTuple = time.strptime(date, format) File "/usr/lib/python2.4/_strptime.py", line 292, in strptime raise ValueError("time data did not match format: data=%s fmt=%s" % ValueError: time data did not match format: data=10 August 2005 at 17:26 fmt=%d %B %Y at %H:%M One workaround I found is by manually busting the regular expression cache in _strptime: import _strptime _strptime._cache_lock.acquire() _strptime._TimeRE_cache = _strptime.TimeRE() _strptime._regex_cache = {} _strptime._cache_lock.release() If I do all that, I can change the LC_TIME part of the locale as many times as I choose. If this isn't a bug, this should at least be in the documentation for the locale module and/or strptime(). ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2007-03-27 19:35 Message: Logged In: YES user_id=357491 Originator: NO Can you show some code that recreatess the problem? ---------------------------------------------------------------------- Comment By: kovan (kovan) Date: 2007-03-27 18:06 Message: Logged In: YES user_id=1426755 Originator: NO I think I'm having this issue with Python 2.5, as I can only make strptime take into account locale.setlocale() calls if I clear strptime's internal regexp cache between the calls to setlocal() and strptime(). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-09-14 19:42 Message: Logged In: YES user_id=357491 OK, the problem was that the cache for the locale information in terms of dates and time was being invalidated and recreated, but the regex cache was not being touched. I has now been fixed in rev. 1.41 for 2.5 and in rev. 1.38.2.3 for 2.4 . Thanks for reporting this, Adam. ---------------------------------------------------------------------- Comment By: Adam Monsen (meonkeys) Date: 2005-09-13 15:57 Message: Logged In: YES user_id=259388 I think there were some long lines in my code. Attaching test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470 From noreply at sourceforge.net Wed Mar 28 04:36:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Mar 2007 19:36:22 -0700 Subject: [ python-Bugs-471432 ] __cdecl / __stdcall unspecified in *.h Message-ID: Bugs item #471432, was opened at 2001-10-15 12:18 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=471432&group_id=5470 Please note that this 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: Platform-specific >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Frederic Giacometti (giacometti) Assigned to: Mark Hammond (mhammond) Summary: __cdecl / __stdcall unspecified in *.h Initial Comment: Currently, the win32 function call convention (__stdcall vs __cdecl) is never specified in the function prototypes contained in the .h header files. The call convention is therefore left up to the configuration of the compiler incluing the header files (__cdecl by default on VC++). However, there are situations in which the compiler default call convention must be set to __stdcall (/Gz option on VC++'s cl.exe), and this makes the link fail; until __cdecl keywords are manually insterted in the Python.h function prototypes required for linking. [For instance, /Gz is required when using typedef definitions on function pointers, later passed as arguments on __stdcall functions (the default on Microsoft/commercial libraries)]. Besides, Microsoft recommands, it the VC++ documentation, that the __stdcall convention be used by default for function with fixed numbers of arguments (smaller code size and better performances); __cdecl being limited for use with functions with variable number of args ('...'). A solution would consist in defining: #ifdef _MS_VER #define FIXARGCALL __stdcall #define VARARGCALL __cdecl #else ... #endif and sticking FIXARGCALL / VARARGCALL in front of all DLL_IMPORT(), macro calls associated to a an exported function prototype, across all Python .h files. Frederic Giacometti ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2007-03-27 19:36 Message: Logged In: YES user_id=357491 Originator: NO No one has cared for a week, so closing as out of date. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-03-20 15:05 Message: Logged In: YES user_id=357491 Originator: NO This is a rather old bug. =) If no one cares to fix this then it should be closed. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-10-16 10:19 Message: Logged In: YES user_id=93657 The fault is not in the other libraries. In MS Windows, 'well-behaved' libraries define explicitely the calling conventions for each function in their header file. This is all. There's nobody's guts loosely hanging out in this ;). FG ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-15 20:00 Message: Logged In: YES user_id=31435 I guess my first question is, if library X needs something other than the default, why isn't it X's responsibility to force *their* non-default behavior where needed? After all, they're the oddballs. Some days I get real tired of cleaing up after everyone else's loose bowels <0.9 wink>. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2001-10-15 18:45 Message: Logged In: YES user_id=14198 This does make sense to me, and I have even been bitten by it. There are some strange libraries out there that need to be compiled with a different calling convention than the default. Trying to extend Python with such a library can be difficult. Having the calling convention specified in the prototypes would solve the problem. I have never been brave enough to do it, given the small number of times it has been reported as a problem. However, I would be happy to help come up with a reasonable scheme. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-10-15 12:46 Message: Logged In: YES user_id=93657 As far as MS Windows / dll stuff is concerned, you're already swimming in non-C-ANSI fishtank anyway (e.g. DLL_IMPORT() macros...). Just try to keep the right fishes in the tank :)) FG ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-15 12:34 Message: Logged In: YES user_id=31435 Mark, does this make sense to you? Any notion that we *have* to add non-standard decorations seems inherently fishy to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=471432&group_id=5470 From noreply at sourceforge.net Wed Mar 28 05:46:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Mar 2007 20:46:51 -0700 Subject: [ python-Bugs-1688393 ] sock.recvfrom(-24) crashes Message-ID: Bugs item #1688393, was opened at 2007-03-26 11:13 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1688393&group_id=5470 Please note that this 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 Private: No Submitted By: Andrew Bennetts (spiv) >Assigned to: Facundo Batista (facundobatista) Summary: sock.recvfrom(-24) crashes Initial Comment: Actually sock.recvfrom(x) crashes or causes memory corruption for all values in -sizeof(PyStringObject) <= x < 0, I think. This script demonstrates the problem: import socket, sys s1 = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) s1.bind(('127.0.0.1', 9999)) s2 = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) s2.sendto('fdsjkldsfkj', ('127.0.0.1', 9999)) print s1.recvfrom(-24) Try e.g. -1 instead of -24 as well. I'm attaching a patch that fixes this bug, and adds a simple test for it too. Other sock_recv* functions in socketmodule.c seem to already catch negative recvlen values and raise ValueError, but for some reason recvfrom missed out. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2007-03-28 00:46 Message: Logged In: YES user_id=752496 Originator: NO Applied this to the trunk, let's see if we should backport it to 2.5.x before close this bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1688393&group_id=5470 From noreply at sourceforge.net Wed Mar 28 06:26:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Mar 2007 21:26:05 -0700 Subject: [ python-Bugs-1689617 ] Intel icc build fails with optimizations -O2 Message-ID: Bugs item #1689617, was opened at 2007-03-28 04: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=1689617&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michael Forbes (mforbes) Assigned to: Nobody/Anonymous (nobody) Summary: Intel icc build fails with optimizations -O2 Initial Comment: When building python 2.5 with the free Intel compilers for non-commercial use (icc), the build works without optimizations, but fails when optimizations -O2 and -O3 are used. The compilation proceedes without errors (though there are lot's of warnings and remarks) and makes a python executable, but when the python setup starts, the intepreter cannot import certain packages and cannot add two strings. case $MAKEFLAGS in \ *-s*) CC='icc -pthread' LDSHARED='icc -pthread -shared' OPT='-DNDEBUG -g -O2 -Ob2 -w1' ./python -E ./setup.py -q build;; \ *) CC='icc -pthread' LDSHARED='icc -pthread -shared' OPT='-DNDEBUG -g -O2 -Ob2 -w1' ./python -E ./setup.py build;; \ esac 'import site' failed; use -v for traceback Traceback (most recent call last): File "./setup.py", line 6, in import sys, os, imp, re, optparse File "/int/apps/mmf/src/Python-2.5_intel/Lib/optparse.py", line 71, in import textwrap File "/int/apps/mmf/src/Python-2.5_intel/Lib/textwrap.py", line 10, in import string, re File "/int/apps/mmf/src/Python-2.5_intel/Lib/string.py", line 26, in letters = lowercase + uppercase SystemError: error return without exception set make: *** [sharedmods] Error 1 For example: $ ./python 'import site' failed; use -v for traceback Python 2.5 (r25:51908, Mar 27 2007, 20:10:22) [GCC Intel(R) C++ gcc 3.4 mode] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a = "123" >>> a + "12" Traceback (most recent call last): File "", line 1, in SystemError: error return without exception set >>> Note that both the import of the site file fails and the addition fails. Python was configured with the following options: ./configure --with-gcc=icc\ --with-cxx-main=icc\ --prefix=/int/apps/mmf/apps/Python-2.5_intel/\ OPT="-g -O2 -Ob2 -w1" ---------------------------- When compiled with fewer optimiztions, everything seems to work. ./configure --with-gcc=icc\ --with-cxx-main=icc\ --prefix=/int/apps/mmf/apps/Python-2.5_intel/\ OPT="-g -O1 -Ob2 -w1" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689617&group_id=5470 From noreply at sourceforge.net Wed Mar 28 09:06:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 00:06:37 -0700 Subject: [ python-Bugs-1290505 ] strptime(): can't switch locales more than once Message-ID: Bugs item #1290505, was opened at 2005-09-14 00:50 Message generated for change (Comment added) made by kovan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470 Please note that this 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: Fixed Priority: 5 Private: No Submitted By: Adam Monsen (meonkeys) Assigned to: Brett Cannon (bcannon) Summary: strptime(): can't switch locales more than once Initial Comment: After calling strptime() once, it appears that subsequent efforts to modify the locale settings (so dates strings in different locales can be parsed) throw a ValueError. I'm pasting everything here since spacing is irrelevant: import locale, time print locale.getdefaultlocale() # ('en_US', 'utf') print locale.getlocale(locale.LC_TIME) # (None, None) # save old locale old_loc = locale.getlocale(locale.LC_TIME) locale.setlocale(locale.LC_TIME, 'nl_NL') print locale.getlocale(locale.LC_TIME) # ('nl_NL', 'ISO8859-1') # parse local date date = '10 augustus 2005 om 17:26' format = '%d %B %Y om %H:%M' dateTuple = time.strptime(date, format) # switch back to previous locale locale.setlocale(locale.LC_TIME, old_loc) print locale.getlocale(locale.LC_TIME) # (None, None) date = '10 August 2005 at 17:26' format = '%d %B %Y at %H:%M' dateTuple = time.strptime(date, format) The output I get from this script is: ('en_US', 'utf') (None, None) ('nl_NL', 'ISO8859-1') (None, None) Traceback (most recent call last): File "switching.py", line 17, in ? dateTuple = time.strptime(date, format) File "/usr/lib/python2.4/_strptime.py", line 292, in strptime raise ValueError("time data did not match format: data=%s fmt=%s" % ValueError: time data did not match format: data=10 August 2005 at 17:26 fmt=%d %B %Y at %H:%M One workaround I found is by manually busting the regular expression cache in _strptime: import _strptime _strptime._cache_lock.acquire() _strptime._TimeRE_cache = _strptime.TimeRE() _strptime._regex_cache = {} _strptime._cache_lock.release() If I do all that, I can change the LC_TIME part of the locale as many times as I choose. If this isn't a bug, this should at least be in the documentation for the locale module and/or strptime(). ---------------------------------------------------------------------- Comment By: kovan (kovan) Date: 2007-03-28 09:06 Message: Logged In: YES user_id=1426755 Originator: NO This is the code: def parseTime(strTime, format = "%a %b %d %H:%M:%S"):# example: Mon Aug 7 21:08:52 locale.setlocale(locale.LC_TIME, ('en_US','UTF8')) format = "%Y " + format strTime = str(datetime.now().year) + " " +strTime import _strptime _strptime._cache_lock.acquire() _strptime._TimeRE_cache = _strptime.TimeRE() _strptime._regex_cache = {} _strptime._cache_lock.release() tuple = strptime(strTime, format) return datetime(*tuple[0:6]) If I remove the code to clear the cache and add "print format_regex.pattern" statement to _strptime.py after "format_regex = time_re.compile(format)", I get (?P\d\d\d\d)\s*(?Pmi\???\???|s\???\???b|lun|mar|jue|vie|dom)\s*(?Pene|feb|mar|abr|may|jun|jul|ago|sep|oct|nov|dic)\s*(?P3[0-1]|[1-2]\d|0[1-9]|[1-9]| [1-9])\s*(?P2[0-3]|[0-1]\d|\d):(?P[0-5]\d|\d):(?P6[0-1]|[0-5]\d|\d) which is in my system's locale (es), and it should be in english. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-03-28 04:35 Message: Logged In: YES user_id=357491 Originator: NO Can you show some code that recreatess the problem? ---------------------------------------------------------------------- Comment By: kovan (kovan) Date: 2007-03-28 03:06 Message: Logged In: YES user_id=1426755 Originator: NO I think I'm having this issue with Python 2.5, as I can only make strptime take into account locale.setlocale() calls if I clear strptime's internal regexp cache between the calls to setlocal() and strptime(). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-09-15 04:42 Message: Logged In: YES user_id=357491 OK, the problem was that the cache for the locale information in terms of dates and time was being invalidated and recreated, but the regex cache was not being touched. I has now been fixed in rev. 1.41 for 2.5 and in rev. 1.38.2.3 for 2.4 . Thanks for reporting this, Adam. ---------------------------------------------------------------------- Comment By: Adam Monsen (meonkeys) Date: 2005-09-14 00:57 Message: Logged In: YES user_id=259388 I think there were some long lines in my code. Attaching test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470 From noreply at sourceforge.net Wed Mar 28 13:12:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 04:12:00 -0700 Subject: [ python-Bugs-1109602 ] Need some setup.py sanity Message-ID: Bugs item #1109602, was opened at 2005-01-26 04:28 Message generated for change (Comment added) made by mforbes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1109602&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Need some setup.py sanity Initial Comment: Python's setup.py has grown way out of control. I'm trying to build and install Python 2.4.0 on a Solaris system with Tcl/Tk installed in a non-standard place and I can't figure out the incantation to tell setup.py to look where they are installed. I have tried: * setting LDFLAGS and CPPFLAGS on the make and configure command lines * running "setup.py --help" and "setup.py build --help" * reading the setup.py source It's not at all obvious to me from any of this if there is any way to point setup.py at a non-standard place. Over time setup.py has grown into the Python equivalent of a configure script, but there's been precious little refactoring, so there is stuff all over the place to add this directory on that platform or try different ad hoc solutions for various external packages based upon common installation practices. I think it's time to rethink the function and organization of setup.py. This might be an excellent sprint topic for PyCon. ---------------------------------------------------------------------- Comment By: Michael Forbes (mforbes) Date: 2007-03-28 11:12 Message: Logged In: YES user_id=253921 Originator: NO Something like this works with Python 2.5 ./configure LDFLAGS="-L/myplace/tcl8.4.14_gcc/lib/"\ CPPFLAGS="-I/myplace/tcl8.4.14_gcc/include/" (Both tcl and tk librarys and headers are installed in these directories.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1109602&group_id=5470 From noreply at sourceforge.net Wed Mar 28 13:32:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 04:32:39 -0700 Subject: [ python-Bugs-1689617 ] Intel icc build fails with optimizations -O2 Message-ID: Bugs item #1689617, was opened at 2007-03-28 06:26 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689617&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michael Forbes (mforbes) Assigned to: Nobody/Anonymous (nobody) Summary: Intel icc build fails with optimizations -O2 Initial Comment: When building python 2.5 with the free Intel compilers for non-commercial use (icc), the build works without optimizations, but fails when optimizations -O2 and -O3 are used. The compilation proceedes without errors (though there are lot's of warnings and remarks) and makes a python executable, but when the python setup starts, the intepreter cannot import certain packages and cannot add two strings. case $MAKEFLAGS in \ *-s*) CC='icc -pthread' LDSHARED='icc -pthread -shared' OPT='-DNDEBUG -g -O2 -Ob2 -w1' ./python -E ./setup.py -q build;; \ *) CC='icc -pthread' LDSHARED='icc -pthread -shared' OPT='-DNDEBUG -g -O2 -Ob2 -w1' ./python -E ./setup.py build;; \ esac 'import site' failed; use -v for traceback Traceback (most recent call last): File "./setup.py", line 6, in import sys, os, imp, re, optparse File "/int/apps/mmf/src/Python-2.5_intel/Lib/optparse.py", line 71, in import textwrap File "/int/apps/mmf/src/Python-2.5_intel/Lib/textwrap.py", line 10, in import string, re File "/int/apps/mmf/src/Python-2.5_intel/Lib/string.py", line 26, in letters = lowercase + uppercase SystemError: error return without exception set make: *** [sharedmods] Error 1 For example: $ ./python 'import site' failed; use -v for traceback Python 2.5 (r25:51908, Mar 27 2007, 20:10:22) [GCC Intel(R) C++ gcc 3.4 mode] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a = "123" >>> a + "12" Traceback (most recent call last): File "", line 1, in SystemError: error return without exception set >>> Note that both the import of the site file fails and the addition fails. Python was configured with the following options: ./configure --with-gcc=icc\ --with-cxx-main=icc\ --prefix=/int/apps/mmf/apps/Python-2.5_intel/\ OPT="-g -O2 -Ob2 -w1" ---------------------------- When compiled with fewer optimiztions, everything seems to work. ./configure --with-gcc=icc\ --with-cxx-main=icc\ --prefix=/int/apps/mmf/apps/Python-2.5_intel/\ OPT="-g -O1 -Ob2 -w1" ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-28 13:32 Message: Logged In: YES user_id=21627 Originator: NO Can you debug this further to determine a specific problem? It could be a compiler bug also, for all I can tell. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689617&group_id=5470 From noreply at sourceforge.net Wed Mar 28 13:35:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 04:35:55 -0700 Subject: [ python-Bugs-1685775 ] msvccompiler.py doesn't recongnize VS2005 Message-ID: Bugs item #1685775, was opened at 2007-03-22 08:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685775&group_id=5470 Please note that this 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.5 >Status: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: Minmin Gong (gongminmin) Assigned to: Nobody/Anonymous (nobody) Summary: msvccompiler.py doesn't recongnize VS2005 Initial Comment: I'm trying to compile some python extensions by VS2005. However, it seems that msvccompiler.py doesn't recongnize VS2005. Only VC6/VS2003 is supported. When will distutils fix this? ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-28 13:35 Message: Logged In: YES user_id=21627 Originator: NO You should not be using VS2005 to build Python extensions, unless you know exactly what you are doing. If you do, you should set DISTUTILS_USE_SDK and MSSdk. Closing as 'works for me'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685775&group_id=5470 From noreply at sourceforge.net Wed Mar 28 13:54:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 04:54:36 -0700 Subject: [ python-Bugs-894599 ] Win32 installer should add python's directory to system path Message-ID: Bugs item #894599, was opened at 2004-02-10 20:17 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=894599&group_id=5470 Please note that this 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: Platform-specific >Status: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: Win32 installer should add python's directory to system path Initial Comment: Win32 installer should add python's base directory to the system path to allow executing Python.exe anywhere. If you use an editor like SciTE a hotkey (F5) will start your script with a command line like: pythonw.exe your_script.py The system path must be set correctly to allow this command. This setting must be done on each machine with python installed. In a while classroom with 30 machines it can be very cumbersome. An installation option would be useful in most cases, especially with "yes" default. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-28 13:54 Message: Logged In: YES user_id=21627 Originator: NO complex, can you confirm that the problem is fixed? The script should be started with simply "your_script.py", which, in turn, should invoke the shell's mechanisms to find Python by extension. Prefixing with pythonw.exe should not be necessary. ---------------------------------------------------------------------- Comment By: Kent Johnson (kjohnson) Date: 2005-10-20 17:53 Message: Logged In: YES user_id=49695 IIRC this worked in Python 2.3 and was broken in 2.4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=894599&group_id=5470 From noreply at sourceforge.net Wed Mar 28 14:01:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 05:01:49 -0700 Subject: [ python-Bugs-1180193 ] broken pyc files Message-ID: Bugs item #1180193, was opened at 2005-04-10 15:10 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180193&group_id=5470 Please note that this 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 Private: No Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: broken pyc files Initial Comment: In a number of situations, the .pyc files can become "corrupted" in a subtle way: the co_filename attribute of the code objects it contains become wrong. This can occur if we move or rename directories, or if we access the same set of files from two different locations (e.g. over NFS). This corruption doesn't prevent the .pyc files from working, but the interpreter looses the reference to the source file. It causes trouble in tracebacks, in the inspect module, etc. A simple fix would be to use the following logic when importing a .py file: if there is a corresponding .pyc file, in addition to checking the timestamp, check the co_filename attribute of the loaded object. If it doesn't point to the original .py file, discard the code object and ignore the .pyc file. Alternatively, we could force all co_filenames to point to the .py file when loading the .pyc file. I'll write a patch for whichever alternative seems better. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-28 14:01 Message: Logged In: YES user_id=21627 Originator: NO I fail to see the corruption. It is quite desirable and normal to only ship pyc files - that the file name they refer to is actually present is not a requirement at all. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180193&group_id=5470 From noreply at sourceforge.net Wed Mar 28 15:40:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 06:40:09 -0700 Subject: [ python-Bugs-1180193 ] broken pyc files Message-ID: Bugs item #1180193, was opened at 2005-04-10 13:10 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180193&group_id=5470 Please note that this 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 Private: No Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: broken pyc files Initial Comment: In a number of situations, the .pyc files can become "corrupted" in a subtle way: the co_filename attribute of the code objects it contains become wrong. This can occur if we move or rename directories, or if we access the same set of files from two different locations (e.g. over NFS). This corruption doesn't prevent the .pyc files from working, but the interpreter looses the reference to the source file. It causes trouble in tracebacks, in the inspect module, etc. A simple fix would be to use the following logic when importing a .py file: if there is a corresponding .pyc file, in addition to checking the timestamp, check the co_filename attribute of the loaded object. If it doesn't point to the original .py file, discard the code object and ignore the .pyc file. Alternatively, we could force all co_filenames to point to the .py file when loading the .pyc file. I'll write a patch for whichever alternative seems better. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2007-03-28 13:40 Message: Logged In: YES user_id=4771 Originator: YES What I called "corruption" is the situation where both the .py and the .pyc files are present, but the filename stored in the .pyc co_filenames is no longer the valid absolute path of the corresponding .py file, for any reason (renaming, NFS views, etc.). This situation causes the tracebacks and the inspect module to fail to locate the .py file, which I consider a bug. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-28 12:01 Message: Logged In: YES user_id=21627 Originator: NO I fail to see the corruption. It is quite desirable and normal to only ship pyc files - that the file name they refer to is actually present is not a requirement at all. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180193&group_id=5470 From noreply at sourceforge.net Wed Mar 28 16:43:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 07:43:56 -0700 Subject: [ python-Bugs-1615275 ] tempile.TemporaryFile differences between linux and windows Message-ID: Bugs item #1615275, was opened at 2006-12-13 16:20 Message generated for change (Comment added) made by draghuram You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1615275&group_id=5470 Please note that this 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: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: hirzel (hirzel) Assigned to: Nobody/Anonymous (nobody) Summary: tempile.TemporaryFile differences between linux and windows Initial Comment: This bug came up when trying to write a numpy array to a tempfile.TemporaryFile() using the numpy 'tofile' method on windows using python 2.4. with a numpy array 'a', and a TemporaryFile 'f', on windows: >>> a.tofile(f) throws an IOError, where on Linux it does not. On windows, you must use a.tofile(f.file) The cause of this difference is that in windows, tempfile.TemporaryFile() returns that has a 'file' attribute of , whereas in linux tempfile.TemporaryFile() returns and there is no 'file' attribute. Ideally, the windows version would align with linux, and the module documentation and TemporaryFile() would return a . If this is not possible, it seems like the linux version and docs should be changed to match the windows version to align cross-platform behavior. At least, that seems to be the shared opinion of this thread from the mailing list: numpy-discussion. http://www.mail-archive.com/numpy-discussion at scipy.org/msg00271.html To my knowledge, while platform differences in tempfile have been reported in the past, this one has not. ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-03-28 10:43 Message: Logged In: YES user_id=984087 Originator: NO I used the following code to reproduce the problem on windows XP. ---------- import array import tempfile testarray = array.array('B') testarray.fromstring("\x00\x00\x00") f = tempfile.TemporaryFile() testarray.tofile(f) ----------- This works fine on linux but on windows, it gives the following error: ------------- Traceback (most recent call last): File "c:\rags\tofile.py", line 7, in testarray.tofile(f) TypeError: arg must be open file ------------- Changing "f" to "f.file" seems to work, though, as explained in the initial post. So this may be the same problem as OP reported even though I am getting TypeError and he mentioned IOError. I tested with 2.4 and 2.5 as I don't know how to set up python development environment on windows (yet). I will see if I can set that up first before working on the "fix". Raghu. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1615275&group_id=5470 From noreply at sourceforge.net Wed Mar 28 17:07:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 08:07:43 -0700 Subject: [ python-Bugs-1508864 ] threading.Timer/timeouts break on change of win32 local time Message-ID: Bugs item #1508864, was opened at 2006-06-19 19:53 Message generated for change (Comment added) made by jtate You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508864&group_id=5470 Please note that this 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 Private: No Submitted By: Russell Warren (qopit) Assigned to: Nobody/Anonymous (nobody) Summary: threading.Timer/timeouts break on change of win32 local time Initial Comment: THE ISSUE... --- threading.py imports time.time as _time. On win32 systems, time.time() periodically reads the system time to figure out when to fire an Event. System time can change while waiting for an Event! eg: If the system time is changed while a threading.Timer is pending, the execution time is affected by the time change. eg: set a pending Timer and then change the clock back an hour - this causes your Timer to fire an hour later. This is clearly not desirable. A FIX... --- A fix for this is to use time.clock() on win32 systems instead. Once I found the problem, I currently just fix it by overriding threading._time to be time.clock. Right now I do this in every file that uses threading.Timer. COMMENTS... --- The penalty for this is that there will be a rollover problem eventaully... when the 64-bit performance counter rolls over in 30+ years of continuous pc operation. I'd much rather have this near impossible event than the very likely system time change. This is a general problem I find with the time module and I often have to switch between time() and clock() dependent on operating system, but I only work with win32 and Linux. The issue is that if you want a high resolution and extended rollover counter, it is a different call on each system. ---------------------------------------------------------------------- Comment By: Joseph Tate (jtate) Date: 2007-03-28 15:07 Message: Logged In: YES user_id=55276 Originator: NO On Linux time.clock() is CPU time. And has no bearing at all on real time. On windows time.clock() is real time since CPU time is not available from the operating system. What if instead of replacing time.time() with time.clock(), the Queue and Event wait loops just kicked out if "remaining time" was larger than the initial wait time? Let the outer loop continue, and the next time wait is called, the "remaining time" will be calculated correctly. Otherwise, we could compare "remaining time" between one loop iteration and the subsequent and then *approximate* how much the time has changed to adjust the "end time" appropriately. ---------------------------------------------------------------------- Comment By: Joseph Tate (jtate) Date: 2006-10-09 13:59 Message: Logged In: YES user_id=55276 This is also currently a problem under Linux when the clock is set back. ---------------------------------------------------------------------- Comment By: Russell Warren (qopit) Date: 2006-06-27 20:01 Message: Logged In: YES user_id=1542586 No - just stating that clock() is definitely a better solution for win32. As you say, any system should just use a time-indpendent uptime counter that is as high resolution as possible. I don't know how to get this on linux, but I do seem to recall that, on linux, time() is higher resolution than clock() for some reason. If linux has no performance counter equivalent (isn't it a hardware thing anyway?) I have no clue which is worse... low resolution, or local time change issues. The first is limiting all the time, the second results in wacky and sporadic errors that people might not expect. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-27 15:04 Message: Logged In: YES user_id=764593 Logically, these calls should always use clock, since they don't care about the actual time; they only want a baseline for computing elapsed time. Are you saying that they should still use clock-time on linux anyway, because of resolution issues? ---------------------------------------------------------------------- Comment By: Russell Warren (qopit) Date: 2006-06-26 21:59 Message: Logged In: YES user_id=1542586 This is an issue for anything that uses threading.py's _time function. This includes _Condition.wait(), which screws up both Conditions and Events, which then screw up (for example) the core Queue.Queue timeout implementation. threading.Thread.join also uses the _time call, so it could also get screwed by changes to the local time on Win32. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508864&group_id=5470 From noreply at sourceforge.net Wed Mar 28 18:56:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 09:56:00 -0700 Subject: [ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace Message-ID: Bugs item #1599254, was opened at 2006-11-19 11:03 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 7 Private: No Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2007-03-28 12:56 Message: Logged In: YES user_id=11375 Originator: NO Created a branch in SVN at svn+ssh://pythondev at svn.python.org/python/branches/amk-mailbox to work on this for 2.5.1. I've committed the unified2 module patch and the test_concurrent_ad() test. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-24 15:48 Message: Logged In: YES user_id=11375 Originator: NO I've strengthened the warning again. The MH bug in unified2 is straightforward: MH.remove() opens a file object, locks it, closes the file object, and then tries to unlock it. Presumably the MH test case never bothered locking the mailbox before making changes before. ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2007-01-22 15:24 Message: Logged In: YES user_id=1504904 Originator: YES So what you propose to commit for 2.5 is basically mailbox-unified2 (your mailbox-unified-patch, minus the _toc clearing)? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-22 10:46 Message: Logged In: YES user_id=11375 Originator: NO This would be an API change, and therefore out-of-bounds for 2.5. I suggest giving up on this for 2.5.1 and only fixing it in 2.6. I'll add another warning to the docs, and maybe to the module as well. ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2007-01-21 17:10 Message: Logged In: YES user_id=1504904 Originator: YES Hold on, I have a plan. If _toc is only regenerated on locking, or at the end of a flush(), then the only way self._pending can be set at that time is if the application has made modifications before calling lock(). If we make that an exception-raising offence, then we can assume that self._toc is a faithful representation of the last known contents of the file. That means we can preserve the existing message keys on a reread without any of that _user_toc nonsense. Diff attached, to apply on top of mailbox-unified2. It's probably had even less review and testing than the previous version, but it appears to pass all the regression tests and doesn't change any existing semantics. File Added: mailbox-update-toc-new.diff ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-20 22:16 Message: Logged In: YES user_id=11375 Originator: NO I'm starting to lose track of all the variations on the bug. Maybe we should just add more warnings to the documentation about locking the mailbox when modifying it and not try to fix this at all. ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2007-01-20 13:20 Message: Logged In: YES user_id=1504904 Originator: YES Hang on. If a message's key changes after recreating _toc, that does not mean that another process has modified the mailbox. If the application removes a message and then (inadvertently) causes _toc to be regenerated, the keys of all subsequent messages will be decremented by one, due only to the application's own actions. That's what happens in the "broken locking" test case: the program intends to remove message 0, flush, and then remove message 1, but because _toc is regenerated in between, message 1 is renumbered as 0, message 2 is renumbered as 1, and so the program deletes message 2 instead. To clear _toc in such code without attempting to preserve the message keys turns possible data loss (in the case that another process modified the mailbox) into certain data loss. That's what I'm concerned about. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-19 10:24 Message: Logged In: YES user_id=11375 Originator: NO After reflection, I don't think the potential changing actually makes things any worse. _generate() always starts numbering keys with 1, so if a message's key changes because of lock()'s, re-reading, that means someone else has already modified the mailbox. Without the ToC clearing, you're already fated to have a corrupted mailbox because the new mailbox will be written using outdated file offsets. With the ToC clearing, you delete the wrong message. Neither outcome is good, but data is lost either way. The new behaviour is maybe a little bit better in that you're losing a single message but still generating a well-formed mailbox, and not a randomly jumbled mailbox. I suggest applying the patch to clear self._toc, and noting in the documentation that keys might possibly change after doing a lock(). ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2007-01-18 13:15 Message: Logged In: YES user_id=1504904 Originator: YES This version passes the new tests (it fixes the length checking bug, and no longer clears self._toc), but goes back to failing test_concurrent_add. File Added: mailbox-unified2-module.diff ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2007-01-18 13:14 Message: Logged In: YES user_id=1504904 Originator: YES Unfortunately, there is a problem with clearing _toc: it's basically the one I alluded to in my comment of 2006-12-16. Back then I thought it could be caught by the test you issue the warning for, but the application may instead do its second remove() *after* the lock() (so that self._pending is not set at lock() time), using the key carried over from before it called unlock(). As before, this would result in the wrong message being deleted. I've added a test case for this (diff attached), and a bug I found in the process whereby flush() wasn't updating the length, which could cause subsequent flushes to fail (I've got a fix for this). These seem to have turned up a third bug in the MH class, but I haven't looked at that yet. File Added: mailbox-unified2-test.diff ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-17 16:06 Message: Logged In: YES user_id=11375 Originator: NO Add mailbox-unified-patch. File Added: mailbox-unified-patch.diff ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-17 16:05 Message: Logged In: YES user_id=11375 Originator: NO mailbox-pending-lock is the difference between David's copy-back-new + fcntl-warning and my -unified patch, uploaded so that he can comment on the changes. The only change is to make _singleFileMailbox.lock() clear self._toc, forcing a re-read of the mailbox file. If _pending is true, the ToC isn't cleared and a warning is logged. I think this lets existing code run (albeit possibly with a warning if the mailbox is modified before .lock() is called), but fixes the risk of missing changes written by another process. Triggering a new warning is sort of an API change, but IMHO it's still worth backporting; code that triggers this warning is at risk of losing messages or corrupting the mailbox. Clearing the _toc on .lock() is also sort of an API change, but it's necessary to avoid the potential data loss. It may lead to some redundant scanning of mailbox files, but this price is worth paying, I think; people probably don't have 2Gb mbox files (I hope not, anyway!) and no extra read is done if you create the mailbox and immediately lock it before looking anything up. Neal: if you want to discuss this patch or want an explanation of something, feel free to chat with me about it. I'll wait a day or two and see if David spots any problems. If nothing turns up, I'll commit it to both trunk and release25-maint. File Added: mailbox-pending-lock.diff ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-17 15:53 Message: Logged In: YES user_id=11375 Originator: NO mailbox-unified-patch contains David's copy-back-new and fcntl-warn patches, plus the test-mailbox patch and some additional changes to mailbox.py from me. (I'll upload a diff to David's diffs in a minute.) This is the change I'd like to check in. test_mailbox.py now passes, as does the mailbox-break.py script I'm using. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-17 14:56 Message: Logged In: YES user_id=11375 Originator: NO Committed a modified version of the doc. patch in rev. 53472 (trunk) and rev. 53474 (release25-maint). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-01-17 01:48 Message: Logged In: YES user_id=33168 Originator: NO Andrew, do you need any help with this? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-15 14:01 Message: Logged In: YES user_id=11375 Originator: NO Comment from Andrew MacIntyre (os2vacpp is the OS/2 that lacks ftruncate()): ================ I actively support the OS/2 EMX port (sys.platform == "os2emx"; build directory is PC/os2emx). I would like to keep the VAC++ port alive, but the reality is I don't have the resources to do so. The VAC++ port was the subject of discussion about removal of build support support from the source tree for 2.6 - I don't recall there being a definitive outcome, but if someone does delete the PC/os2vacpp directory, I'm not in a position to argue. AMK: (mailbox.py has a separate section of code used when file.truncate() isn't available, and the existence of this section is bedevilling me. It would be convenient if platforms without file.truncate() weren't a factor; then this branch could just be removed. In your opinion, would it hurt OS/2 users of mailbox.py if support for platforms without file.truncate() was removed?) aimacintyre: No. From what documentation I can quickly check, ftruncate() operates on file descriptors rather than FILE pointers. As such I am sure that, if it became an issue, it would not be difficult to write a ftruncate() emulation wrapper for the underlying OS/2 APIs that implement the required functionality. ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2007-01-13 13:32 Message: Logged In: YES user_id=1504904 Originator: YES I like the warning idea - it seems appropriate if the problem is relatively rare. How about this? File Added: mailbox-fcntl-warn.diff ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-12 14:41 Message: Logged In: YES user_id=11375 Originator: NO One OS/2 port lacks truncate(), and so does RISCOS. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-12 13:41 Message: Logged In: YES user_id=11375 Originator: NO I realized that making flush() invalidate keys breaks the final example in the docs, which loops over inbox.iterkeys() and removes messages, doing a pack() after each message. Which platforms lack file.truncate()? Windows has it; POSIX has it, so modern Unix variants should all have it. Maybe mailbox should simply raise an exception (or trigger a warning?) if truncate is missing, and we should then assume that flush() has no effect upon keys. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-12 12:12 Message: Logged In: YES user_id=11375 Originator: NO So shall we document flush() as invalidating keys, then? ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2007-01-06 14:57 Message: Logged In: YES user_id=1504904 Originator: YES Oops, length checking had made the first two lines of this patch redundant; update-toc applies OK with fuzz. File Added: mailbox-copy-back-new.diff ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2007-01-06 10:30 Message: Logged In: YES user_id=1504904 Originator: YES File Added: mailbox-copy-back-53287.diff ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2007-01-06 10:24 Message: Logged In: YES user_id=1504904 Originator: YES Aack, yes, that should be _next_user_key. Attaching a fixed version. I've been thinking, though: flush() does in fact invalidate the keys on platforms without a file.truncate(), when the fcntl() lock is momentarily released afterwards. It seems hard to avoid this as, perversely, fcntl() locks are supposed to be released automatically on all file descriptors referring to the file whenever the process closes any one of them - even one the lock was never set on. So, code using mailbox.py such platforms could inadvertently be carrying keys across an unlocked period, which is not made safe by the update-toc patch (as it's only meant to avert disasters resulting from doing this *and* rebuilding the table of contents, *assuming* that another process hasn't deleted or rearranged messages). File Added: mailbox-update-toc-fixed.diff ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-05 14:51 Message: Logged In: YES user_id=11375 Originator: NO Question about mailbox-update-doc: the add() method still returns self._next_key - 1; should this be self._next_user_key - 1? The keys in _user_toc are the ones returned to external users of the mailbox, right? (A good test case would be to initialize _next_key to 0 and _next_user_key to a different value like 123456.) I'm still staring at the patch, trying to convince myself that it will help -- haven't spotted any problems, but this bug is making me nervous... ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-05 14:24 Message: Logged In: YES user_id=11375 Originator: NO As a step toward improving matters, I've attached the suggested doc patch (for both 25-maint and trunk). It encourages people to use Maildir :), explicitly states that modifications should be bracketed by lock(), and fixes the examples to match. It does not say that keys are invalidated by doing a flush(), because we're going to try to avoid the necessity for that. File Added: mailbox-docs.diff ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-20 14:48 Message: Logged In: YES user_id=11375 Originator: NO Committed length-checking.diff to trunk in rev. 53110. ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2006-12-20 14:19 Message: Logged In: YES user_id=1504904 Originator: YES File Added: mailbox-test-lock.diff ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2006-12-20 14:17 Message: Logged In: YES user_id=1504904 Originator: YES Yeah, I think that should definitely go in. ExternalClashError or a subclass sounds fine to me (although you could make a whole taxonomy of these errors, really). It would be good to have the code actually keep up with other programs' changes, though; a program might just want to count the messages at first, say, and not make changes until much later. I've been trying out the second option (patch attached, to apply on top of mailbox-copy-back), regenerating _toc on locking, but preserving existing keys. The patch allows existing _generate_toc()s to work unmodified, but means that _toc now holds the entire last known contents of the mailbox file, with the 'pending' (user-visible) mailbox state being held in a new attribute, _user_toc, which is a mapping from keys issued to the program to the keys of _toc (i.e. sequence numbers in the file). When _toc is updated, any new messages that have appeared are given keys in _user_toc that haven't been issued before, and any messages that have disappeared are removed from it. The code basically assumes that messages with the same sequence number are the same message, though, so even if most cases are caught by the length check, programs that make deletions/replacements before locking could still delete the wrong messages. This behaviour could be trapped, though, by raising an exception in lock() if self._pending is set (after all, code like that would be incorrect unless it could be assumed that the mailbox module kept hashes of each message or something). Also attached is a patch to the test case, adding a lock/unlock around the message count to make sure _toc is up-to-date if the parent process finishes first; without it, there are still intermittent failures. File Added: mailbox-update-toc.diff ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-20 09:46 Message: Logged In: YES user_id=11375 Originator: NO Attaching a patch that adds length checking: before doing a flush() on a single-file mailbox, seek to the end and verify its length is unchanged. It raises an ExternalClashError if the file's length has changed. (Should there be a different exception for this case, perhaps a subclass of ExternalClashError?) I verified that this change works by running a program that added 25 messages, pausing between each one, and then did 'echo "new line" > /tmp/mbox' from a shell while the program was running. I also noticed that the self._lookup() call in self.flush() wasn't necessary, and replaced it by an assertion. I think this change should go on both the trunk and 25-maint branches. File Added: length-checking.diff ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-18 12:43 Message: Logged In: YES user_id=11375 Originator: NO Eep, correct; changing the key IDs would be a big problem for existing code. We could say 'discard all keys' after doing lock() or unlock(), but this is an API change that means the fix couldn't be backported to 2.5-maint. We could make generating the ToC more complicated, preserving key IDs when possible; that may not be too difficult, though the code might be messy. Maybe it's best to just catch this error condition: save the size of the mailbox, updating it in _append_message(), and then make .flush() raise an exception if the mailbox size has unexpectedly changed. ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2006-12-16 14:09 Message: Logged In: YES user_id=1504904 Originator: YES Yes, I see what you mean. I had tried multiple flushes, but only inside a single lock/unlock. But this means that in the no-truncate() code path, even this is currently unsafe, as the lock is momentarily released after flushing. I think _toc should be regenerated after every lock(), as with the risk of another process replacing/deleting/rearranging the messages, it isn't valid to carry sequence numbers from one locked period to another anyway, or from unlocked to locked. However, this runs the risk of dangerously breaking code that thinks it is valid to do so, even in the case where the mailbox was *not* modified (i.e. turning possible failure into certain failure). For instance, if the program removes message 1, then as things stand, the key "1" is no longer used, and removing message 2 will remove the message that followed 1. If _toc is regenerated in between, however (using the current code, so that the messages are renumbered from 0), then the old message 2 becomes message 1, and removing message 2 will therefore remove the wrong message. You'd also have things like pending deletions and replacements (also unsafe generally) being forgotten. So it would take some work to get right, if it's to work at all... ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-15 09:06 Message: Logged In: YES user_id=11375 Originator: NO I'm testing the fix using two Python processes running mailbox.py, and my test case fails even with your patch. This is due to another bug, even in the patched version. mbox has a dictionary attribute, _toc, mapping message keys to positions in the file. flush() writes out all the messages in self._toc and constructs a new _toc with the new file offsets. It doesn't re-read the file to see if new messages were added by another process. One fix that seems to work: instead of doing 'self._toc = new_toc' after flush() has done its work, do self._toc = None. The ToC will be regenerated the next time _lookup() is called, causing a re-read of all the contents of the mbox. Inefficient, but I see no way around the necessity for doing this. It's not clear to me that my suggested fix is enough, though. Process #1 opens a mailbox, reads the ToC, and the process does something else for 5 minutes. In the meantime, process #2 adds a file to the mbox. Process #1 then adds a message to the mbox and writes it out; it never notices process #2's change. Maybe the _toc has to be regenerated every time you call lock(), because at this point you know there will be no further updates to the mbox by any other process. Any unlocked usage of _toc should also really be regenerating _toc every time, because you never know if another process has added a message... but that would be really inefficient. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-15 08:17 Message: Logged In: YES user_id=11375 Originator: NO The attached patch adds a test case to test_mailbox.py that demonstrates the problem. No modifications to mailbox.py are needed to show data loss. Now looking at the patch... File Added: mailbox-test.patch ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-12 16:04 Message: Logged In: YES user_id=11375 Originator: NO I agree with David's analysis; this is in fact a bug. I'll try to look at the patch. ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2006-11-19 15:44 Message: Logged In: YES user_id=1504904 Originator: YES This is a bug. The point is that the code is subverting the protection of its own fcntl locking. I should have pointed out that Postfix was still using fcntl locking, and that should have been sufficient. (In fact, it was due to its use of fcntl locking that it chose precisely the wrong moment to deliver mail.) Dot-locking does protect against this, but not every program uses it - which is precisely the reason that the code implements fcntl locking in the first place. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 15:02 Message: Logged In: YES user_id=21627 Originator: NO Mailbox locking was invented precisely to support this kind of operation. Why do you complain that things break if you deliberately turn off the mechanism preventing breakage? I fail to see a bug here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&group_id=5470 From noreply at sourceforge.net Wed Mar 28 20:39:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 11:39:44 -0700 Subject: [ python-Bugs-1290505 ] strptime(): can't switch locales more than once Message-ID: Bugs item #1290505, was opened at 2005-09-13 15:50 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470 Please note that this 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.5 >Status: Open >Resolution: None Priority: 5 Private: No Submitted By: Adam Monsen (meonkeys) Assigned to: Brett Cannon (bcannon) Summary: strptime(): can't switch locales more than once Initial Comment: After calling strptime() once, it appears that subsequent efforts to modify the locale settings (so dates strings in different locales can be parsed) throw a ValueError. I'm pasting everything here since spacing is irrelevant: import locale, time print locale.getdefaultlocale() # ('en_US', 'utf') print locale.getlocale(locale.LC_TIME) # (None, None) # save old locale old_loc = locale.getlocale(locale.LC_TIME) locale.setlocale(locale.LC_TIME, 'nl_NL') print locale.getlocale(locale.LC_TIME) # ('nl_NL', 'ISO8859-1') # parse local date date = '10 augustus 2005 om 17:26' format = '%d %B %Y om %H:%M' dateTuple = time.strptime(date, format) # switch back to previous locale locale.setlocale(locale.LC_TIME, old_loc) print locale.getlocale(locale.LC_TIME) # (None, None) date = '10 August 2005 at 17:26' format = '%d %B %Y at %H:%M' dateTuple = time.strptime(date, format) The output I get from this script is: ('en_US', 'utf') (None, None) ('nl_NL', 'ISO8859-1') (None, None) Traceback (most recent call last): File "switching.py", line 17, in ? dateTuple = time.strptime(date, format) File "/usr/lib/python2.4/_strptime.py", line 292, in strptime raise ValueError("time data did not match format: data=%s fmt=%s" % ValueError: time data did not match format: data=10 August 2005 at 17:26 fmt=%d %B %Y at %H:%M One workaround I found is by manually busting the regular expression cache in _strptime: import _strptime _strptime._cache_lock.acquire() _strptime._TimeRE_cache = _strptime.TimeRE() _strptime._regex_cache = {} _strptime._cache_lock.release() If I do all that, I can change the LC_TIME part of the locale as many times as I choose. If this isn't a bug, this should at least be in the documentation for the locale module and/or strptime(). ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2007-03-28 11:39 Message: Logged In: YES user_id=357491 Originator: NO kovan, can you please apply the patch I have uploaded to your copy of _strptime and let me know if that fixes it? I am oS X and switching locales doesn't work for me so I don't have an easy way to test this. File Added: strptime_cache.diff ---------------------------------------------------------------------- Comment By: kovan (kovan) Date: 2007-03-28 00:06 Message: Logged In: YES user_id=1426755 Originator: NO This is the code: def parseTime(strTime, format = "%a %b %d %H:%M:%S"):# example: Mon Aug 7 21:08:52 locale.setlocale(locale.LC_TIME, ('en_US','UTF8')) format = "%Y " + format strTime = str(datetime.now().year) + " " +strTime import _strptime _strptime._cache_lock.acquire() _strptime._TimeRE_cache = _strptime.TimeRE() _strptime._regex_cache = {} _strptime._cache_lock.release() tuple = strptime(strTime, format) return datetime(*tuple[0:6]) If I remove the code to clear the cache and add "print format_regex.pattern" statement to _strptime.py after "format_regex = time_re.compile(format)", I get (?P\d\d\d\d)\s*(?Pmi\???\???|s\???\???b|lun|mar|jue|vie|dom)\s*(?Pene|feb|mar|abr|may|jun|jul|ago|sep|oct|nov|dic)\s*(?P3[0-1]|[1-2]\d|0[1-9]|[1-9]| [1-9])\s*(?P2[0-3]|[0-1]\d|\d):(?P[0-5]\d|\d):(?P6[0-1]|[0-5]\d|\d) which is in my system's locale (es), and it should be in english. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-03-27 19:35 Message: Logged In: YES user_id=357491 Originator: NO Can you show some code that recreatess the problem? ---------------------------------------------------------------------- Comment By: kovan (kovan) Date: 2007-03-27 18:06 Message: Logged In: YES user_id=1426755 Originator: NO I think I'm having this issue with Python 2.5, as I can only make strptime take into account locale.setlocale() calls if I clear strptime's internal regexp cache between the calls to setlocal() and strptime(). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-09-14 19:42 Message: Logged In: YES user_id=357491 OK, the problem was that the cache for the locale information in terms of dates and time was being invalidated and recreated, but the regex cache was not being touched. I has now been fixed in rev. 1.41 for 2.5 and in rev. 1.38.2.3 for 2.4 . Thanks for reporting this, Adam. ---------------------------------------------------------------------- Comment By: Adam Monsen (meonkeys) Date: 2005-09-13 15:57 Message: Logged In: YES user_id=259388 I think there were some long lines in my code. Attaching test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470 From noreply at sourceforge.net Wed Mar 28 21:05:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 12:05:04 -0700 Subject: [ python-Bugs-1690103 ] trace module borks __file__ Message-ID: Bugs item #1690103, was opened at 2007-03-28 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=1690103&group_id=5470 Please note that this 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 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: trace module borks __file__ Initial Comment: Stick this in a file (say, printfile.py): print __file__ If I run it as "python printfile.py" using Python 2.4, 2.5 or 2.6 it prints as expected, e.g.: % python ~/tmp/printfile.py /Users/skip/tmp/printfile.py If, however, I run it under control of the trace module I get something entirely different: % python -m trace --count ~/tmp/printfile.py /Users/skip/local/lib/python2.6/trace.py % python -m trace --trace ~/tmp/printfile.py --- modulename: threading, funcname: settrace threading.py(70): _trace_hook = func --- modulename: trace, funcname: (1): --- modulename: trace, funcname: printfile.py(1): print __file__ /Users/skip/local/lib/python2.6/trace.py Definitely looks buggy to me... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690103&group_id=5470 From noreply at sourceforge.net Wed Mar 28 22:01:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 13:01:36 -0700 Subject: [ python-Bugs-1690103 ] trace module borks __file__ Message-ID: Bugs item #1690103, was opened at 2007-03-28 14:05 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690103&group_id=5470 Please note that this 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 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: trace module borks __file__ Initial Comment: Stick this in a file (say, printfile.py): print __file__ If I run it as "python printfile.py" using Python 2.4, 2.5 or 2.6 it prints as expected, e.g.: % python ~/tmp/printfile.py /Users/skip/tmp/printfile.py If, however, I run it under control of the trace module I get something entirely different: % python -m trace --count ~/tmp/printfile.py /Users/skip/local/lib/python2.6/trace.py % python -m trace --trace ~/tmp/printfile.py --- modulename: threading, funcname: settrace threading.py(70): _trace_hook = func --- modulename: trace, funcname: (1): --- modulename: trace, funcname: printfile.py(1): print __file__ /Users/skip/local/lib/python2.6/trace.py Definitely looks buggy to me... ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2007-03-28 15:01 Message: Logged In: YES user_id=44345 Originator: YES I believe this is because the trace module calls execfile() to run the file. I'm not sure if there's an easy fix for this problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690103&group_id=5470 From noreply at sourceforge.net Wed Mar 28 22:38:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 13:38:53 -0700 Subject: [ python-Bugs-1690103 ] trace module borks __file__ Message-ID: Bugs item #1690103, was opened at 2007-03-28 14:05 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690103&group_id=5470 Please note that this 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 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: trace module borks __file__ Initial Comment: Stick this in a file (say, printfile.py): print __file__ If I run it as "python printfile.py" using Python 2.4, 2.5 or 2.6 it prints as expected, e.g.: % python ~/tmp/printfile.py /Users/skip/tmp/printfile.py If, however, I run it under control of the trace module I get something entirely different: % python -m trace --count ~/tmp/printfile.py /Users/skip/local/lib/python2.6/trace.py % python -m trace --trace ~/tmp/printfile.py --- modulename: threading, funcname: settrace threading.py(70): _trace_hook = func --- modulename: trace, funcname: (1): --- modulename: trace, funcname: printfile.py(1): print __file__ /Users/skip/local/lib/python2.6/trace.py Definitely looks buggy to me... ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2007-03-28 15:38 Message: Logged In: YES user_id=44345 Originator: YES Hmmm... Maybe not so hard after all. See attached diff. Does anyone see a problem with simply overwriting the trace module's __file__ attribute? File Added: trace.diff ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-03-28 15:01 Message: Logged In: YES user_id=44345 Originator: YES I believe this is because the trace module calls execfile() to run the file. I'm not sure if there's an easy fix for this problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690103&group_id=5470 From noreply at sourceforge.net Wed Mar 28 23:00:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 14:00:53 -0700 Subject: [ python-Bugs-223616 ] compiler package needs better documentation. Message-ID: Bugs item #223616, was opened at 2000-11-27 15:33 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=223616&group_id=5470 Please note that this 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: Feature Request Status: Open Resolution: None Priority: 6 Private: No Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Jeremy Hylton (jhylton) Summary: compiler package needs better documentation. Initial Comment: The compiler package is not documented; this needs to be done before tools are likely to be written on top of it. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2007-03-28 18:00 Message: Logged In: YES user_id=752496 Originator: NO This is one of the oldest bugs we have... As the compiler package surely got revised with the inclusion of AST, and the bug was only to remember about polishing... this still needs to be open? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-03-01 19:38 Message: Logged In: YES user_id=31392 jeremy, get your butt in gear on this! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-21 15:19 Message: Logged In: YES user_id=3066 I'll note that Jeremy has written basic docs, and they are in the Library Reference. But he really needs to polish them a bit as well, so this stays open but gets a new summary. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-10 18:56 Message: Logged In: YES user_id=3066 Jeremy said he'd work on this next week, so I'm bumping the priority as a reminder. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-01-08 00:48 Message: Jeremy -- is there anything that can be done to make it easier for you to get this done? I think these should really be documented and moved into the library. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=223616&group_id=5470 From noreply at sourceforge.net Wed Mar 28 23:45:24 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 14:45:24 -0700 Subject: [ python-Bugs-1687163 ] Inconsistent Exceptions for Readonly Attributes Message-ID: Bugs item #1687163, was opened at 2007-03-23 17:51 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1687163&group_id=5470 Please note that this 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 3000 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Raymond Hettinger (rhettinger) Assigned to: Collin Winter (collinwinter) Summary: Inconsistent Exceptions for Readonly Attributes Initial Comment: Attempting assignment to a readonly attribute raises an Attribute error for pure Python attributes but raises a TypeError for C readonly attributes. I think the AttributeError is the correct exception. >>> class A(object): ... _x = [] ... ... @property ... def x(self): ... return self._x ... >>> a = A() >>> a.x = None Traceback (most recent call last): a.x = None AttributeError: can't set attribute >>> def f(): ... yield None >>> g = f() >>> g.gi_frame = None Traceback (most recent call last): g.gi_frame = None TypeError: readonly attribute ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-28 17:45 Message: Logged In: YES user_id=1344176 Originator: NO Fixed in r54602. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2007-03-26 16:18 Message: Logged In: YES user_id=80475 Originator: YES Collin, would you please apply this to the Py3K code. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2007-03-23 19:52 Message: Logged In: YES user_id=80475 Originator: YES Here's the one line change: Index: Python/structmember.c =================================================================== --- Python/structmember.c (revision 54557) +++ Python/structmember.c (working copy) @@ -160,7 +160,7 @@ if ((l->flags & READONLY) || l->type == T_STRING) { - PyErr_SetString(PyExc_TypeError, "readonly attribute"); + PyErr_SetString(PyExc_AttributeError, "readonly attribute"); Four of the tests will need to be updated: test_csv test_descr test_generators test_os ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2007-03-23 18:16 Message: Logged In: YES user_id=80475 Originator: YES Readonly methods throw an AttributeError, but readonly members (anything defined in PyMemberDef with an RO or READONLY flag) raise a TypeError. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2007-03-23 18:12 Message: Logged In: YES user_id=591932 Originator: NO I think this has something peculiar to frames, for instance: Python 2.5 (r25:51908, Sep 25 2006, 17:50:07) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> f = 'asdf' >>> f.strip = 42 Traceback (most recent call last): File "", line 1, in AttributeError: 'str' object attribute 'strip' is read-only >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1687163&group_id=5470 From noreply at sourceforge.net Wed Mar 28 23:48:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 14:48:53 -0700 Subject: [ python-Bugs-1688564 ] os.path.join.__doc__ should mention absolute paths Message-ID: Bugs item #1688564, was opened at 2007-03-26 13:12 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1688564&group_id=5470 Please note that this 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 Private: No Submitted By: Eugene Kramer (zdes) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.join.__doc__ should mention absolute paths Initial Comment: Currently, automatically generated docs from os.path.join do not mention that all paths prior to the last absolute path are discarded. The __doc__ says: "Join two or more pathname components, inserting '/' as needed" >From this documentation, it is not obvious that os.path.join("abc", "/cde", "fgh") results in "/cde/fgh". ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-28 17:48 Message: Logged In: YES user_id=1344176 Originator: NO """Join two or more pathname components, inserting '/' as needed. If any component is an absolute path, all previous path components will be discarded.""" Does that work for you? Could you come up with language that you'd prefer to see? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1688564&group_id=5470 From noreply at sourceforge.net Wed Mar 28 23:54:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 14:54:47 -0700 Subject: [ python-Bugs-1689458 ] pdb unable to jump to first statement Message-ID: Bugs item #1689458, was opened at 2007-03-27 17:07 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689458&group_id=5470 Please note that this 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 Private: No Submitted By: gotgenes (gotgenes) Assigned to: Nobody/Anonymous (nobody) Summary: pdb unable to jump to first statement Initial Comment: The Python debugger is unable to "jump" back to the first executable statement in a frame once that statement has been executed. For example: chris at feathers:~/development/playground$ python -m pdb simple.py > /home/chris/development/playground/simple.py(3)?() -> a = 1 (Pdb) next > /home/chris/development/playground/simple.py(4)?() -> b = 2 (Pdb) jump 3 > /home/chris/development/playground/simple.py(3)?() -> a = 1 (Pdb) list 1 #!/usr/bin/env python 2 3 a = 1 4 -> b = 2 5 6 c = a + b 7 8 print c [EOF] (Pdb) next > /home/chris/development/playground/simple.py(6)?() -> c = a + b One can see that after supposedly "jump"ing to line 3 at the second command, when "list"ing the line, the debugger is actually at line 4. The "next" command further demonstrates this since it re-executes line 4 and moves to line 6. This issue was raised on comp.lang.python. (For example, see or if that link is munged, refer to Duncan Booth offers the following: [quote] I verified (with a print statement in pdb) that assigning to self.curframe.f_lineno sets self.curframe.f_lineno and sel.curframe.f_lasti incorrectly ... The problem looks to be in frameobject.c: addr = 0; line = f->f_code->co_firstlineno; new_lasti = -1; for (offset = 0; offset < lnotab_len; offset += 2) { addr += lnotab[offset]; line += lnotab[offset+1]; if (line >= new_lineno) { new_lasti = addr; new_lineno = line; break; } } The first bytes in lnotab are the length and line increment for line 3 (i.e. 6, 1). If line==f->f_code->co_firstlineno it should set new_lasti=0, new_lineno=line but the loop still executes once which increments new_lasti and new_lineno to the next line (6, 4). [/quote] And Rocky Bernstein offers the following: [quote] Best as I can tell, it looks like a bug in Python. pdb, pydb, rpdb2 all handle the "jump" command by changing the frame f_lineno value. When the corresponding code pointer has offset 0 (or equivalently and more simlply as you put it, is the first statement) this doesn't seem to work properly. [/quote] ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-28 17:54 Message: Logged In: YES user_id=1344176 Originator: NO Could you work up a full test case for this? Or better yet, a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689458&group_id=5470 From noreply at sourceforge.net Thu Mar 29 00:05:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 15:05:40 -0700 Subject: [ python-Bugs-1681984 ] unittest documentation is incomplete Message-ID: Bugs item #1681984, was opened at 2007-03-16 06:17 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681984&group_id=5470 Please note that this 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 Private: No Submitted By: STINNER Victor (haypo) Assigned to: Collin Winter (collinwinter) Summary: unittest documentation is incomplete Initial Comment: When I tried to write a test suite using many test cases, I read the documentation (docs.python.org) but it does work because I was unable to run my test suite. Using Google I realised that documentation is incomplete! In Python binding of gstreamer, I found a "TextTestRunner"! So, would it be possible to update the doc? ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-28 18:05 Message: Logged In: YES user_id=1344176 Originator: NO I don't see the need to document TestProgram or TextTestRunner; the former is an implementation detail of the module (and a messy detail, to boot), not meant to be used in third-party code; the only time you'd come across the latter is when implementing custom test runners, in which case you're to the point of reading the module's source anyway. As for an example of how to use test runners and test suites, why? "unittest.main()" means most users never need to know about these things. Totally comprehensive documentation is an easy thing to get lost in. ---------------------------------------------------------------------- Comment By: STINNER Victor (haypo) Date: 2007-03-18 22:00 Message: Logged In: YES user_id=365388 Originator: YES "Could you please state what exactly is missing from the documentation, in your opinion?" Well, when I ready Python documentation I expect to have the full list of "builtin" modules, functions and classes. But if you check unittest module, documentation only list TestCase, TestSuite, TestResult and TestLoader. Whereas dir(unittest) gives TestCase, TestLoader, *TestProgram*, TestResult, TestSuite, *TextTestRunner*. So information about TestProgram and TextTestRunner is missing. I also expect a small example showing how to use a test runner and a test suite. I'm using: ------------------------------ 8< ----------------------- from unittest import TestSuite, TestLoader, TextTestRunner from sys import exit def loadTests(loader): """Generator listing all test cases""" ... def main(): loader = TestLoader() suite = TestSuite() for test in loadTests(loader.loadTestsFromTestCase): suite.addTests(test) runner = TextTestRunner(descriptions=2, verbosity=2) result = runner.run(suite) if result.failures or result.errors: exit(1) ------------------------------ 8< ----------------------- ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 09:02 Message: Logged In: YES user_id=849994 Originator: NO Could you please state what exactly is missing from the documentation, in your opinion? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681984&group_id=5470 From noreply at sourceforge.net Thu Mar 29 00:55:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 15:55:47 -0700 Subject: [ python-Bugs-1290505 ] strptime(): can't switch locales more than once Message-ID: Bugs item #1290505, was opened at 2005-09-14 00:50 Message generated for change (Comment added) made by kovan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Adam Monsen (meonkeys) Assigned to: Brett Cannon (bcannon) Summary: strptime(): can't switch locales more than once Initial Comment: After calling strptime() once, it appears that subsequent efforts to modify the locale settings (so dates strings in different locales can be parsed) throw a ValueError. I'm pasting everything here since spacing is irrelevant: import locale, time print locale.getdefaultlocale() # ('en_US', 'utf') print locale.getlocale(locale.LC_TIME) # (None, None) # save old locale old_loc = locale.getlocale(locale.LC_TIME) locale.setlocale(locale.LC_TIME, 'nl_NL') print locale.getlocale(locale.LC_TIME) # ('nl_NL', 'ISO8859-1') # parse local date date = '10 augustus 2005 om 17:26' format = '%d %B %Y om %H:%M' dateTuple = time.strptime(date, format) # switch back to previous locale locale.setlocale(locale.LC_TIME, old_loc) print locale.getlocale(locale.LC_TIME) # (None, None) date = '10 August 2005 at 17:26' format = '%d %B %Y at %H:%M' dateTuple = time.strptime(date, format) The output I get from this script is: ('en_US', 'utf') (None, None) ('nl_NL', 'ISO8859-1') (None, None) Traceback (most recent call last): File "switching.py", line 17, in ? dateTuple = time.strptime(date, format) File "/usr/lib/python2.4/_strptime.py", line 292, in strptime raise ValueError("time data did not match format: data=%s fmt=%s" % ValueError: time data did not match format: data=10 August 2005 at 17:26 fmt=%d %B %Y at %H:%M One workaround I found is by manually busting the regular expression cache in _strptime: import _strptime _strptime._cache_lock.acquire() _strptime._TimeRE_cache = _strptime.TimeRE() _strptime._regex_cache = {} _strptime._cache_lock.release() If I do all that, I can change the LC_TIME part of the locale as many times as I choose. If this isn't a bug, this should at least be in the documentation for the locale module and/or strptime(). ---------------------------------------------------------------------- Comment By: kovan (kovan) Date: 2007-03-29 00:55 Message: Logged In: YES user_id=1426755 Originator: NO I applied the patch, and it works now :). Thanks bcannon for the quick responses. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-03-28 20:39 Message: Logged In: YES user_id=357491 Originator: NO kovan, can you please apply the patch I have uploaded to your copy of _strptime and let me know if that fixes it? I am oS X and switching locales doesn't work for me so I don't have an easy way to test this. File Added: strptime_cache.diff ---------------------------------------------------------------------- Comment By: kovan (kovan) Date: 2007-03-28 09:06 Message: Logged In: YES user_id=1426755 Originator: NO This is the code: def parseTime(strTime, format = "%a %b %d %H:%M:%S"):# example: Mon Aug 7 21:08:52 locale.setlocale(locale.LC_TIME, ('en_US','UTF8')) format = "%Y " + format strTime = str(datetime.now().year) + " " +strTime import _strptime _strptime._cache_lock.acquire() _strptime._TimeRE_cache = _strptime.TimeRE() _strptime._regex_cache = {} _strptime._cache_lock.release() tuple = strptime(strTime, format) return datetime(*tuple[0:6]) If I remove the code to clear the cache and add "print format_regex.pattern" statement to _strptime.py after "format_regex = time_re.compile(format)", I get (?P\d\d\d\d)\s*(?Pmi\???\???|s\???\???b|lun|mar|jue|vie|dom)\s*(?Pene|feb|mar|abr|may|jun|jul|ago|sep|oct|nov|dic)\s*(?P3[0-1]|[1-2]\d|0[1-9]|[1-9]| [1-9])\s*(?P2[0-3]|[0-1]\d|\d):(?P[0-5]\d|\d):(?P6[0-1]|[0-5]\d|\d) which is in my system's locale (es), and it should be in english. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-03-28 04:35 Message: Logged In: YES user_id=357491 Originator: NO Can you show some code that recreatess the problem? ---------------------------------------------------------------------- Comment By: kovan (kovan) Date: 2007-03-28 03:06 Message: Logged In: YES user_id=1426755 Originator: NO I think I'm having this issue with Python 2.5, as I can only make strptime take into account locale.setlocale() calls if I clear strptime's internal regexp cache between the calls to setlocal() and strptime(). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-09-15 04:42 Message: Logged In: YES user_id=357491 OK, the problem was that the cache for the locale information in terms of dates and time was being invalidated and recreated, but the regex cache was not being touched. I has now been fixed in rev. 1.41 for 2.5 and in rev. 1.38.2.3 for 2.4 . Thanks for reporting this, Adam. ---------------------------------------------------------------------- Comment By: Adam Monsen (meonkeys) Date: 2005-09-14 00:57 Message: Logged In: YES user_id=259388 I think there were some long lines in my code. Attaching test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470 From noreply at sourceforge.net Thu Mar 29 01:37:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 16:37:26 -0700 Subject: [ python-Feature Requests-1634034 ] Show "expected" token on syntax error Message-ID: Feature Requests item #1634034, was opened at 2007-01-12 13:03 Message generated for change (Comment added) made by sean_gillespie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1634034&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Oliver Gramberg (oliver_gramberg) Assigned to: Nobody/Anonymous (nobody) Summary: Show "expected" token on syntax error Initial Comment: I suggest that the parser, when reporting a syntax error, should make use of its knowlegde of which token type is expected at the position where the error occurred. This results in more helpful error messages: ----------------------------------------------------- >>> for a in (8,9) File "", line 1 for a in (8,9) ^ SyntaxError: invalid syntax - COLON expected ----------------------------------------------------- >>> for a in (8,9: print a, File "", line 1 for a in (8,9: print a, ^ SyntaxError: invalid syntax: RPAR expected ----------------------------------------------------- I tried the following patch (for pythonrun.c). It works well in the shell both interactively and in scripts, as well as in IDLE. But it's not complete: - It doesn't always print useful messages (only for fixed-size terminal token types, I assume.) - There sure are cases where more than one token type is allowed in a position. I believe I have seen that this information is available too somewhere in the parser, but it is not forwarded to the err_input routine. It's even nicer to show "')'" instead of "RPAR"... ----------------------------------------------------- /* Set the error appropriate to the given input error code (see errcode.h) */ static void err_input(perrdetail *err) { PyObject *v, *w, *errtype; PyObject* u = NULL; char *msg = NULL; errtype = PyExc_SyntaxError; switch (err->error) { case E_SYNTAX: errtype = PyExc_IndentationError; if (err->expected == INDENT) msg = "expected an indented block"; else if (err->token == INDENT) msg = "unexpected indent"; else if (err->token == DEDENT) msg = "unexpected unindent"; else { char buf[50]; errtype = PyExc_SyntaxError; if(err->expected != -1) { snprintf(buf, 48, "invalid syntax - %.16s expected\0", _PyParser_TokenNames[err->expected]); msg = buf; } else { msg = "invalid syntax"; } } break; ... ----------------------------------------------------- I am willing to help work on this. Regards -Oliver ---------------------------------------------------------------------- Comment By: Sean Gillespie (sean_gillespie) Date: 2007-03-28 23:37 Message: Logged In: YES user_id=1744567 Originator: NO Your patch seems to work. I agree that showing the token (as in ")") would indeed be much more useful, and it would be pretty easy to implement. However, I think that you should generate a diff for your patch. Its incredibly hard to read over SF. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1634034&group_id=5470 From noreply at sourceforge.net Thu Mar 29 01:40:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 16:40:37 -0700 Subject: [ python-Bugs-1290505 ] strptime(): can't switch locales more than once Message-ID: Bugs item #1290505, was opened at 2005-09-13 15:50 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Adam Monsen (meonkeys) Assigned to: Brett Cannon (bcannon) Summary: strptime(): can't switch locales more than once Initial Comment: After calling strptime() once, it appears that subsequent efforts to modify the locale settings (so dates strings in different locales can be parsed) throw a ValueError. I'm pasting everything here since spacing is irrelevant: import locale, time print locale.getdefaultlocale() # ('en_US', 'utf') print locale.getlocale(locale.LC_TIME) # (None, None) # save old locale old_loc = locale.getlocale(locale.LC_TIME) locale.setlocale(locale.LC_TIME, 'nl_NL') print locale.getlocale(locale.LC_TIME) # ('nl_NL', 'ISO8859-1') # parse local date date = '10 augustus 2005 om 17:26' format = '%d %B %Y om %H:%M' dateTuple = time.strptime(date, format) # switch back to previous locale locale.setlocale(locale.LC_TIME, old_loc) print locale.getlocale(locale.LC_TIME) # (None, None) date = '10 August 2005 at 17:26' format = '%d %B %Y at %H:%M' dateTuple = time.strptime(date, format) The output I get from this script is: ('en_US', 'utf') (None, None) ('nl_NL', 'ISO8859-1') (None, None) Traceback (most recent call last): File "switching.py", line 17, in ? dateTuple = time.strptime(date, format) File "/usr/lib/python2.4/_strptime.py", line 292, in strptime raise ValueError("time data did not match format: data=%s fmt=%s" % ValueError: time data did not match format: data=10 August 2005 at 17:26 fmt=%d %B %Y at %H:%M One workaround I found is by manually busting the regular expression cache in _strptime: import _strptime _strptime._cache_lock.acquire() _strptime._TimeRE_cache = _strptime.TimeRE() _strptime._regex_cache = {} _strptime._cache_lock.release() If I do all that, I can change the LC_TIME part of the locale as many times as I choose. If this isn't a bug, this should at least be in the documentation for the locale module and/or strptime(). ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2007-03-28 16:40 Message: Logged In: YES user_id=357491 Originator: NO The power of procrastination in the morning. =) I am going to try to come up with a test case for this. I might ask, kovan, if you can run the test case to make sure it works. ---------------------------------------------------------------------- Comment By: Javier Sanz (kovan) Date: 2007-03-28 15:55 Message: Logged In: YES user_id=1426755 Originator: NO I applied the patch, and it works now :). Thanks bcannon for the quick responses. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-03-28 11:39 Message: Logged In: YES user_id=357491 Originator: NO kovan, can you please apply the patch I have uploaded to your copy of _strptime and let me know if that fixes it? I am oS X and switching locales doesn't work for me so I don't have an easy way to test this. File Added: strptime_cache.diff ---------------------------------------------------------------------- Comment By: Javier Sanz (kovan) Date: 2007-03-28 00:06 Message: Logged In: YES user_id=1426755 Originator: NO This is the code: def parseTime(strTime, format = "%a %b %d %H:%M:%S"):# example: Mon Aug 7 21:08:52 locale.setlocale(locale.LC_TIME, ('en_US','UTF8')) format = "%Y " + format strTime = str(datetime.now().year) + " " +strTime import _strptime _strptime._cache_lock.acquire() _strptime._TimeRE_cache = _strptime.TimeRE() _strptime._regex_cache = {} _strptime._cache_lock.release() tuple = strptime(strTime, format) return datetime(*tuple[0:6]) If I remove the code to clear the cache and add "print format_regex.pattern" statement to _strptime.py after "format_regex = time_re.compile(format)", I get (?P\d\d\d\d)\s*(?Pmi\???\???|s\???\???b|lun|mar|jue|vie|dom)\s*(?Pene|feb|mar|abr|may|jun|jul|ago|sep|oct|nov|dic)\s*(?P3[0-1]|[1-2]\d|0[1-9]|[1-9]| [1-9])\s*(?P2[0-3]|[0-1]\d|\d):(?P[0-5]\d|\d):(?P6[0-1]|[0-5]\d|\d) which is in my system's locale (es), and it should be in english. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-03-27 19:35 Message: Logged In: YES user_id=357491 Originator: NO Can you show some code that recreatess the problem? ---------------------------------------------------------------------- Comment By: Javier Sanz (kovan) Date: 2007-03-27 18:06 Message: Logged In: YES user_id=1426755 Originator: NO I think I'm having this issue with Python 2.5, as I can only make strptime take into account locale.setlocale() calls if I clear strptime's internal regexp cache between the calls to setlocal() and strptime(). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-09-14 19:42 Message: Logged In: YES user_id=357491 OK, the problem was that the cache for the locale information in terms of dates and time was being invalidated and recreated, but the regex cache was not being touched. I has now been fixed in rev. 1.41 for 2.5 and in rev. 1.38.2.3 for 2.4 . Thanks for reporting this, Adam. ---------------------------------------------------------------------- Comment By: Adam Monsen (meonkeys) Date: 2005-09-13 15:57 Message: Logged In: YES user_id=259388 I think there were some long lines in my code. Attaching test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470 From noreply at sourceforge.net Thu Mar 29 01:40:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 16:40:56 -0700 Subject: [ python-Bugs-1290505 ] strptime(): can't switch locales more than once Message-ID: Bugs item #1290505, was opened at 2005-09-13 15:50 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470 Please note that this 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.5 >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Adam Monsen (meonkeys) Assigned to: Brett Cannon (bcannon) Summary: strptime(): can't switch locales more than once Initial Comment: After calling strptime() once, it appears that subsequent efforts to modify the locale settings (so dates strings in different locales can be parsed) throw a ValueError. I'm pasting everything here since spacing is irrelevant: import locale, time print locale.getdefaultlocale() # ('en_US', 'utf') print locale.getlocale(locale.LC_TIME) # (None, None) # save old locale old_loc = locale.getlocale(locale.LC_TIME) locale.setlocale(locale.LC_TIME, 'nl_NL') print locale.getlocale(locale.LC_TIME) # ('nl_NL', 'ISO8859-1') # parse local date date = '10 augustus 2005 om 17:26' format = '%d %B %Y om %H:%M' dateTuple = time.strptime(date, format) # switch back to previous locale locale.setlocale(locale.LC_TIME, old_loc) print locale.getlocale(locale.LC_TIME) # (None, None) date = '10 August 2005 at 17:26' format = '%d %B %Y at %H:%M' dateTuple = time.strptime(date, format) The output I get from this script is: ('en_US', 'utf') (None, None) ('nl_NL', 'ISO8859-1') (None, None) Traceback (most recent call last): File "switching.py", line 17, in ? dateTuple = time.strptime(date, format) File "/usr/lib/python2.4/_strptime.py", line 292, in strptime raise ValueError("time data did not match format: data=%s fmt=%s" % ValueError: time data did not match format: data=10 August 2005 at 17:26 fmt=%d %B %Y at %H:%M One workaround I found is by manually busting the regular expression cache in _strptime: import _strptime _strptime._cache_lock.acquire() _strptime._TimeRE_cache = _strptime.TimeRE() _strptime._regex_cache = {} _strptime._cache_lock.release() If I do all that, I can change the LC_TIME part of the locale as many times as I choose. If this isn't a bug, this should at least be in the documentation for the locale module and/or strptime(). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-03-28 16:40 Message: Logged In: YES user_id=357491 Originator: NO The power of procrastination in the morning. =) I am going to try to come up with a test case for this. I might ask, kovan, if you can run the test case to make sure it works. ---------------------------------------------------------------------- Comment By: Javier Sanz (kovan) Date: 2007-03-28 15:55 Message: Logged In: YES user_id=1426755 Originator: NO I applied the patch, and it works now :). Thanks bcannon for the quick responses. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-03-28 11:39 Message: Logged In: YES user_id=357491 Originator: NO kovan, can you please apply the patch I have uploaded to your copy of _strptime and let me know if that fixes it? I am oS X and switching locales doesn't work for me so I don't have an easy way to test this. File Added: strptime_cache.diff ---------------------------------------------------------------------- Comment By: Javier Sanz (kovan) Date: 2007-03-28 00:06 Message: Logged In: YES user_id=1426755 Originator: NO This is the code: def parseTime(strTime, format = "%a %b %d %H:%M:%S"):# example: Mon Aug 7 21:08:52 locale.setlocale(locale.LC_TIME, ('en_US','UTF8')) format = "%Y " + format strTime = str(datetime.now().year) + " " +strTime import _strptime _strptime._cache_lock.acquire() _strptime._TimeRE_cache = _strptime.TimeRE() _strptime._regex_cache = {} _strptime._cache_lock.release() tuple = strptime(strTime, format) return datetime(*tuple[0:6]) If I remove the code to clear the cache and add "print format_regex.pattern" statement to _strptime.py after "format_regex = time_re.compile(format)", I get (?P\d\d\d\d)\s*(?Pmi\???\???|s\???\???b|lun|mar|jue|vie|dom)\s*(?Pene|feb|mar|abr|may|jun|jul|ago|sep|oct|nov|dic)\s*(?P3[0-1]|[1-2]\d|0[1-9]|[1-9]| [1-9])\s*(?P2[0-3]|[0-1]\d|\d):(?P[0-5]\d|\d):(?P6[0-1]|[0-5]\d|\d) which is in my system's locale (es), and it should be in english. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-03-27 19:35 Message: Logged In: YES user_id=357491 Originator: NO Can you show some code that recreatess the problem? ---------------------------------------------------------------------- Comment By: Javier Sanz (kovan) Date: 2007-03-27 18:06 Message: Logged In: YES user_id=1426755 Originator: NO I think I'm having this issue with Python 2.5, as I can only make strptime take into account locale.setlocale() calls if I clear strptime's internal regexp cache between the calls to setlocal() and strptime(). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-09-14 19:42 Message: Logged In: YES user_id=357491 OK, the problem was that the cache for the locale information in terms of dates and time was being invalidated and recreated, but the regex cache was not being touched. I has now been fixed in rev. 1.41 for 2.5 and in rev. 1.38.2.3 for 2.4 . Thanks for reporting this, Adam. ---------------------------------------------------------------------- Comment By: Adam Monsen (meonkeys) Date: 2005-09-13 15:57 Message: Logged In: YES user_id=259388 I think there were some long lines in my code. Attaching test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470 From noreply at sourceforge.net Thu Mar 29 01:44:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 16:44:52 -0700 Subject: [ python-Bugs-1290505 ] strptime(): can't switch locales more than once Message-ID: Bugs item #1290505, was opened at 2005-09-14 00:50 Message generated for change (Comment added) made by kovan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470 Please note that this 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.5 Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Adam Monsen (meonkeys) Assigned to: Brett Cannon (bcannon) Summary: strptime(): can't switch locales more than once Initial Comment: After calling strptime() once, it appears that subsequent efforts to modify the locale settings (so dates strings in different locales can be parsed) throw a ValueError. I'm pasting everything here since spacing is irrelevant: import locale, time print locale.getdefaultlocale() # ('en_US', 'utf') print locale.getlocale(locale.LC_TIME) # (None, None) # save old locale old_loc = locale.getlocale(locale.LC_TIME) locale.setlocale(locale.LC_TIME, 'nl_NL') print locale.getlocale(locale.LC_TIME) # ('nl_NL', 'ISO8859-1') # parse local date date = '10 augustus 2005 om 17:26' format = '%d %B %Y om %H:%M' dateTuple = time.strptime(date, format) # switch back to previous locale locale.setlocale(locale.LC_TIME, old_loc) print locale.getlocale(locale.LC_TIME) # (None, None) date = '10 August 2005 at 17:26' format = '%d %B %Y at %H:%M' dateTuple = time.strptime(date, format) The output I get from this script is: ('en_US', 'utf') (None, None) ('nl_NL', 'ISO8859-1') (None, None) Traceback (most recent call last): File "switching.py", line 17, in ? dateTuple = time.strptime(date, format) File "/usr/lib/python2.4/_strptime.py", line 292, in strptime raise ValueError("time data did not match format: data=%s fmt=%s" % ValueError: time data did not match format: data=10 August 2005 at 17:26 fmt=%d %B %Y at %H:%M One workaround I found is by manually busting the regular expression cache in _strptime: import _strptime _strptime._cache_lock.acquire() _strptime._TimeRE_cache = _strptime.TimeRE() _strptime._regex_cache = {} _strptime._cache_lock.release() If I do all that, I can change the LC_TIME part of the locale as many times as I choose. If this isn't a bug, this should at least be in the documentation for the locale module and/or strptime(). ---------------------------------------------------------------------- Comment By: Javier Sanz (kovan) Date: 2007-03-29 01:44 Message: Logged In: YES user_id=1426755 Originator: NO I'll be glad to help in whatever I can. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-03-29 01:40 Message: Logged In: YES user_id=357491 Originator: NO The power of procrastination in the morning. =) I am going to try to come up with a test case for this. I might ask, kovan, if you can run the test case to make sure it works. ---------------------------------------------------------------------- Comment By: Javier Sanz (kovan) Date: 2007-03-29 00:55 Message: Logged In: YES user_id=1426755 Originator: NO I applied the patch, and it works now :). Thanks bcannon for the quick responses. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-03-28 20:39 Message: Logged In: YES user_id=357491 Originator: NO kovan, can you please apply the patch I have uploaded to your copy of _strptime and let me know if that fixes it? I am oS X and switching locales doesn't work for me so I don't have an easy way to test this. File Added: strptime_cache.diff ---------------------------------------------------------------------- Comment By: Javier Sanz (kovan) Date: 2007-03-28 09:06 Message: Logged In: YES user_id=1426755 Originator: NO This is the code: def parseTime(strTime, format = "%a %b %d %H:%M:%S"):# example: Mon Aug 7 21:08:52 locale.setlocale(locale.LC_TIME, ('en_US','UTF8')) format = "%Y " + format strTime = str(datetime.now().year) + " " +strTime import _strptime _strptime._cache_lock.acquire() _strptime._TimeRE_cache = _strptime.TimeRE() _strptime._regex_cache = {} _strptime._cache_lock.release() tuple = strptime(strTime, format) return datetime(*tuple[0:6]) If I remove the code to clear the cache and add "print format_regex.pattern" statement to _strptime.py after "format_regex = time_re.compile(format)", I get (?P\d\d\d\d)\s*(?Pmi\???\???|s\???\???b|lun|mar|jue|vie|dom)\s*(?Pene|feb|mar|abr|may|jun|jul|ago|sep|oct|nov|dic)\s*(?P3[0-1]|[1-2]\d|0[1-9]|[1-9]| [1-9])\s*(?P2[0-3]|[0-1]\d|\d):(?P[0-5]\d|\d):(?P6[0-1]|[0-5]\d|\d) which is in my system's locale (es), and it should be in english. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-03-28 04:35 Message: Logged In: YES user_id=357491 Originator: NO Can you show some code that recreatess the problem? ---------------------------------------------------------------------- Comment By: Javier Sanz (kovan) Date: 2007-03-28 03:06 Message: Logged In: YES user_id=1426755 Originator: NO I think I'm having this issue with Python 2.5, as I can only make strptime take into account locale.setlocale() calls if I clear strptime's internal regexp cache between the calls to setlocal() and strptime(). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-09-15 04:42 Message: Logged In: YES user_id=357491 OK, the problem was that the cache for the locale information in terms of dates and time was being invalidated and recreated, but the regex cache was not being touched. I has now been fixed in rev. 1.41 for 2.5 and in rev. 1.38.2.3 for 2.4 . Thanks for reporting this, Adam. ---------------------------------------------------------------------- Comment By: Adam Monsen (meonkeys) Date: 2005-09-14 00:57 Message: Logged In: YES user_id=259388 I think there were some long lines in my code. Attaching test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470 From noreply at sourceforge.net Thu Mar 29 01:46:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 16:46:16 -0700 Subject: [ python-Bugs-1682403 ] docutils clarification request for "rest" Message-ID: Bugs item #1682403, was opened at 2007-03-16 15:58 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682403&group_id=5470 Please note that this 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 Private: No Submitted By: j vickroy (jvickroy) Assigned to: Nobody/Anonymous (nobody) Summary: docutils clarification request for "rest" Initial Comment: >From the definition of long_description: *'long string'* Multiple lines of plain text in reStructuredText format (see http://docutils.sf.net/). in: http://docs.python.org/dist/meta-data.html I incorrectly concluded that the the bdist_wininst installer would provide visual markup for long_description specified in restructured text. According to Thomas Heller, that is not the case. I wish to suggest adding this clarification to the distutils documentation perhaps in one or both of the following documents: http://docs.python.org/dist/postinstallation-script.html http://docs.python.org/dist/meta-data.html Thanks, -- jv ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-28 19:46 Message: Logged In: YES user_id=1344176 Originator: NO I'm not quite sure what the problem is. What kind of "visual markup" did you expect? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682403&group_id=5470 From noreply at sourceforge.net Thu Mar 29 03:24:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 18:24:53 -0700 Subject: [ python-Bugs-1689458 ] pdb unable to jump to first statement Message-ID: Bugs item #1689458, was opened at 2007-03-27 16:07 Message generated for change (Comment added) made by gotgenes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689458&group_id=5470 Please note that this 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 Private: No Submitted By: gotgenes (gotgenes) Assigned to: Nobody/Anonymous (nobody) Summary: pdb unable to jump to first statement Initial Comment: The Python debugger is unable to "jump" back to the first executable statement in a frame once that statement has been executed. For example: chris at feathers:~/development/playground$ python -m pdb simple.py > /home/chris/development/playground/simple.py(3)?() -> a = 1 (Pdb) next > /home/chris/development/playground/simple.py(4)?() -> b = 2 (Pdb) jump 3 > /home/chris/development/playground/simple.py(3)?() -> a = 1 (Pdb) list 1 #!/usr/bin/env python 2 3 a = 1 4 -> b = 2 5 6 c = a + b 7 8 print c [EOF] (Pdb) next > /home/chris/development/playground/simple.py(6)?() -> c = a + b One can see that after supposedly "jump"ing to line 3 at the second command, when "list"ing the line, the debugger is actually at line 4. The "next" command further demonstrates this since it re-executes line 4 and moves to line 6. This issue was raised on comp.lang.python. (For example, see or if that link is munged, refer to Duncan Booth offers the following: [quote] I verified (with a print statement in pdb) that assigning to self.curframe.f_lineno sets self.curframe.f_lineno and sel.curframe.f_lasti incorrectly ... The problem looks to be in frameobject.c: addr = 0; line = f->f_code->co_firstlineno; new_lasti = -1; for (offset = 0; offset < lnotab_len; offset += 2) { addr += lnotab[offset]; line += lnotab[offset+1]; if (line >= new_lineno) { new_lasti = addr; new_lineno = line; break; } } The first bytes in lnotab are the length and line increment for line 3 (i.e. 6, 1). If line==f->f_code->co_firstlineno it should set new_lasti=0, new_lineno=line but the loop still executes once which increments new_lasti and new_lineno to the next line (6, 4). [/quote] And Rocky Bernstein offers the following: [quote] Best as I can tell, it looks like a bug in Python. pdb, pydb, rpdb2 all handle the "jump" command by changing the frame f_lineno value. When the corresponding code pointer has offset 0 (or equivalently and more simlply as you put it, is the first statement) this doesn't seem to work properly. [/quote] ---------------------------------------------------------------------- >Comment By: gotgenes (gotgenes) Date: 2007-03-28 20:24 Message: Logged In: YES user_id=1180453 Originator: YES Truthfully, I don't have enough know-how to write a full test case or a patch. I have put forth a request on the comp.lang.python thread (link in original report) for those that would to please do so. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-28 16:54 Message: Logged In: YES user_id=1344176 Originator: NO Could you work up a full test case for this? Or better yet, a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689458&group_id=5470 From noreply at sourceforge.net Thu Mar 29 03:41:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 18:41:50 -0700 Subject: [ python-Bugs-1508864 ] threading.Timer/timeouts break on change of win32 local time Message-ID: Bugs item #1508864, was opened at 2006-06-19 14:53 Message generated for change (Comment added) made by xiaowen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508864&group_id=5470 Please note that this 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 Private: No Submitted By: Russell Warren (qopit) Assigned to: Nobody/Anonymous (nobody) Summary: threading.Timer/timeouts break on change of win32 local time Initial Comment: THE ISSUE... --- threading.py imports time.time as _time. On win32 systems, time.time() periodically reads the system time to figure out when to fire an Event. System time can change while waiting for an Event! eg: If the system time is changed while a threading.Timer is pending, the execution time is affected by the time change. eg: set a pending Timer and then change the clock back an hour - this causes your Timer to fire an hour later. This is clearly not desirable. A FIX... --- A fix for this is to use time.clock() on win32 systems instead. Once I found the problem, I currently just fix it by overriding threading._time to be time.clock. Right now I do this in every file that uses threading.Timer. COMMENTS... --- The penalty for this is that there will be a rollover problem eventaully... when the 64-bit performance counter rolls over in 30+ years of continuous pc operation. I'd much rather have this near impossible event than the very likely system time change. This is a general problem I find with the time module and I often have to switch between time() and clock() dependent on operating system, but I only work with win32 and Linux. The issue is that if you want a high resolution and extended rollover counter, it is a different call on each system. ---------------------------------------------------------------------- Comment By: xiaowen (xiaowen) Date: 2007-03-28 20:41 Message: Logged In: YES user_id=251143 Originator: NO Patch implementing what jtate described: --- python/Lib/threading.py 2007-03-29 09:13:53.000000000 +0800 +++ python/Lib/threading.py.new 2007-03-29 09:26:44.000000000 +0800 @@ -222,15 +222,19 @@ # than 20 times per second (or the timeout time remaining). endtime = _time() + timeout delay = 0.0005 # 500 us -> initial delay of 1 ms + remaining = max(timeout, 0) while True: gotit = waiter.acquire(0) if gotit: break - remaining = endtime - _time() if remaining <= 0: break delay = min(delay * 2, remaining, .05) _sleep(delay) + if endtime - _time() > remaining: + # Time must have been moved back, so readjust endtime. + endtime = _time() + remaining - delay + remaining = endtime - _time() if not gotit: if __debug__: self._note("%s.wait(%s): timed out", self, timeout) --- python/Lib/Queue.py 2007-01-01 00:38:56.000000000 +0800 +++ python/Lib/Queue.py.new 2007-01-01 00:42:14.000000000 +0800 @@ -127,7 +127,7 @@ endtime = _time() + timeout while self._full(): remaining = endtime - _time() - if remaining <= 0.0: + if remaining <= 0.0 or remaining > timeout: raise Full self.not_full.wait(remaining) self._put(item) @@ -169,7 +169,7 @@ endtime = _time() + timeout while self._empty(): remaining = endtime - _time() - if remaining <= 0.0: + if remaining <= 0.0 or remaining > timeout: raise Empty self.not_empty.wait(remaining) item = self._get() ---------------------------------------------------------------------- Comment By: Joseph Tate (jtate) Date: 2007-03-28 10:07 Message: Logged In: YES user_id=55276 Originator: NO On Linux time.clock() is CPU time. And has no bearing at all on real time. On windows time.clock() is real time since CPU time is not available from the operating system. What if instead of replacing time.time() with time.clock(), the Queue and Event wait loops just kicked out if "remaining time" was larger than the initial wait time? Let the outer loop continue, and the next time wait is called, the "remaining time" will be calculated correctly. Otherwise, we could compare "remaining time" between one loop iteration and the subsequent and then *approximate* how much the time has changed to adjust the "end time" appropriately. ---------------------------------------------------------------------- Comment By: Joseph Tate (jtate) Date: 2006-10-09 08:59 Message: Logged In: YES user_id=55276 This is also currently a problem under Linux when the clock is set back. ---------------------------------------------------------------------- Comment By: Russell Warren (qopit) Date: 2006-06-27 15:01 Message: Logged In: YES user_id=1542586 No - just stating that clock() is definitely a better solution for win32. As you say, any system should just use a time-indpendent uptime counter that is as high resolution as possible. I don't know how to get this on linux, but I do seem to recall that, on linux, time() is higher resolution than clock() for some reason. If linux has no performance counter equivalent (isn't it a hardware thing anyway?) I have no clue which is worse... low resolution, or local time change issues. The first is limiting all the time, the second results in wacky and sporadic errors that people might not expect. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-27 10:04 Message: Logged In: YES user_id=764593 Logically, these calls should always use clock, since they don't care about the actual time; they only want a baseline for computing elapsed time. Are you saying that they should still use clock-time on linux anyway, because of resolution issues? ---------------------------------------------------------------------- Comment By: Russell Warren (qopit) Date: 2006-06-26 16:59 Message: Logged In: YES user_id=1542586 This is an issue for anything that uses threading.py's _time function. This includes _Condition.wait(), which screws up both Conditions and Events, which then screw up (for example) the core Queue.Queue timeout implementation. threading.Thread.join also uses the _time call, so it could also get screwed by changes to the local time on Win32. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508864&group_id=5470 From noreply at sourceforge.net Thu Mar 29 04:07:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 19:07:13 -0700 Subject: [ python-Bugs-1290505 ] strptime(): can't switch locales more than once Message-ID: Bugs item #1290505, was opened at 2005-09-13 15:50 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470 Please note that this 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.5 Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Adam Monsen (meonkeys) Assigned to: Brett Cannon (bcannon) Summary: strptime(): can't switch locales more than once Initial Comment: After calling strptime() once, it appears that subsequent efforts to modify the locale settings (so dates strings in different locales can be parsed) throw a ValueError. I'm pasting everything here since spacing is irrelevant: import locale, time print locale.getdefaultlocale() # ('en_US', 'utf') print locale.getlocale(locale.LC_TIME) # (None, None) # save old locale old_loc = locale.getlocale(locale.LC_TIME) locale.setlocale(locale.LC_TIME, 'nl_NL') print locale.getlocale(locale.LC_TIME) # ('nl_NL', 'ISO8859-1') # parse local date date = '10 augustus 2005 om 17:26' format = '%d %B %Y om %H:%M' dateTuple = time.strptime(date, format) # switch back to previous locale locale.setlocale(locale.LC_TIME, old_loc) print locale.getlocale(locale.LC_TIME) # (None, None) date = '10 August 2005 at 17:26' format = '%d %B %Y at %H:%M' dateTuple = time.strptime(date, format) The output I get from this script is: ('en_US', 'utf') (None, None) ('nl_NL', 'ISO8859-1') (None, None) Traceback (most recent call last): File "switching.py", line 17, in ? dateTuple = time.strptime(date, format) File "/usr/lib/python2.4/_strptime.py", line 292, in strptime raise ValueError("time data did not match format: data=%s fmt=%s" % ValueError: time data did not match format: data=10 August 2005 at 17:26 fmt=%d %B %Y at %H:%M One workaround I found is by manually busting the regular expression cache in _strptime: import _strptime _strptime._cache_lock.acquire() _strptime._TimeRE_cache = _strptime.TimeRE() _strptime._regex_cache = {} _strptime._cache_lock.release() If I do all that, I can change the LC_TIME part of the locale as many times as I choose. If this isn't a bug, this should at least be in the documentation for the locale module and/or strptime(). ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2007-03-28 19:07 Message: Logged In: YES user_id=357491 Originator: NO I have uploaded a patch for test_strptime that adds a test to make sure that the TimeRE instance is recreated if the locale changes (went with en_US and de_DE, but could easily be other locales if there are other ones that are more common). Let me know if the test runs fine and works. Even better is if it fails without the fix. File Added: strptime_timere_test.diff ---------------------------------------------------------------------- Comment By: Javier Sanz (kovan) Date: 2007-03-28 16:44 Message: Logged In: YES user_id=1426755 Originator: NO I'll be glad to help in whatever I can. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-03-28 16:40 Message: Logged In: YES user_id=357491 Originator: NO The power of procrastination in the morning. =) I am going to try to come up with a test case for this. I might ask, kovan, if you can run the test case to make sure it works. ---------------------------------------------------------------------- Comment By: Javier Sanz (kovan) Date: 2007-03-28 15:55 Message: Logged In: YES user_id=1426755 Originator: NO I applied the patch, and it works now :). Thanks bcannon for the quick responses. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-03-28 11:39 Message: Logged In: YES user_id=357491 Originator: NO kovan, can you please apply the patch I have uploaded to your copy of _strptime and let me know if that fixes it? I am oS X and switching locales doesn't work for me so I don't have an easy way to test this. File Added: strptime_cache.diff ---------------------------------------------------------------------- Comment By: Javier Sanz (kovan) Date: 2007-03-28 00:06 Message: Logged In: YES user_id=1426755 Originator: NO This is the code: def parseTime(strTime, format = "%a %b %d %H:%M:%S"):# example: Mon Aug 7 21:08:52 locale.setlocale(locale.LC_TIME, ('en_US','UTF8')) format = "%Y " + format strTime = str(datetime.now().year) + " " +strTime import _strptime _strptime._cache_lock.acquire() _strptime._TimeRE_cache = _strptime.TimeRE() _strptime._regex_cache = {} _strptime._cache_lock.release() tuple = strptime(strTime, format) return datetime(*tuple[0:6]) If I remove the code to clear the cache and add "print format_regex.pattern" statement to _strptime.py after "format_regex = time_re.compile(format)", I get (?P\d\d\d\d)\s*(?Pmi\???\???|s\???\???b|lun|mar|jue|vie|dom)\s*(?Pene|feb|mar|abr|may|jun|jul|ago|sep|oct|nov|dic)\s*(?P3[0-1]|[1-2]\d|0[1-9]|[1-9]| [1-9])\s*(?P2[0-3]|[0-1]\d|\d):(?P[0-5]\d|\d):(?P6[0-1]|[0-5]\d|\d) which is in my system's locale (es), and it should be in english. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-03-27 19:35 Message: Logged In: YES user_id=357491 Originator: NO Can you show some code that recreatess the problem? ---------------------------------------------------------------------- Comment By: Javier Sanz (kovan) Date: 2007-03-27 18:06 Message: Logged In: YES user_id=1426755 Originator: NO I think I'm having this issue with Python 2.5, as I can only make strptime take into account locale.setlocale() calls if I clear strptime's internal regexp cache between the calls to setlocal() and strptime(). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-09-14 19:42 Message: Logged In: YES user_id=357491 OK, the problem was that the cache for the locale information in terms of dates and time was being invalidated and recreated, but the regex cache was not being touched. I has now been fixed in rev. 1.41 for 2.5 and in rev. 1.38.2.3 for 2.4 . Thanks for reporting this, Adam. ---------------------------------------------------------------------- Comment By: Adam Monsen (meonkeys) Date: 2005-09-13 15:57 Message: Logged In: YES user_id=259388 I think there were some long lines in my code. Attaching test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470 From noreply at sourceforge.net Thu Mar 29 04:20:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 19:20:04 -0700 Subject: [ python-Bugs-1572084 ] .eml attachments in email Message-ID: <200703290220.l2T2K4WV002172@sc8-sf-db2-new-b.sourceforge.net> Bugs item #1572084, was opened at 2006-10-06 05:23 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1572084&group_id=5470 Please note that this 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.5 >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: rainwolf8472 (rainwolf8472) Assigned to: Barry A. Warsaw (bwarsaw) Summary: .eml attachments in email Initial Comment: I think there's a bug somewhere in the email package. I wanted to write a script to send emails with certain attachments using libgmail, and found this one, http://pramode.net/articles/lfy/fuse/4.txt , it works fine with most files, but it fails with .eml files, and what i can't understand is that if I change the extension of those .eml files to .txt, the script works fine. However, when trying to mail a simple textfile containing "hello", en changing the extension to .eml before sending, it fails again. it doesn't fail when I don't change the extension to .eml. Any help please? I pasted the output I get (over and over again) in the attached textfile. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-03-28 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2007-03-13 22:04 Message: Logged In: YES user_id=12800 Originator: NO I'll need more information in order to debug this. Please try to create a small, standalone, reproducible test case. I don't have libgmail available so please don't write a test case that depends on that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1572084&group_id=5470 From noreply at sourceforge.net Thu Mar 29 04:44:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 19:44:25 -0700 Subject: [ python-Bugs-1690324 ] Typographical Error Message-ID: Bugs item #1690324, was opened at 2007-03-29 10:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690324&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mervyn Yeo (myeo) Assigned to: Nobody/Anonymous (nobody) Summary: Typographical Error Initial Comment: Python Tutorial 8.3 Handling Exceptions "One my also instantiate an exception first before raising it and add any attributes to it as desired." 'my' should be 'may' instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690324&group_id=5470 From noreply at sourceforge.net Thu Mar 29 04:45:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 19:45:06 -0700 Subject: [ python-Bugs-1690324 ] Typographical Error Message-ID: Bugs item #1690324, was opened at 2007-03-29 10:44 Message generated for change (Settings changed) made by myeo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690324&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None >Priority: 1 Private: No Submitted By: Mervyn Yeo (myeo) Assigned to: Nobody/Anonymous (nobody) Summary: Typographical Error Initial Comment: Python Tutorial 8.3 Handling Exceptions "One my also instantiate an exception first before raising it and add any attributes to it as desired." 'my' should be 'may' instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690324&group_id=5470 From noreply at sourceforge.net Thu Mar 29 07:11:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 22:11:50 -0700 Subject: [ python-Bugs-1690324 ] Typographical Error Message-ID: Bugs item #1690324, was opened at 2007-03-29 11:44 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690324&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Out of Date Priority: 1 Private: No Submitted By: Mervyn Yeo (myeo) >Assigned to: George Yoshida (quiver) Summary: Typographical Error Initial Comment: Python Tutorial 8.3 Handling Exceptions "One my also instantiate an exception first before raising it and add any attributes to it as desired." 'my' should be 'may' instead. ---------------------------------------------------------------------- >Comment By: George Yoshida (quiver) Date: 2007-03-29 14:11 Message: Logged In: YES user_id=671362 Originator: NO This is a known issue and already fixed in the subversion(see r52048 and r52049). Thanks for the report anyway. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690324&group_id=5470 From noreply at sourceforge.net Thu Mar 29 15:27:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Mar 2007 06:27:49 -0700 Subject: [ python-Bugs-1690608 ] email.utils.formataddr() should be rfc2047 aware Message-ID: Bugs item #1690608, was opened at 2007-03-29 09:27 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=1690608&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.utils.formataddr() should be rfc2047 aware Initial Comment: formataddr() should rfc2047 encode its name argument if necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690608&group_id=5470 From noreply at sourceforge.net Thu Mar 29 16:03:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Mar 2007 07:03:47 -0700 Subject: [ python-Bugs-1685000 ] DoS asyncore vulnerability Message-ID: Bugs item #1685000, was opened at 2007-03-21 10:15 Message generated for change (Comment added) made by billiejoex You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685000&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: billiejoex (billiejoex) Assigned to: Nobody/Anonymous (nobody) Summary: DoS asyncore vulnerability Initial Comment: DoS asyncore vulnerability asyncore, independently if used with select() or poll(), suffers a DoS-type vulnerability when a high number of simultaneous connections to handle simultaneously is reached. The number of maximum connections is system-dependent as well as the type of error raised. I attached two simple Proof of Concept scripts demonstrating such bug. If you want to try the behaviours listed below run the attached "asyncore_server.py" and "asyncore_client.py" scripts on your local workstation. On my Windows XP system (Python 2.5), independently if asyncore has been used to develop a server or a client, the error is raised by select() inside asyncore's "poll" function when 512 (socket_map's elements) simultaneous connections are reached. Here's the traceback I get: [...] connections: 510 connections: 511 connections: 512 Traceback (most recent call last): File "C:\scripts\asyncore_server.py", line 38, in asyncore.loop() File "C:\Python25\lib\asyncore.py", line 191, in loop poll_fun(timeout, map) File "C:\Python25\lib\asyncore.py", line 121, in poll r, w, e = select.select(r, w, e, timeout) ValueError: too many file descriptors in select() On my Linux Ubuntu 6.10 (kernel 2.6.17-10, Python 2.5) different type of errors are raised depending on the application (client or server). In an asyncore-based client the error is raised by socket module (dispatcher's "self.socket" attribute) inside 'connect' method of 'dispatcher' class: [...] connections: 1018 connections: 1019 connections: 1020 connections: 1021 Traceback (most recent call last): File "asyncore_client.py", line 31, in File "asyncore.py", line 191, in loop File "asyncore.py", line 138, in poll File "asyncore.py", line 80, in write File "asyncore.py", line 76, in write File "asyncore.py", line 395, in handle_write_event File "asyncore_client.py", line 24, in handle_connect File "asyncore_client.py", line 9, in __init__ File "asyncore.py", line 257, in create_socket File "socket.py", line 156, in __init__ socket.error: (24, 'Too many open files') On an asyncore-based server the error is raised by socket module (dispatcher's "self.socket" attribute) inside 'accept' method of 'dispatcher' class: [...] connections: 1019 connections: 1020 connections: 1021 Traceback (most recent call last): File "asyncore_server.py", line 38, in File "asyncore.py", line 191, in loop File "asyncore.py", line 132, in poll File "asyncore.py", line 72, in read File "asyncore.py", line 68, in read File "asyncore.py", line 384, in handle_read_event File "asyncore_server.py", line 16, in handle_accept File "asyncore.py", line 321, in accept File "socket.py", line 170, in accept socket.error: (24, 'Too many open files') ---------------------------------------------------------------------- >Comment By: billiejoex (billiejoex) Date: 2007-03-29 16:03 Message: Logged In: YES user_id=1357589 Originator: YES > The problem is that there's no portable way to know what the limit > on file descriptors is. Why don't put a try/except statement before creating a new socket's file-descriptor? I believe that such problem shouldn't be understimated. Actually asyncore is the only asynchronous module present in Python's stdlib. If asyncore suffers a DoS vulnerability it just means that writing a secure client/server application with Python without using a third-party library isn't possible. I wrote a modified version of asyncore that solves the problem with select (affecting Windows) but still can't find a way to solve the problem with socket's file-descriptors (affecting Unix). ---------------------------------------------------------------------- Comment By: Sam Rushing (rushing) Date: 2007-03-23 20:59 Message: Logged In: YES user_id=73736 Originator: NO The problem is that there's no portable way to know what the limit on file descriptors is. The 'classic' for select/poll is the FD_SETSIZE macro. But on some operating systems there is no such limit. [e.g., win32 does not use the 'lowest-free-int' model common to unix]. I believe that in Medusa there was a derived class or extension that counted the number of open sockets, and limited it, using something like a semaphore. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685000&group_id=5470 From noreply at sourceforge.net Thu Mar 29 16:26:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Mar 2007 07:26:29 -0700 Subject: [ python-Bugs-1682403 ] docutils clarification request for "rest" Message-ID: Bugs item #1682403, was opened at 2007-03-16 19:58 Message generated for change (Comment added) made by jvickroy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682403&group_id=5470 Please note that this 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 Private: No Submitted By: j vickroy (jvickroy) Assigned to: Nobody/Anonymous (nobody) Summary: docutils clarification request for "rest" Initial Comment: >From the definition of long_description: *'long string'* Multiple lines of plain text in reStructuredText format (see http://docutils.sf.net/). in: http://docs.python.org/dist/meta-data.html I incorrectly concluded that the the bdist_wininst installer would provide visual markup for long_description specified in restructured text. According to Thomas Heller, that is not the case. I wish to suggest adding this clarification to the distutils documentation perhaps in one or both of the following documents: http://docs.python.org/dist/postinstallation-script.html http://docs.python.org/dist/meta-data.html Thanks, -- jv ---------------------------------------------------------------------- >Comment By: j vickroy (jvickroy) Date: 2007-03-29 14:26 Message: Logged In: YES user_id=17213 Originator: YES I expected bold font when using "**" markers, list bullets when using "*" and "-" markers, etc. in the long_description text definition. Unfortunately, all of these markers are simply passed through unprocessed in the long description text that appears in the opening window when running the generated binary installer. Does this help clarify the issue? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-28 23:46 Message: Logged In: YES user_id=1344176 Originator: NO I'm not quite sure what the problem is. What kind of "visual markup" did you expect? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682403&group_id=5470 From noreply at sourceforge.net Thu Mar 29 17:44:27 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Mar 2007 08:44:27 -0700 Subject: [ python-Bugs-1493676 ] time.strftime() %z error Message-ID: Bugs item #1493676, was opened at 2006-05-23 16:58 Message generated for change (Comment added) made by csharkey You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&group_id=5470 Please note that this 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 Private: No Submitted By: Cillian Sharkey (csharkey) Assigned to: Nobody/Anonymous (nobody) Summary: time.strftime() %z error Initial Comment: According to the time module documentation, if the time argument for strftime() is not provided, it will use the current time as returned by localtime(). However, when the value of localtime() is explicitly given to strftime(), this produces an error in the value of the timezone offset (%z) as seen here: >>> from time import * >>> strftime("%a %b %e %H:%M:%S %Y %Z %z") 'Tue May 23 16:28:31 2006 IST +0100' >>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime()) 'Tue May 23 16:28:31 2006 IST +0000' This same problem happens for other timezones (the offset is always +0000 when localtime() is explicitly given). This problem is present in both these versions: Python 2.4.2 (#2, Sep 30 2005, 21:19:01) [GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu8)] on linux2 Python 2.3.5 (#2, Sep 4 2005, 22:01:42) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 ---------------------------------------------------------------------- >Comment By: Cillian Sharkey (csharkey) Date: 2007-03-29 16:44 Message: Logged In: YES user_id=1527351 Originator: YES Hi all, glad to see this bug is being addressed! Paul - thanks for your work, I hope your patching efforts make it into the tree. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-02-23 23:26 Message: Logged In: YES user_id=226443 Originator: NO See patch #1667546 for a somewhat tested implementation of the changes mentioned below. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-02-23 23:13 Message: Logged In: YES user_id=226443 Originator: NO It's probably too late to change details of the time tuple (far too much code now depends on it), but I have patches against 2.4.4 which provide an additional function called localtime_tz, which itself returns a localtime tuple containing the additional "GMT offset" field. With some modifications to various internal functions, the "struct tm" data can be populated and strftime can then produce the desired result. With regard to datetime, it does support time zones, but there's a relatively large of work required to get "aware" datetime objects. I noted this situation in the referenced newsgroup message on this topic. ---------------------------------------------------------------------- Comment By: bwooster47 (bwooster47) Date: 2007-02-23 18:33 Message: Logged In: YES user_id=1209659 Originator: NO Thanks, I'll let this go. (datetime is even worse - it does not handle any timezone data, and requires users to create their own timezone info). So right now Python has no support for the functions that are readily available to GNU C-lib users of time, that's that, and I won't argue about it, will just assume Python cannot produce RFC 822 conformant dates with standard libraries. (Perl, PHP, all work fine (but they are not Python)). (C-lib strftime has no problems printing %z with the time-tuple - with just dst info - because it is supposed to be the local time zone as set on the computer. No data needed in the tuple. >From the man page: %z The time-zone as hour offset from GMT. Required to emit RFC 822-conformant dates (using "%a, %d %b %Y %H:%M:%S %z"). (GNU) ) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-02-23 17:23 Message: Logged In: YES user_id=357491 Originator: NO OK, but that is an issue of how much information is stored in the time tuple. There is no UTC offset or timezone information stored in the tuple beyond whether DST is on or not. That is just an inherit shortcoming of the time tuple. You can't fix that without adding a new field to the time tuple itself. I am personally not about to do that, but if someone wants to write a patch it might be considered. But you will also need to discuss why this should be done over just moving to datetime (and possibly fixing it there if there are problems there as well). ---------------------------------------------------------------------- Comment By: bwooster47 (bwooster47) Date: 2007-02-23 15:38 Message: Logged In: YES user_id=1209659 Originator: NO To continue my previous comment, here's the snippet of a posting from comp.lang.python discussion, posted by "Paul Boddie": As far as I can see, the reason for the differing behaviour of time.strftime is due to the way any supplied tuple is processed: 1. In Modules/timemodule.c, the time_strftime function calls gettmarg. 2. In gettmarg, various fields of struct tm are filled in, except for tm_gmtoff and tm_zone/__tm_zone (according to /usr/include/time.h). 3. Consequently, any structure produced from a tuple may lack those fields, in contrast to such structures produced directly by the system calls. 4. Thus, the strftime system call fails to find or make use of time zone information. So it looks like no call to strftime with a supplied argument will produce time zone information. ---------------------------------------------------------------------- Comment By: bwooster47 (bwooster47) Date: 2007-02-23 15:20 Message: Logged In: YES user_id=1209659 Originator: NO But the C library does support it (and ones that don't will start - +nnnn is ISO format, and frankly, I don't know a C library that does not support it, though I'm sure some exist). The question is different - as the original post shows: >>> strftime("%a %b %e %H:%M:%S %Y %Z %z") 'Tue May 23 16:28:31 2006 IST +0100' >>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime()) 'Tue May 23 16:28:31 2006 IST +0000' Python has clearly used the C-library to get correct data in the first code path through strftime, but there is a second code path that prints wrong data. Someone posted code analysis in comp.lang.python explaining this, maybe that can be used as a starting point for a patch to fix the two code paths in Python strftime to work the same? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-02-23 14:25 Message: Logged In: YES user_id=357491 Originator: NO It is not a Python issue. strftime is a very thin wrapper to the underlying C implementation, so if the C library doesn't support %z, neither does Python. You can write a patch if you want to cause it to blank out if it is not supported and submit it. ---------------------------------------------------------------------- Comment By: bwooster47 (bwooster47) Date: 2007-02-22 16:22 Message: Logged In: YES user_id=1209659 Originator: NO Can we confirm whether this issue is not a python issue? We are talking about small z, not capital Z. >From Python docs at http://docs.python.org/lib/module-time.html : "The use of %Z is now deprecated, but the %z escape that expands to the preferred hour/minute offset is not supported by all ANSI C libraries." Most current C libraries support %z, it is in fact the preferred way to do things, would be bad to see python reject this. Even then - isn't the above a bug? If not supported, %z should always provide a empty character, but not print out totally incorrect data as +0000 for EST. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-05-24 22:26 Message: Logged In: YES user_id=357491 Closing as invalid since, as Georg pointed out, %z is not supported by Python. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-23 17:58 Message: Logged In: YES user_id=849994 Note that %z isn't officially supported by Python, judging by the docs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&group_id=5470 From noreply at sourceforge.net Thu Mar 29 18:53:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Mar 2007 09:53:08 -0700 Subject: [ python-Bugs-1290505 ] strptime(): can't switch locales more than once Message-ID: Bugs item #1290505, was opened at 2005-09-14 00:50 Message generated for change (Comment added) made by kovan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470 Please note that this 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.5 Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Adam Monsen (meonkeys) Assigned to: Brett Cannon (bcannon) Summary: strptime(): can't switch locales more than once Initial Comment: After calling strptime() once, it appears that subsequent efforts to modify the locale settings (so dates strings in different locales can be parsed) throw a ValueError. I'm pasting everything here since spacing is irrelevant: import locale, time print locale.getdefaultlocale() # ('en_US', 'utf') print locale.getlocale(locale.LC_TIME) # (None, None) # save old locale old_loc = locale.getlocale(locale.LC_TIME) locale.setlocale(locale.LC_TIME, 'nl_NL') print locale.getlocale(locale.LC_TIME) # ('nl_NL', 'ISO8859-1') # parse local date date = '10 augustus 2005 om 17:26' format = '%d %B %Y om %H:%M' dateTuple = time.strptime(date, format) # switch back to previous locale locale.setlocale(locale.LC_TIME, old_loc) print locale.getlocale(locale.LC_TIME) # (None, None) date = '10 August 2005 at 17:26' format = '%d %B %Y at %H:%M' dateTuple = time.strptime(date, format) The output I get from this script is: ('en_US', 'utf') (None, None) ('nl_NL', 'ISO8859-1') (None, None) Traceback (most recent call last): File "switching.py", line 17, in ? dateTuple = time.strptime(date, format) File "/usr/lib/python2.4/_strptime.py", line 292, in strptime raise ValueError("time data did not match format: data=%s fmt=%s" % ValueError: time data did not match format: data=10 August 2005 at 17:26 fmt=%d %B %Y at %H:%M One workaround I found is by manually busting the regular expression cache in _strptime: import _strptime _strptime._cache_lock.acquire() _strptime._TimeRE_cache = _strptime.TimeRE() _strptime._regex_cache = {} _strptime._cache_lock.release() If I do all that, I can change the LC_TIME part of the locale as many times as I choose. If this isn't a bug, this should at least be in the documentation for the locale module and/or strptime(). ---------------------------------------------------------------------- Comment By: Javier Sanz (kovan) Date: 2007-03-29 18:53 Message: Logged In: YES user_id=1426755 Originator: NO I've been looking at the test case, and I noticed that isn't actually checking anything, because locale.getlocale(locale.LC_TIME) is returning (None,None), which is ok and just means that the default locale (which is the C locale, not the system locale) is being used. After removing that 'if' I also changed de_DE by es_ES to fit my system, and strptime('10', '%d') by strptime('Fri', '%a') and strptime('vie','%a'); because '10' is '10' in all -occidental- languages, and the test would not fail when the wrong locale is being used. Once I made these changes to the test case, it successfully failed when using the non-patched _strptime.py, AND ran ok when using the patched version. This is the test case I ended up using: def test_TimeRE_recreation(self): # The TimeRE instance should be recreated upon changing the locale. locale_info = locale.getlocale(locale.LC_TIME) locale.setlocale(locale.LC_TIME, ('en_US', 'UTF8')) try: _strptime.strptime('Fri', '%a') first_time_re_id = id(_strptime._TimeRE_cache) locale.setlocale(locale.LC_TIME, ('es_ES', 'UTF8')) _strptime.strptime('vie', '%a') second_time_re_id = id(_strptime._TimeRE_cache) self.failIfEqual(first_time_re_id, second_time_re_id) finally: locale.setlocale(locale.LC_TIME, locale_info) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-03-29 04:07 Message: Logged In: YES user_id=357491 Originator: NO I have uploaded a patch for test_strptime that adds a test to make sure that the TimeRE instance is recreated if the locale changes (went with en_US and de_DE, but could easily be other locales if there are other ones that are more common). Let me know if the test runs fine and works. Even better is if it fails without the fix. File Added: strptime_timere_test.diff ---------------------------------------------------------------------- Comment By: Javier Sanz (kovan) Date: 2007-03-29 01:44 Message: Logged In: YES user_id=1426755 Originator: NO I'll be glad to help in whatever I can. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-03-29 01:40 Message: Logged In: YES user_id=357491 Originator: NO The power of procrastination in the morning. =) I am going to try to come up with a test case for this. I might ask, kovan, if you can run the test case to make sure it works. ---------------------------------------------------------------------- Comment By: Javier Sanz (kovan) Date: 2007-03-29 00:55 Message: Logged In: YES user_id=1426755 Originator: NO I applied the patch, and it works now :). Thanks bcannon for the quick responses. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-03-28 20:39 Message: Logged In: YES user_id=357491 Originator: NO kovan, can you please apply the patch I have uploaded to your copy of _strptime and let me know if that fixes it? I am oS X and switching locales doesn't work for me so I don't have an easy way to test this. File Added: strptime_cache.diff ---------------------------------------------------------------------- Comment By: Javier Sanz (kovan) Date: 2007-03-28 09:06 Message: Logged In: YES user_id=1426755 Originator: NO This is the code: def parseTime(strTime, format = "%a %b %d %H:%M:%S"):# example: Mon Aug 7 21:08:52 locale.setlocale(locale.LC_TIME, ('en_US','UTF8')) format = "%Y " + format strTime = str(datetime.now().year) + " " +strTime import _strptime _strptime._cache_lock.acquire() _strptime._TimeRE_cache = _strptime.TimeRE() _strptime._regex_cache = {} _strptime._cache_lock.release() tuple = strptime(strTime, format) return datetime(*tuple[0:6]) If I remove the code to clear the cache and add "print format_regex.pattern" statement to _strptime.py after "format_regex = time_re.compile(format)", I get (?P\d\d\d\d)\s*(?Pmi\???\???|s\???\???b|lun|mar|jue|vie|dom)\s*(?Pene|feb|mar|abr|may|jun|jul|ago|sep|oct|nov|dic)\s*(?P3[0-1]|[1-2]\d|0[1-9]|[1-9]| [1-9])\s*(?P2[0-3]|[0-1]\d|\d):(?P[0-5]\d|\d):(?P6[0-1]|[0-5]\d|\d) which is in my system's locale (es), and it should be in english. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-03-28 04:35 Message: Logged In: YES user_id=357491 Originator: NO Can you show some code that recreatess the problem? ---------------------------------------------------------------------- Comment By: Javier Sanz (kovan) Date: 2007-03-28 03:06 Message: Logged In: YES user_id=1426755 Originator: NO I think I'm having this issue with Python 2.5, as I can only make strptime take into account locale.setlocale() calls if I clear strptime's internal regexp cache between the calls to setlocal() and strptime(). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-09-15 04:42 Message: Logged In: YES user_id=357491 OK, the problem was that the cache for the locale information in terms of dates and time was being invalidated and recreated, but the regex cache was not being touched. I has now been fixed in rev. 1.41 for 2.5 and in rev. 1.38.2.3 for 2.4 . Thanks for reporting this, Adam. ---------------------------------------------------------------------- Comment By: Adam Monsen (meonkeys) Date: 2005-09-14 00:57 Message: Logged In: YES user_id=259388 I think there were some long lines in my code. Attaching test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470 From noreply at sourceforge.net Thu Mar 29 20:36:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Mar 2007 11:36:10 -0700 Subject: [ python-Bugs-1615275 ] tempile.TemporaryFile differences between linux and windows Message-ID: Bugs item #1615275, was opened at 2006-12-13 16:20 Message generated for change (Comment added) made by draghuram You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1615275&group_id=5470 Please note that this 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: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: hirzel (hirzel) Assigned to: Nobody/Anonymous (nobody) Summary: tempile.TemporaryFile differences between linux and windows Initial Comment: This bug came up when trying to write a numpy array to a tempfile.TemporaryFile() using the numpy 'tofile' method on windows using python 2.4. with a numpy array 'a', and a TemporaryFile 'f', on windows: >>> a.tofile(f) throws an IOError, where on Linux it does not. On windows, you must use a.tofile(f.file) The cause of this difference is that in windows, tempfile.TemporaryFile() returns that has a 'file' attribute of , whereas in linux tempfile.TemporaryFile() returns and there is no 'file' attribute. Ideally, the windows version would align with linux, and the module documentation and TemporaryFile() would return a . If this is not possible, it seems like the linux version and docs should be changed to match the windows version to align cross-platform behavior. At least, that seems to be the shared opinion of this thread from the mailing list: numpy-discussion. http://www.mail-archive.com/numpy-discussion at scipy.org/msg00271.html To my knowledge, while platform differences in tempfile have been reported in the past, this one has not. ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-03-29 14:36 Message: Logged In: YES user_id=984087 Originator: NO After looking at tempfile.py, the reason for the difference in behaviour is clear. On windows, "TemporaryFile" is an alias for "NamedTemporaryFile". NamedTemporaryFile() returns a wrapper instance with file-like interface but which is not actually a file. This is not a problem when file operations like "write" and "close" are used directly. But array.tofile() explicitly checks for file type object and hence fails with NamedTemporaryFile(). Same is the reason for numpy failure as reported by OP (I haven't explicitly analyzed numpy failure but gleaned this info from the discussion thread in the initial post). Even though the reason is clear, I think the end result is a bit unsatisfactory. array.tofile() (and numpy's tofile()) need to pass different parameters depending on the platform. One possible solution is for "TemporaryFile" to return a wrapper as well. Then, tofile() can be called with TemporaryFile().file on all platforms. ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-03-28 10:43 Message: Logged In: YES user_id=984087 Originator: NO I used the following code to reproduce the problem on windows XP. ---------- import array import tempfile testarray = array.array('B') testarray.fromstring("\x00\x00\x00") f = tempfile.TemporaryFile() testarray.tofile(f) ----------- This works fine on linux but on windows, it gives the following error: ------------- Traceback (most recent call last): File "c:\rags\tofile.py", line 7, in testarray.tofile(f) TypeError: arg must be open file ------------- Changing "f" to "f.file" seems to work, though, as explained in the initial post. So this may be the same problem as OP reported even though I am getting TypeError and he mentioned IOError. I tested with 2.4 and 2.5 as I don't know how to set up python development environment on windows (yet). I will see if I can set that up first before working on the "fix". Raghu. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1615275&group_id=5470 From noreply at sourceforge.net Thu Mar 29 21:14:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Mar 2007 12:14:04 -0700 Subject: [ python-Bugs-1690840 ] xmlrpclib methods submit call on __str__, __repr__ Message-ID: Bugs item #1690840, was opened at 2007-03-29 19:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690840&group_id=5470 Please note that this 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 Private: No Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib methods submit call on __str__, __repr__ Initial Comment: Notice how trying to print a method causes it to submit the call: Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from xmlrpclib import ServerProxy >>> s = ServerProxy("http://google.com") >>> print s.somecall Traceback (most recent call last): File "", line 1, in File "c:\python25\lib\xmlrpclib.py", line 1147, in __call__ return self.__send(self.__name, args) File "c:\python25\lib\xmlrpclib.py", line 1437, in __request verbose=self.__verbose File "c:\python25\lib\xmlrpclib.py", line 1191, in request headers xmlrpclib.ProtocolError: >> f = s.somecall >>> locals() {'f': Traceback (most recent call last): File "", line 1, in File "c:\python25\lib\xmlrpclib.py", line 1147, in __call__ return self.__send(self.__name, args) File "c:\python25\lib\xmlrpclib.py", line 1437, in __request verbose=self.__verbose File "c:\python25\lib\xmlrpclib.py", line 1191, in request headers xmlrpclib.ProtocolError: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690840&group_id=5470 From noreply at sourceforge.net Thu Mar 29 22:03:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Mar 2007 13:03:08 -0700 Subject: [ python-Bugs-1290505 ] strptime(): can't switch locales more than once Message-ID: Bugs item #1290505, was opened at 2005-09-13 15:50 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470 Please note that this 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.5 Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Adam Monsen (meonkeys) Assigned to: Brett Cannon (bcannon) Summary: strptime(): can't switch locales more than once Initial Comment: After calling strptime() once, it appears that subsequent efforts to modify the locale settings (so dates strings in different locales can be parsed) throw a ValueError. I'm pasting everything here since spacing is irrelevant: import locale, time print locale.getdefaultlocale() # ('en_US', 'utf') print locale.getlocale(locale.LC_TIME) # (None, None) # save old locale old_loc = locale.getlocale(locale.LC_TIME) locale.setlocale(locale.LC_TIME, 'nl_NL') print locale.getlocale(locale.LC_TIME) # ('nl_NL', 'ISO8859-1') # parse local date date = '10 augustus 2005 om 17:26' format = '%d %B %Y om %H:%M' dateTuple = time.strptime(date, format) # switch back to previous locale locale.setlocale(locale.LC_TIME, old_loc) print locale.getlocale(locale.LC_TIME) # (None, None) date = '10 August 2005 at 17:26' format = '%d %B %Y at %H:%M' dateTuple = time.strptime(date, format) The output I get from this script is: ('en_US', 'utf') (None, None) ('nl_NL', 'ISO8859-1') (None, None) Traceback (most recent call last): File "switching.py", line 17, in ? dateTuple = time.strptime(date, format) File "/usr/lib/python2.4/_strptime.py", line 292, in strptime raise ValueError("time data did not match format: data=%s fmt=%s" % ValueError: time data did not match format: data=10 August 2005 at 17:26 fmt=%d %B %Y at %H:%M One workaround I found is by manually busting the regular expression cache in _strptime: import _strptime _strptime._cache_lock.acquire() _strptime._TimeRE_cache = _strptime.TimeRE() _strptime._regex_cache = {} _strptime._cache_lock.release() If I do all that, I can change the LC_TIME part of the locale as many times as I choose. If this isn't a bug, this should at least be in the documentation for the locale module and/or strptime(). ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2007-03-29 13:03 Message: Logged In: YES user_id=357491 Originator: NO The test was checking that the TimeRE instance is recreated when the locale changes. You do have a valid point about the 'if' check; should have put the setlocale call in an try/except block and just returned if an exception was raised. As for the %d usage of strptime, that is just to force a call into strptime and thus trigger the new instance of TimeRE. That is why the test checks the id of the objects; don't really care about strptime directly failing. Did the test not fail properly even when you removed the 'if' but left everything else alone? ---------------------------------------------------------------------- Comment By: Javier Sanz (kovan) Date: 2007-03-29 09:53 Message: Logged In: YES user_id=1426755 Originator: NO I've been looking at the test case, and I noticed that isn't actually checking anything, because locale.getlocale(locale.LC_TIME) is returning (None,None), which is ok and just means that the default locale (which is the C locale, not the system locale) is being used. After removing that 'if' I also changed de_DE by es_ES to fit my system, and strptime('10', '%d') by strptime('Fri', '%a') and strptime('vie','%a'); because '10' is '10' in all -occidental- languages, and the test would not fail when the wrong locale is being used. Once I made these changes to the test case, it successfully failed when using the non-patched _strptime.py, AND ran ok when using the patched version. This is the test case I ended up using: def test_TimeRE_recreation(self): # The TimeRE instance should be recreated upon changing the locale. locale_info = locale.getlocale(locale.LC_TIME) locale.setlocale(locale.LC_TIME, ('en_US', 'UTF8')) try: _strptime.strptime('Fri', '%a') first_time_re_id = id(_strptime._TimeRE_cache) locale.setlocale(locale.LC_TIME, ('es_ES', 'UTF8')) _strptime.strptime('vie', '%a') second_time_re_id = id(_strptime._TimeRE_cache) self.failIfEqual(first_time_re_id, second_time_re_id) finally: locale.setlocale(locale.LC_TIME, locale_info) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-03-28 19:07 Message: Logged In: YES user_id=357491 Originator: NO I have uploaded a patch for test_strptime that adds a test to make sure that the TimeRE instance is recreated if the locale changes (went with en_US and de_DE, but could easily be other locales if there are other ones that are more common). Let me know if the test runs fine and works. Even better is if it fails without the fix. File Added: strptime_timere_test.diff ---------------------------------------------------------------------- Comment By: Javier Sanz (kovan) Date: 2007-03-28 16:44 Message: Logged In: YES user_id=1426755 Originator: NO I'll be glad to help in whatever I can. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-03-28 16:40 Message: Logged In: YES user_id=357491 Originator: NO The power of procrastination in the morning. =) I am going to try to come up with a test case for this. I might ask, kovan, if you can run the test case to make sure it works. ---------------------------------------------------------------------- Comment By: Javier Sanz (kovan) Date: 2007-03-28 15:55 Message: Logged In: YES user_id=1426755 Originator: NO I applied the patch, and it works now :). Thanks bcannon for the quick responses. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-03-28 11:39 Message: Logged In: YES user_id=357491 Originator: NO kovan, can you please apply the patch I have uploaded to your copy of _strptime and let me know if that fixes it? I am oS X and switching locales doesn't work for me so I don't have an easy way to test this. File Added: strptime_cache.diff ---------------------------------------------------------------------- Comment By: Javier Sanz (kovan) Date: 2007-03-28 00:06 Message: Logged In: YES user_id=1426755 Originator: NO This is the code: def parseTime(strTime, format = "%a %b %d %H:%M:%S"):# example: Mon Aug 7 21:08:52 locale.setlocale(locale.LC_TIME, ('en_US','UTF8')) format = "%Y " + format strTime = str(datetime.now().year) + " " +strTime import _strptime _strptime._cache_lock.acquire() _strptime._TimeRE_cache = _strptime.TimeRE() _strptime._regex_cache = {} _strptime._cache_lock.release() tuple = strptime(strTime, format) return datetime(*tuple[0:6]) If I remove the code to clear the cache and add "print format_regex.pattern" statement to _strptime.py after "format_regex = time_re.compile(format)", I get (?P\d\d\d\d)\s*(?Pmi\???\???|s\???\???b|lun|mar|jue|vie|dom)\s*(?Pene|feb|mar|abr|may|jun|jul|ago|sep|oct|nov|dic)\s*(?P3[0-1]|[1-2]\d|0[1-9]|[1-9]| [1-9])\s*(?P2[0-3]|[0-1]\d|\d):(?P[0-5]\d|\d):(?P6[0-1]|[0-5]\d|\d) which is in my system's locale (es), and it should be in english. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-03-27 19:35 Message: Logged In: YES user_id=357491 Originator: NO Can you show some code that recreatess the problem? ---------------------------------------------------------------------- Comment By: Javier Sanz (kovan) Date: 2007-03-27 18:06 Message: Logged In: YES user_id=1426755 Originator: NO I think I'm having this issue with Python 2.5, as I can only make strptime take into account locale.setlocale() calls if I clear strptime's internal regexp cache between the calls to setlocal() and strptime(). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-09-14 19:42 Message: Logged In: YES user_id=357491 OK, the problem was that the cache for the locale information in terms of dates and time was being invalidated and recreated, but the regex cache was not being touched. I has now been fixed in rev. 1.41 for 2.5 and in rev. 1.38.2.3 for 2.4 . Thanks for reporting this, Adam. ---------------------------------------------------------------------- Comment By: Adam Monsen (meonkeys) Date: 2005-09-13 15:57 Message: Logged In: YES user_id=259388 I think there were some long lines in my code. Attaching test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290505&group_id=5470 From noreply at sourceforge.net Fri Mar 30 00:06:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Mar 2007 15:06:06 -0700 Subject: [ python-Bugs-1689617 ] Intel icc build fails with optimizations -O2 Message-ID: Bugs item #1689617, was opened at 2007-03-28 04:26 Message generated for change (Comment added) made by mforbes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689617&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michael Forbes (mforbes) Assigned to: Nobody/Anonymous (nobody) Summary: Intel icc build fails with optimizations -O2 Initial Comment: When building python 2.5 with the free Intel compilers for non-commercial use (icc), the build works without optimizations, but fails when optimizations -O2 and -O3 are used. The compilation proceedes without errors (though there are lot's of warnings and remarks) and makes a python executable, but when the python setup starts, the intepreter cannot import certain packages and cannot add two strings. case $MAKEFLAGS in \ *-s*) CC='icc -pthread' LDSHARED='icc -pthread -shared' OPT='-DNDEBUG -g -O2 -Ob2 -w1' ./python -E ./setup.py -q build;; \ *) CC='icc -pthread' LDSHARED='icc -pthread -shared' OPT='-DNDEBUG -g -O2 -Ob2 -w1' ./python -E ./setup.py build;; \ esac 'import site' failed; use -v for traceback Traceback (most recent call last): File "./setup.py", line 6, in import sys, os, imp, re, optparse File "/int/apps/mmf/src/Python-2.5_intel/Lib/optparse.py", line 71, in import textwrap File "/int/apps/mmf/src/Python-2.5_intel/Lib/textwrap.py", line 10, in import string, re File "/int/apps/mmf/src/Python-2.5_intel/Lib/string.py", line 26, in letters = lowercase + uppercase SystemError: error return without exception set make: *** [sharedmods] Error 1 For example: $ ./python 'import site' failed; use -v for traceback Python 2.5 (r25:51908, Mar 27 2007, 20:10:22) [GCC Intel(R) C++ gcc 3.4 mode] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a = "123" >>> a + "12" Traceback (most recent call last): File "", line 1, in SystemError: error return without exception set >>> Note that both the import of the site file fails and the addition fails. Python was configured with the following options: ./configure --with-gcc=icc\ --with-cxx-main=icc\ --prefix=/int/apps/mmf/apps/Python-2.5_intel/\ OPT="-g -O2 -Ob2 -w1" ---------------------------- When compiled with fewer optimiztions, everything seems to work. ./configure --with-gcc=icc\ --with-cxx-main=icc\ --prefix=/int/apps/mmf/apps/Python-2.5_intel/\ OPT="-g -O1 -Ob2 -w1" ---------------------------------------------------------------------- >Comment By: Michael Forbes (mforbes) Date: 2007-03-29 22:06 Message: Logged In: YES user_id=253921 Originator: YES I have spoken with some people who have had similar issues with the intel compilers in other applications, so it looks like it might be a compiler bug. I will look into this. Can anyone confirm this behaviour? (I only have access to one linux box). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-28 11:32 Message: Logged In: YES user_id=21627 Originator: NO Can you debug this further to determine a specific problem? It could be a compiler bug also, for all I can tell. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689617&group_id=5470 From noreply at sourceforge.net Fri Mar 30 00:38:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Mar 2007 15:38:55 -0700 Subject: [ python-Bugs-705836 ] struct.pack of floats in non-native endian order Message-ID: Bugs item #705836, was opened at 2003-03-18 15:17 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705836&group_id=5470 Please note that this 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: Fixed Priority: 7 Private: No Submitted By: Richard Hill (richardh2003) Assigned to: Tim Peters (tim_one) Summary: struct.pack of floats in non-native endian order Initial Comment: Python version 2.1 (2.2.1 behaves the same). Windows 2000 and RH Linux 8.0 This was run on an Intel platform. >>> v = 7.0 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 >>> v 7.9999999999999964 >>> struct.pack( "f", v ) '\x00\x00\x00A' >>> struct.pack( ">f", v ) '@\x80\x00\x00' These two should be the same byte pattern (only reversed)! >>> struct.unpack( ">f", '@\x80\x00\x00' ) (4.0,) !!!!! ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-29 18:38 Message: Logged In: YES user_id=1344176 Originator: NO Reopening. The test case committed in r31892 is broken, specifically the part that checks for an OverflowError towards the end: the TestFailed exception is only instanced, never raised. Actually raising the TestFailed instance causes the test to fail. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-20 13:48 Message: Logged In: YES user_id=31435 Fixed. In the 2.2 branch: Lib/test/test_struct.py; new revision: 1.14.12.1 Misc/NEWS; new revision: 1.337.2.4.2.68 Modules/cPickle.c; new revision: 2.73.2.1.2.4 Modules/structmodule.c; new revision: 2.51.8.2 For 2.3: Lib/test/test_struct.py; new revision: 1.17 Misc/NEWS; new revision: 1.700 Modules/cPickle.c; new revision: 2.141 Modules/structmodule.c; new revision: 2.58 ---------------------------------------------------------------------- Comment By: Richard Hill (richardh2003) Date: 2003-03-20 07:33 Message: Logged In: YES user_id=737060 Thanks for getting back to me. Your comment regarding IEEE formats is very interesting, I didn't know about this behaviour. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-20 00:25 Message: Logged In: YES user_id=31435 Boosted priority because this is an especially bad kind of bug: mysterious, subtle, and very rare ("most" in-range floats pack under "<f" and ">f" without problems; a problem requires that a carry out of the 25th most-significant-bit propagate thru a solid string of 24 1 bits). For 2.2 I expect to check in a quick hack. In 2.3 this code needs refactoring (structmodule and cPickle shouldn't have duplicated this delicate code) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-19 14:01 Message: Logged In: YES user_id=31435 Yuck. It's a bug in not accounting for that rounding can spill over the original bit width. structmodule's pack_float() and pack_double() both have this flaw, although the one in pack_double() is much subtler. A similar cut-and-paste bug is in cPicke's save_float(). I'll fix all this. Note: while "<f"'s result should be the byte-reversal of ">f"'s, there's no defined relationship between either of those and plain "f". "f" is platform-native in all respects. "<f" and ">f" force an IEEE-like encoding, even on non-IEEE platforms. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705836&group_id=5470 From noreply at sourceforge.net Fri Mar 30 00:48:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Mar 2007 15:48:08 -0700 Subject: [ python-Bugs-1530559 ] struct.pack raises TypeError where it used to convert Message-ID: Bugs item #1530559, was opened at 2006-07-28 14:07 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530559&group_id=5470 Please note that this 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.5 >Status: Open >Resolution: None Priority: 9 Private: No Submitted By: Joe Wreschnig (piman) Assigned to: Bob Ippolito (etrepum) Summary: struct.pack raises TypeError where it used to convert Initial Comment: piman at toybox:~$ python2.4 -c "import struct; struct.pack('>H', 1.0)" piman at toybox:~$ python2.5 -c "import struct; struct.pack('>H', 1.0)" Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/struct.py", line 63, in pack return o.pack(*args) TypeError: unsupported operand type(s) for &: 'float' and 'long' This might have appeared as part of the struct optimizations; if struct isn't going to convert anymore for performance reasons, I think this should be mentioned in the release notes. Though personally I would prefer struct go back to converting its arguments. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-29 18:48 Message: Logged In: YES user_id=1344176 Originator: NO Reopening. The test case added in r51119 (specifically, test_1530559() and its infrastructure) doesn't work. The check_float_coerce() function is overwritten by a later assignment, meaning that test_1530559() calls the wrong function. Actually making it call the right check_float_coerce() function results in a NameError ("global name 'func' is not defined"). The reason the test currently passes is because check_float_coerce() is effectively an alias for deprecated_err(). test_1530559() passes deprecated_err() a string as its first argument; when deprecated_err() tries to call the string, a TypeError results. deprecated_err() traps the TypeError and so everything appears from the outside to have gone smoothly. If the test is tweaked so that struct.pack() is actually invoked with the proper arguments, it fails to raise the expected error on float coercion. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-11 00:27 Message: Logged In: YES user_id=33168 This patch (or some variant) was checked in as 51119 ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2006-08-02 22:10 Message: Logged In: YES user_id=139309 I've attached a patch which should resolve this issue. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-28 23:21 Message: Logged In: YES user_id=33168 I'd like to see a deprecation warning so old code continues to work. struct is way to loose and needs to be tightened up, but that might not fully happen until py3k. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-28 15:44 Message: Logged In: YES user_id=849994 I think that's a question for python-dev. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2006-07-28 15:31 Message: Logged In: YES user_id=139309 That wasn't really intentional, but the old behavior looks a bit suspect: $ python2.4 -c "import struct; print repr(struct.pack('>H', 1.6))" '\x00\x01' We could change it to check for floats and do a DeprecationWarning? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-28 14:51 Message: Logged In: YES user_id=849994 Bob? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530559&group_id=5470 From noreply at sourceforge.net Fri Mar 30 04:59:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Mar 2007 19:59:03 -0700 Subject: [ python-Bugs-1690840 ] xmlrpclib methods submit call on __str__, __repr__ Message-ID: Bugs item #1690840, was opened at 2007-03-29 15:14 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690840&group_id=5470 Please note that this 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 Private: No Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib methods submit call on __str__, __repr__ Initial Comment: Notice how trying to print a method causes it to submit the call: Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from xmlrpclib import ServerProxy >>> s = ServerProxy("http://google.com") >>> print s.somecall Traceback (most recent call last): File "", line 1, in File "c:\python25\lib\xmlrpclib.py", line 1147, in __call__ return self.__send(self.__name, args) File "c:\python25\lib\xmlrpclib.py", line 1437, in __request verbose=self.__verbose File "c:\python25\lib\xmlrpclib.py", line 1191, in request headers xmlrpclib.ProtocolError: >> f = s.somecall >>> locals() {'f': Traceback (most recent call last): File "", line 1, in File "c:\python25\lib\xmlrpclib.py", line 1147, in __call__ return self.__send(self.__name, args) File "c:\python25\lib\xmlrpclib.py", line 1437, in __request verbose=self.__verbose File "c:\python25\lib\xmlrpclib.py", line 1191, in request headers xmlrpclib.ProtocolError: ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-29 22:59 Message: Logged In: YES user_id=1344176 Originator: NO What would you rather seem them print? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690840&group_id=5470 From noreply at sourceforge.net Fri Mar 30 05:03:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Mar 2007 20:03:11 -0700 Subject: [ python-Bugs-1682403 ] docutils clarification request for "rest" Message-ID: Bugs item #1682403, was opened at 2007-03-16 15:58 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682403&group_id=5470 Please note that this 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: 3 Private: No Submitted By: j vickroy (jvickroy) >Assigned to: Martin v. L?wis (loewis) Summary: docutils clarification request for "rest" Initial Comment: >From the definition of long_description: *'long string'* Multiple lines of plain text in reStructuredText format (see http://docutils.sf.net/). in: http://docs.python.org/dist/meta-data.html I incorrectly concluded that the the bdist_wininst installer would provide visual markup for long_description specified in restructured text. According to Thomas Heller, that is not the case. I wish to suggest adding this clarification to the distutils documentation perhaps in one or both of the following documents: http://docs.python.org/dist/postinstallation-script.html http://docs.python.org/dist/meta-data.html Thanks, -- jv ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-29 23:03 Message: Logged In: YES user_id=1344176 Originator: NO Martin, you handle a lot of the Windows-related code, right? Thoughts on this? ---------------------------------------------------------------------- Comment By: j vickroy (jvickroy) Date: 2007-03-29 10:26 Message: Logged In: YES user_id=17213 Originator: YES I expected bold font when using "**" markers, list bullets when using "*" and "-" markers, etc. in the long_description text definition. Unfortunately, all of these markers are simply passed through unprocessed in the long description text that appears in the opening window when running the generated binary installer. Does this help clarify the issue? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-28 19:46 Message: Logged In: YES user_id=1344176 Originator: NO I'm not quite sure what the problem is. What kind of "visual markup" did you expect? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682403&group_id=5470 From noreply at sourceforge.net Fri Mar 30 05:24:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Mar 2007 20:24:19 -0700 Subject: [ python-Bugs-1688274 ] Python/C PyClass_* are not documented Message-ID: Bugs item #1688274, was opened at 2007-03-26 07:24 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1688274&group_id=5470 Please note that this 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 Private: No Submitted By: Tommi Vainikainen (tvainika) Assigned to: Nobody/Anonymous (nobody) Summary: Python/C PyClass_* are not documented Initial Comment: Python/C API Reference Manual chapter 7.5 Other Objects does not contain subchapter for Class objects, but only Instance objects and many other are documented there. >From header I can find that at least PyClass_Check and PyClass_New exist, I just don't know what those do until I take time to read source code... :( ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-29 23:24 Message: Logged In: YES user_id=1344176 Originator: NO Take a look at the attached patch and see if that says what you want. File Added: concrete.tex.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1688274&group_id=5470 From noreply at sourceforge.net Fri Mar 30 08:29:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Mar 2007 23:29:22 -0700 Subject: [ python-Bugs-1686475 ] os.stat() WindowsError 13 when file in use Message-ID: Bugs item #1686475, was opened at 2007-03-23 03:31 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686475&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: d roberts (dcroberts) Assigned to: Martin v. L?wis (loewis) Summary: os.stat() WindowsError 13 when file in use Initial Comment: Using 2.5 Sept 19, 2006 on Windows XP, 32-bit. os.stat() on an "in use" file (i.e., open by another process) erroneously returns WindowsError [Error 13]. The file stats should be available on an open file, even if you cannot read/write the file itself. Python 2.4 correctly returns the stats on the file. ---------------- CORRECT in 2.4: Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32 >>> import os >>> os.stat('c:\\hiberfil.sys') (33206, 0L, 2, 1, 0, 0, 804311040L, 1173962381, 1173962381, 1069302780) ----------------- ERROR in 2.5: Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 >>> import os >>> os.stat("c:\\hiberfil.sys") Traceback (most recent call last): File "", line 1, in WindowsError: [Error 13] The process cannot access the file because it is being used by another process: 'c:\\hiberfil.sys' ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-30 08:29 Message: Logged In: YES user_id=21627 Originator: NO Attached is a patch that makes it fall back to FindFirstFile if GetFileAttributesEx fail with ERROR_SHARING_VIOLATION. File Added: stat.diff ---------------------------------------------------------------------- Comment By: d roberts (dcroberts) Date: 2007-03-23 18:49 Message: Logged In: YES user_id=1750755 Originator: YES Taking your hint, I just looked at the code in 42230 which uses the Win32 GetFileAttributesEx() function. This function does indeed return an error for an in-use file. Not sure if this is a "feature" or "bug" in the underlying Windows function. I did try FindFirstFile(), which is able to return info on an in-use file. Not sure if this is a reasonable alternative to GFAE(), but wanted to make folks aware of the possibility. It's probably slower, since it can handle wild-cards, and returns a handle for subsequent calls to FindNextFile(). The handle must be closed with FindClose(). I'm not sure what underlying mechanism FindFirstFile() uses, but I'm assuming it accesses the "directory" to get its information, rather than trying to access the file itself. FWIW. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-23 11:24 Message: Logged In: YES user_id=21627 Originator: NO It certainly is; Python is likely opening the file in the wrong mode now. I'll investigate, although contributions would be welcome. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-23 11:15 Message: Logged In: YES user_id=849994 Originator: NO May this be related to rev. 42230 - "Drop C library for stat/fstat on Windows." ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686475&group_id=5470 From noreply at sourceforge.net Fri Mar 30 09:11:24 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Mar 2007 00:11:24 -0700 Subject: [ python-Feature Requests-1465406 ] Allowing the definition of constants Message-ID: Feature Requests item #1465406, was opened at 2006-04-05 19:30 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1465406&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Chris Wilson (ciw42) Assigned to: Nobody/Anonymous (nobody) Summary: Allowing the definition of constants Initial Comment: One of the current optimizations due in v2.5 includes constant folding of expressions, which as it stands serves as a way of somply getting rid of a redundant arithmetic operations and the like. In practice, it's rare a developer would leave an expression such as "2+3" sat in his/her code, but by allowing the declaration of constants within a script, it could make this new feature *much* more useful. As an example, in a recent script I had the following at the top, outside the main loop: SCREEN_WIDTH=640 SCREEN_HEIGHT=480 SCREEN_RATIO=SCREEN_WIDTH/SCREEN_HEIGHT As SCREEN_RATIO is used a number of times during my main loop, it makes sense to pre-calculate it to avoid the extra processing, but if the compiler were aware that SCREEN_WIDTH and SCREEN_HEIGHT were constants, it could optimise out the calculation and I could include the calculation in-place. I frequently make use of "constants" to make my code more readable, and wonder whether there is any performance penalty or lack of optimisation going on due to them in fact being regular variables? ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-30 03:11 Message: Logged In: YES user_id=1344176 Originator: NO The PEP Raymond mentioned hasn't been written (to Google's knowledge), and I can't see much support for it even if it were to be written. The performance benefits from a "const" keyword would in my view be minimal and not worth adding the necessary complication to the compiler. Closing. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-05-09 00:51 Message: Logged In: YES user_id=80475 Introducing a new keyword, "const", requires a PEP. Such a PEP should be backed-up by timings that demonstrate performance improvements impressive enough to warrant a change. In my experience, replacing global lookups with constants almost never produces much a speed-up in real code. If you write a PEP, it needs to first go through discussion on comp.lang.python. Also, you should find out how this would affect Jython and IronPython. ---------------------------------------------------------------------- Comment By: Chris Wilson (ciw42) Date: 2006-04-28 09:38 Message: Logged In: YES user_id=1018283 I see your point, and it's a good example of why using namespaces is so important, but in practice, with my proposal in place, the code you propose simply wouldn't compile. Assuming the compiler simply substituted the literal "3.1415" for "pi" as I've proposed, you'd end up with "3.1415 = 4", and a syntax error for trying to assign to a literal value. You'd not get as far as running the code, so in practice there'd be no issues with it running incorrectly. Being able to declare constants is important as it allows the compiler to make the sort of optimistations I mentioned previously. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-10 09:55 Message: Logged In: YES user_id=21627 The problem is that declaring the value assignment const doesn't help. Consider this: from math import pi def area(r): return r*r*pi pi = 4 print area(10) So even though math.pi might be declared as a constant, hard-coding its value into the function area would break this program - the value of the variable pi might change not change inside math, but it might change where it is imported. ---------------------------------------------------------------------- Comment By: Chris Wilson (ciw42) Date: 2006-04-06 17:59 Message: Logged In: YES user_id=1018283 I've re-opened this, as I don't feel it would be difficult to implement or require any fundamental changes to the parser or runtime. In fact, it would be very easy, and potentially very useful beyond the scope of my initial suggestion. Appologies to rhettinger if this seems rude, but I would ask that you give the following some consideration. The addition of a "const" or similar compiler directive would allow the compiler to simply do an on-the-fly substitution for the specified value/string etc. There would be no code analysis required, and adding this type of functionality would carry no real overheads or further complicate the compilation process. There would be no changes required within the runtime. Once substituted, the already incorporated compiler constant folding features would then come into play. I suppose, that what I'm suggesting is effectively a basic pre-compiler macro feature. This in itself may prove useful in many other situations. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-04-05 19:57 Message: Logged In: YES user_id=80475 Python is too dynamic for this kind of optimization to be done automatically. If those "constants" are defined at the module level, they can be changed by code outside the module. Even within the module, it would take a thorough analysis of the code to determine that nothing was trying to alter the value of the global variable. If the "constant" is defined inside a function, it is still a local variable subject to change by later lines in function. Your best bet is to use the bind_consts recipe at ASPN. It will automatically turn some global references into locals: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/277 940 It may be possible to adapt the recipe to go an additional step and fold the globals "constants". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1465406&group_id=5470 From noreply at sourceforge.net Fri Mar 30 09:20:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Mar 2007 00:20:31 -0700 Subject: [ python-Feature Requests-1322308 ] itemgetter built-in? Message-ID: Feature Requests item #1322308, was opened at 2005-10-10 05:56 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1322308&group_id=5470 Please note that this 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 Private: No Submitted By: capnSTABN (capnstabn) Assigned to: Nobody/Anonymous (nobody) Summary: itemgetter built-in? Initial Comment: uhm... operator.itemgetter() is useful and all, but fairly retarded looking for how simple it is basically what i am wrestling with at the moment is doing some regular expressions without completely ganking the crap out of the code to make it work, since every freakin thing in re returns None all over the bloody place like regular expressions were hitting a ragging pinata with a chainsaw after a LOT of muckymuck, basically six hours straight, the simplest non-conditional form i could come up with was this: http://42.vg/81691 http://42.vg/81691 any comments would be leet! ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-30 03:20 Message: Logged In: YES user_id=1344176 Originator: NO None of the links provided work anymore, and I have no idea what is being proposed (save for Raymond's comment). If the goal is to clarify the code snippet supplied by the OP, I agree with Raymond: learn to use "if" statements. Closing as "invalid". ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-14 07:19 Message: Logged In: YES user_id=80475 The use case is common enough to warrant further exploration. Essentially what is being requested is a straight-forward way to get a group dictionary that only includes matching groups. Two approaches come to mind. 1. Add a module constant, EXCLUDE, that when used as the default value causes non-matching groups to be excluded from the group dictionary: d=mo.groupdict(re.EXCLUDE) 2. Create a new flag, N or NODEFAULT or (?N), indicating that match objects should only include matching groups and not create default entries for non-matches: d=match('(?\w+)|(?\d+)', s, NODEFAULT).groupdict() FWIW, am not sympathetic to the OP's code fragment not being explicit. That is what happens when trying too hard to avoid using an if-statement. The fragment is much clearer without filtering: for type, string_ in mo.groupdict().iteritems(): if string_ is not None: . . . ---------------------------------------------------------------------- Comment By: capnSTABN (capnstabn) Date: 2005-10-11 05:33 Message: Logged In: YES user_id=1126596 ok to be more specific, as maybe that will help, line 17 in the code: for type, string_ in (filter(itemgetter(1), match.groupdict ().iteritems())): is about as implicit as pulling a tooth to remove a strand of celery the problem is that when using a single expansive recursive regular expression (which can translate an entire page of HTML like in any WikiWiki system in microseconds) that the amount of recursive calls because of all of the Nones flying around gets ludicrous a bit of a glimpse of a considerably more complex example: http://generic-host.us/~kevin/display_renderer.png please bear in mind that example is from 1999 or so ---------------------------------------------------------------------- Comment By: capnSTABN (capnstabn) Date: 2005-10-11 05:17 Message: Logged In: YES user_id=1126596 my request for enhancement is either a built-in version of operation.itemgetter() or an alteration of the behavior of re matches, i'm assuming the matter is up for debate so i wasn't being specific. this issue has nothing to do with showing code and i find your followup to be completely off topic! ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-10-10 12:57 Message: Logged In: YES user_id=1188172 Please tell us what your request for enhancement is or I'm going to close this as Invalid. Sorry I'm not showing more respect for your writing abilities :-), but if you want to show code around, do it on comp.lang.python please. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1322308&group_id=5470 From noreply at sourceforge.net Fri Mar 30 09:21:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Mar 2007 00:21:50 -0700 Subject: [ python-Feature Requests-1309676 ] Add os.path.relpath Message-ID: Feature Requests item #1309676, was opened at 2005-09-30 14:38 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1309676&group_id=5470 Please note that this 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: Accepted Priority: 5 Private: No Submitted By: Georg Brandl (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: Add os.path.relpath Initial Comment: Add a method to os.path which calculates the "difference" of two paths. See this python-dev thread for details and sample implementations: http://mail.python.org/pipermail/python-dev/2005-September/056391.html ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-30 03:21 Message: Logged In: YES user_id=1344176 Originator: NO Applied rbarran's patch as r54419. ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-10-27 14:33 Message: Logged In: YES user_id=1207189 Hi, Submitted a patch #1339796 to add this function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1309676&group_id=5470 From noreply at sourceforge.net Fri Mar 30 09:23:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Mar 2007 00:23:57 -0700 Subject: [ python-Feature Requests-1177998 ] Add a settimeout to ftplib.FTP object Message-ID: Feature Requests item #1177998, was opened at 2005-04-06 14:52 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1177998&group_id=5470 Please note that this 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 Private: No Submitted By: Juan Antonio Vali?o Garc?a (juanval) >Assigned to: Facundo Batista (facundobatista) Summary: Add a settimeout to ftplib.FTP object Initial Comment: It will be usefull that the FTP object of ftplib had a settimeout method to setup a timeout for the connection, because the only way of doing this is to use the socket.setdefaulttimeout method, and this is very dangerous when you are using threads. Thanks and keep up the work ! ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-30 03:23 Message: Logged In: YES user_id=1344176 Originator: NO Facundo, I believe you're doing something along these lines, right? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1177998&group_id=5470 From noreply at sourceforge.net Fri Mar 30 09:29:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Mar 2007 00:29:47 -0700 Subject: [ python-Feature Requests-1110010 ] 'attrmap' function, attrmap(x)['attname'] == x.attname Message-ID: Feature Requests item #1110010, was opened at 2005-01-26 11:28 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1110010&group_id=5470 Please note that this 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: Rejected Priority: 5 Private: No Submitted By: Gregory Smith (gregsmith) Assigned to: Nobody/Anonymous (nobody) Summary: 'attrmap' function, attrmap(x)['attname'] == x.attname Initial Comment: One of the side effects of the new-style classes is that objects don't necessarily have __dict__ attached to them. It used to be possible to write things like def __str__(self): return "Node %(name)s, %(nlinks)d links, active: %(active)s" % self.__dict__ ... but this doesn't work if the class doesn't have a __dict__. Even if does, I'm not sure it will always get members from base classes. There is a 'vars' function; you could put 'vars(self)' in the above instead of self.__dict__, but it still doesn't work if the class doesn't have a __dict__. I can see different solutions for this: (1) change the 'string %' operator so that it allows %(.name)s, leading to a getattr() on the right-side argument rather than a getitem. return "Node %(.name)s, %(.nlinks)d links, active: %(.active)s" % self (2) Make a builtin like vars, but which works when the object doesn't have a __dict__ I.e. attrmap(x) would return a mapping which is bound to x, and reading attrmap(x)['attname'] is the same as getattr(x,'attname'). Thus return "Node %(name)s, %(nlinks)d links, active: %(active)s" % attrmap(self) This attrmap() function can be implemented in pure python, of course. I originally thought (1) made a lot of sense, but (2) seems to work just as well and doesn't require changing much. Also, (1) allows cases like "%(name)s %(.name2)s", which are not very useful, but are very likely to be created by accident; whereas in (2) you are deciding on the right of the '%' whether you are naming attributes or providing mapping keys. I'm not sure it's a good idea change 'vars' to have this behaviour, since vars(x).keys() currently works in a predictable way when vars(x) works; whereas attrmap(x).keys() may not be complete, or possible, even when attrmap(x) is useful. I.e. when x has a __getattr__ defined. On the other hand, vars(x) doesn't currently do much at all, so maybe it's possible to enhance it like this without breaking anything. The motivation for this came from the "%(name)s" issue, but the attrmap() function would be useful in other places e.g. processdata( infile, outfile, **attrmap(options)) ... where options might be obtained from optparse, e.g. Or, an attrmap can be used with the new Templates: string.Template('Node $name').substitute( attrmap(node)) Both of these examples will work with vars(), but only when the object actually has __dict__. This is why I'm thinking it may make sense to enhance vars: some code may be broken by the change; but other code, broken by new-style classes, may be unbroken by this change. The proxy could be writable, so that attrmap(x)['a'] = y is the same as x.a = y .. which could have more uses. A possible useful (possibly weird) variation: attrmap accepts 1 or more parameters, and the resulting proxy is bound to all of them. when attrmap(x,y,z)['a'] is done, the proxy will try x.a, y.a, z.a until one of them doesn't raise AttributeError. So it's equivalent to merging dictionaries. This would be useful in the %(name)s or Template cases, where you want information from several objects. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-30 03:29 Message: Logged In: YES user_id=1344176 Originator: NO Closing due to lack of support. If you're still interested in an operator.attrmap() function, please try and work up a patch to Modules/operator.c and resubmit. ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2006-05-07 11:27 Message: Logged In: YES user_id=292741 I can't disagree with that -- one of the things I like about python is that simple funcs I use fairly often can usually be retyped out of my head in less time than it takes to find them and copy them from another software project- and more importantly, there's basically no risk that the fresh one will be buggy, if it's expression is simple and clear. So, the overhead of maintaining a zillion 'standard' utility funcs outweighs the cost of having to recode them instead, when they are small and simple. This applies as much to the core library as it does to a site-specific library. I do prefer if they have the same names each time I use them though, since it makes it easier to transplant higher-level chunks of code from one program to another. When I ran across this issue and its solution, I figured it would be something that, if available, could be used often enough to justify have a standard name. But I agree now it shouldn't be a builtin; having it as operator.attrmap still means you can copy code using it from one application to another without having to hunt down where 'attrmap' got implemented. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-05-05 02:28 Message: Logged In: YES user_id=341410 As I and others have expressed perhaps hundreds of times over the last few years; not all X line functions/classes should be built into Python. This particular object doesn't have enough general usefulness to make it into Python as a builtin, so you would need to import something anyways. If you are going to need to import to get at it, you may as well put this somewhere, and perhaps monkey-patch __builtins__ yourself so that you can get at it everywhere without importing it. Heck, you could even put it into site.py . If this were going to make it into Python, I would suggest it go into the operator module, where a similar feature already exists in the operator.attrgetter. If there is also desire, one may want to offer mapattr class which does x.attr -> x['attr'] . All in all, I'm -0; it would be useful, but I believe most people would just write the 5-liner and call it good. ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2006-05-04 11:19 Message: Logged In: YES user_id=292741 Josiah, I'm well aware of that, but as I said 10/26 I don't want to add attribute mapping to a whole set of classes just so they will all work a certain way in one specific situation; I want a separate adapter so I can have attribute mapping for ANY object in that specific situation. I can't mixin a new base class into every class I might encounter, since most of them are not under my control; but all of them have an attribute interface and will all work with attrmap. There's no reason to mess things up like that when I can implement attrmap already (and have done) -- and you have shown how short the code is on your 6/26/'05 post -- I'm just suggesting this is simple, elegant, and generally useful enough to be included as a standard python gizmo. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-10-27 02:16 Message: Logged In: YES user_id=341410 gregsmith: class attrmap: def __getitem__(self, key): return getattr(self, key) Use that as a mixin with any class you want to offer attribute mapping support to. As in... class foo(..., attrmap): ... Now your class has attribute mapping support. Amazing! As for the neatness of __dict__, I have used it before, but when I need to rely on using __dict__, I make sure my object has one (generally by not creating or using __slots__). ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2005-10-26 14:14 Message: Logged In: YES user_id=292741 To josiahcarlson: Yes, I can add __getitem__ to any class. But I don't see why I should make a whole bunch of classes act like dictionaries, only so that I can pass them to single API (like string.Template) which requires a dictionary. A class should have a dictionary behaviour if it makes sense for that class; if I have to add it specifically, and only, to make it work well in one particular situation, that's a kluge. If I have to add dict behaviour to a whole bunch of classes to make them all work in that one situation, that's a serious kluge. And entirely unintuitive, to borrow a phrase. When you encounter this situation, IMO, it's clear that a little 'pipe-fitting' like this is the best solution. Furthermore, and to underline the above, what if I have a class which already has a __getitem__ interface for it's own purposes? Chances are this behaves in a way which makes it useless for harvesting general attributes from the object; the object always has a getattr interface, however. Since ALL objects have a getattr interface, and there's a fair number of APIs that require objects with a read-only, string-keyed dict interface, why not have this universal pipe-fitting to tie them together, so as not to have to modify the objects and/or interfaces. To rhettinger: First off, what do you mean by 'use case'? I gave three examples of the use of the function, with %attrmap(x), string.Template(...).substitute(attrmap(x)); attrmap(options). I can expand these to more detail if you like. I didn't give use examples for the 'write' case; I haven't encountered a use for that. Yes, you have to think a bit before you see what it's for. That's arguably true for super(), slice() and operator.attrgetter() as well. Once you've run into the situation where it's useful, it becomes pretty clear what it's for. Given the general problem it solves, it's hard to imagine a neater and more intuitive solution IMO. Here's a 2-line sales pitch, which was implied, but not given, in the original post: def __str__(self): return "MyObj(name=%(name)s, n=%(n)d, links = %(links)d )" % attrmap(self) vs. the harder-to-maintain return "MyObj( name=%s, n=%d, links = %d )" % (self.name, self.n, self.links) ...this requires the programmer to maintain the same list of symbols twice, a burden which is very common in languages inferior to Python. And obviously it's very simple (the base functionality is 5 lines). Like attrgetter, It becomes more useful when it's always available in the standard lib, and a little faster if it happens to be in C. to loewis: fair enough, maybe it doesn't qualify for a builtin. But it might make more sense to do it as operator.attrmap rather than UserDict.AttrMap; it seems to fit into the same category as attrgettr and itemgetter. I wasn't aware of those two when I originally posted. And am I the only one who thinks the first example I gave (with __str__ using "..."%self.__dict__) is a pretty neat trick? And who has noticed it's been broken with new-style classes? That by itself, IMO, calls for a fix, and replacing self.__dict__ with attrmap(self) is a pretty simple fix. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-27 00:18 Message: Logged In: YES user_id=80475 -1 While potentially useful, the function is entirely unintuitive (it has to be studied a bit before being able to see what it is for). Also, the OP is short on use cases (none were presented). IMO, this belongs as a cookbook recipe. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-06-26 13:47 Message: Logged In: YES user_id=341410 An implementation of the base attrmap functionality (as suggested by Reinhold in his post in python-dev)... class attrmap: def __init__(self, obj): self.obj = obj def __getitem__(self, key): return getattr(self.obj, key) To Gregory Smith: If you merely add the __getitem__ method with a 'self' as the first argument of getattr, you don't even need attrmap. As an aside, when I want dictionary-like behavior from my classes, I use a dictionary or something that implements a subset of the mapping protocol. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-11 19:51 Message: Logged In: YES user_id=21627 I think I would rather not to see this as a builtin, e.g. putting it into UserDict.AttrMap instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1110010&group_id=5470 From noreply at sourceforge.net Fri Mar 30 09:58:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Mar 2007 00:58:38 -0700 Subject: [ python-Bugs-1688274 ] Python/C PyClass_* are not documented Message-ID: Bugs item #1688274, was opened at 2007-03-26 14:24 Message generated for change (Comment added) made by tvainika You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1688274&group_id=5470 Please note that this 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 Private: No Submitted By: Tommi Vainikainen (tvainika) Assigned to: Nobody/Anonymous (nobody) Summary: Python/C PyClass_* are not documented Initial Comment: Python/C API Reference Manual chapter 7.5 Other Objects does not contain subchapter for Class objects, but only Instance objects and many other are documented there. >From header I can find that at least PyClass_Check and PyClass_New exist, I just don't know what those do until I take time to read source code... :( ---------------------------------------------------------------------- >Comment By: Tommi Vainikainen (tvainika) Date: 2007-03-30 10:58 Message: Logged In: YES user_id=1753247 Originator: YES Looks good for me. Actually the first pointer to new-style classes is the most important I think... :) (which I found out by myself after reporting this bug) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-30 06:24 Message: Logged In: YES user_id=1344176 Originator: NO Take a look at the attached patch and see if that says what you want. File Added: concrete.tex.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1688274&group_id=5470 From noreply at sourceforge.net Fri Mar 30 13:44:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Mar 2007 04:44:04 -0700 Subject: [ python-Feature Requests-1634034 ] Show "expected" token on syntax error Message-ID: Feature Requests item #1634034, was opened at 2007-01-12 13:03 Message generated for change (Comment added) made by oliver_gramberg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1634034&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Oliver Gramberg (oliver_gramberg) Assigned to: Nobody/Anonymous (nobody) Summary: Show "expected" token on syntax error Initial Comment: I suggest that the parser, when reporting a syntax error, should make use of its knowlegde of which token type is expected at the position where the error occurred. This results in more helpful error messages: ----------------------------------------------------- >>> for a in (8,9) File "", line 1 for a in (8,9) ^ SyntaxError: invalid syntax - COLON expected ----------------------------------------------------- >>> for a in (8,9: print a, File "", line 1 for a in (8,9: print a, ^ SyntaxError: invalid syntax: RPAR expected ----------------------------------------------------- I tried the following patch (for pythonrun.c). It works well in the shell both interactively and in scripts, as well as in IDLE. But it's not complete: - It doesn't always print useful messages (only for fixed-size terminal token types, I assume.) - There sure are cases where more than one token type is allowed in a position. I believe I have seen that this information is available too somewhere in the parser, but it is not forwarded to the err_input routine. It's even nicer to show "')'" instead of "RPAR"... ----------------------------------------------------- /* Set the error appropriate to the given input error code (see errcode.h) */ static void err_input(perrdetail *err) { PyObject *v, *w, *errtype; PyObject* u = NULL; char *msg = NULL; errtype = PyExc_SyntaxError; switch (err->error) { case E_SYNTAX: errtype = PyExc_IndentationError; if (err->expected == INDENT) msg = "expected an indented block"; else if (err->token == INDENT) msg = "unexpected indent"; else if (err->token == DEDENT) msg = "unexpected unindent"; else { char buf[50]; errtype = PyExc_SyntaxError; if(err->expected != -1) { snprintf(buf, 48, "invalid syntax - %.16s expected\0", _PyParser_TokenNames[err->expected]); msg = buf; } else { msg = "invalid syntax"; } } break; ... ----------------------------------------------------- I am willing to help work on this. Regards -Oliver ---------------------------------------------------------------------- >Comment By: Oliver Gramberg (oliver_gramberg) Date: 2007-03-30 11:44 Message: Logged In: YES user_id=206204 Originator: YES Pfa a diff for my patch. Regards -Oliver File Added: pythonrun.patch ---------------------------------------------------------------------- Comment By: Sean Gillespie (sean_gillespie) Date: 2007-03-28 23:37 Message: Logged In: YES user_id=1744567 Originator: NO Your patch seems to work. I agree that showing the token (as in ")") would indeed be much more useful, and it would be pretty easy to implement. However, I think that you should generate a diff for your patch. Its incredibly hard to read over SF. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1634034&group_id=5470 From noreply at sourceforge.net Fri Mar 30 14:31:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Mar 2007 05:31:51 -0700 Subject: [ python-Bugs-1688274 ] Python/C PyClass_* are not documented Message-ID: Bugs item #1688274, was opened at 2007-03-26 14:24 Message generated for change (Comment added) made by tvainika You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1688274&group_id=5470 Please note that this 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 Private: No Submitted By: Tommi Vainikainen (tvainika) Assigned to: Nobody/Anonymous (nobody) Summary: Python/C PyClass_* are not documented Initial Comment: Python/C API Reference Manual chapter 7.5 Other Objects does not contain subchapter for Class objects, but only Instance objects and many other are documented there. >From header I can find that at least PyClass_Check and PyClass_New exist, I just don't know what those do until I take time to read source code... :( ---------------------------------------------------------------------- >Comment By: Tommi Vainikainen (tvainika) Date: 2007-03-30 15:31 Message: Logged In: YES user_id=1753247 Originator: YES Actually one more thing: I think that chapter 7.5.2 Instance Objects would need also similar note about being relevant only for old-style classes. (At least I think it is only relevant for old style classes.) ---------------------------------------------------------------------- Comment By: Tommi Vainikainen (tvainika) Date: 2007-03-30 10:58 Message: Logged In: YES user_id=1753247 Originator: YES Looks good for me. Actually the first pointer to new-style classes is the most important I think... :) (which I found out by myself after reporting this bug) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-30 06:24 Message: Logged In: YES user_id=1344176 Originator: NO Take a look at the attached patch and see if that says what you want. File Added: concrete.tex.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1688274&group_id=5470 From noreply at sourceforge.net Fri Mar 30 15:02:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Mar 2007 06:02:48 -0700 Subject: [ python-Feature Requests-1177998 ] Add a settimeout to ftplib.FTP object Message-ID: Feature Requests item #1177998, was opened at 2005-04-06 15:52 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1177998&group_id=5470 Please note that this 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: Accepted Priority: 5 Private: No Submitted By: Juan Antonio Vali?o Garc?a (juanval) Assigned to: Facundo Batista (facundobatista) Summary: Add a settimeout to ftplib.FTP object Initial Comment: It will be usefull that the FTP object of ftplib had a settimeout method to setup a timeout for the connection, because the only way of doing this is to use the socket.setdefaulttimeout method, and this is very dangerous when you are using threads. Thanks and keep up the work ! ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2007-03-30 10:02 Message: Logged In: YES user_id=752496 Originator: NO It's already in the trunk, you can do this: >>> ftp = ftplib.FTP("localhost", timeout=30) ... or ... >>> ftp = ftplib.FTP() >>> ftp.connect("localhost", timeout=30) ... or ... >>> ftp = ftplib.FTP(timeout=30) >>> ftp.connect("localhost") ... or ... >>> ftp = ftplib.FTP() >>> ftp.timeout = 30 >>> ftp.connect("localhost") :D Thanks Collin! ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-30 04:23 Message: Logged In: YES user_id=1344176 Originator: NO Facundo, I believe you're doing something along these lines, right? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1177998&group_id=5470 From noreply at sourceforge.net Fri Mar 30 16:02:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Mar 2007 07:02:49 -0700 Subject: [ python-Bugs-1688274 ] Python/C PyClass_* are not documented Message-ID: Bugs item #1688274, was opened at 2007-03-26 07:24 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1688274&group_id=5470 Please note that this 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.6 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Tommi Vainikainen (tvainika) Assigned to: Nobody/Anonymous (nobody) Summary: Python/C PyClass_* are not documented Initial Comment: Python/C API Reference Manual chapter 7.5 Other Objects does not contain subchapter for Class objects, but only Instance objects and many other are documented there. >From header I can find that at least PyClass_Check and PyClass_New exist, I just don't know what those do until I take time to read source code... :( ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-30 10:02 Message: Logged In: YES user_id=1344176 Originator: NO I'll add a note to the docs for instance objects. Fixed in r54614. Thanks, Tommi. ---------------------------------------------------------------------- Comment By: Tommi Vainikainen (tvainika) Date: 2007-03-30 08:31 Message: Logged In: YES user_id=1753247 Originator: YES Actually one more thing: I think that chapter 7.5.2 Instance Objects would need also similar note about being relevant only for old-style classes. (At least I think it is only relevant for old style classes.) ---------------------------------------------------------------------- Comment By: Tommi Vainikainen (tvainika) Date: 2007-03-30 03:58 Message: Logged In: YES user_id=1753247 Originator: YES Looks good for me. Actually the first pointer to new-style classes is the most important I think... :) (which I found out by myself after reporting this bug) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-29 23:24 Message: Logged In: YES user_id=1344176 Originator: NO Take a look at the attached patch and see if that says what you want. File Added: concrete.tex.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1688274&group_id=5470 From noreply at sourceforge.net Fri Mar 30 16:39:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Mar 2007 07:39:22 -0700 Subject: [ python-Feature Requests-1506171 ] Add "methodcaller" to the operator module Message-ID: Feature Requests item #1506171, was opened at 2006-06-14 12:02 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506171&group_id=5470 Please note that this 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: Rejected Priority: 5 Private: No Submitted By: Gregory Petrosyan (gregory_p) Assigned to: Nobody/Anonymous (nobody) Summary: Add "methodcaller" to the operator module Initial Comment: I found that I (like Alex Martelli, http://mail.python. org/pipermail/python-dev/2006-February/060341.html :-) am writing lambdas like "lambda x: x.do_smth(a,b,c)" a lot (often for filter/map functions). So, I think it would be great to have such a function implemented in C and placed in the standart library. Operator module can be a good place for it. -- Regards, Gregory. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-30 10:39 Message: Logged In: YES user_id=1344176 Originator: NO Guido has stated that lambda will not be removed in Python 3000 (see PEP 3099), so I can't see the need for a HOF to avoid lambda-usage, especially when the lambda expression is shorter/clearer: operator.methodcaller('method', x, y, z) lambda x: x.method(x, y, z) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506171&group_id=5470 From noreply at sourceforge.net Fri Mar 30 16:40:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Mar 2007 07:40:47 -0700 Subject: [ python-Feature Requests-1612190 ] Py_DEBUG Message-ID: Feature Requests item #1612190, was opened at 2006-12-09 10:48 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1612190&group_id=5470 Please note that this 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 Private: No Submitted By: nitro (nitrogenycs) Assigned to: Nobody/Anonymous (nobody) Summary: Py_DEBUG Initial Comment: Hello, I am writing an extension module (Win32, VC8). Of course I need to #include . Now, when _DEBUG is defined in my application Py_DEBUG gets defined as well (in pyconfig.h). I don't want this to happen as I have to link to the python debug library that way. However, I don't want to debug python, I only want to debug my own application. So the automatic definition of Py_DEBUG doesn't seem right. A solution that would be backwards compatible could look like: #ifdef _DEBUG && !defined(Py_NO_DEBUG) # define Py_DEBUG #endif Could something like this be included in python? Note that #undef _DEBUG #include #define _DEBUG does not work as VC8 complains in this case, because some header files had the _DEBUG preprocessor symbol and some didn't. That trick used to work in VC 6 and 7.x. I've seen a lot of people fighting this problem. Another problem that also arises from pyconfig.h is this code: # ifdef _DEBUG # pragma comment(lib,"python24_d.lib") # else I don't think it's clean that python tells my program what to link to. I am the one who should (and wants to) do this via a linker switch. I know that some people probably would regard the code above as a feature, but it's the opposite imo. A backwards compatible change could look like: #ifdef MS_COREDLL # ifndef Py_BUILD_CORE /* not building the core - must be an ext */ # if defined(_MSC_VER) && !defined(Py_NO_AUTOMATIC_MSVC_LINK) /* So MSVC users need not specify the .lib file in their Makefile (other compilers are generally taken care of by distutils.) */ # ifdef _DEBUG # pragma comment(lib,"python24_d.lib") # else # pragma comment(lib,"python24.lib") # endif /* _DEBUG */ # endif /* _MSC_VER */ # endif /* Py_BUILD_CORE */ #endif /* MS_COREDLL */ Thanks, -Matthias ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-30 10:40 Message: Logged In: YES user_id=1344176 Originator: NO Closing per Martin's comment. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-11 14:09 Message: Logged In: YES user_id=21627 Originator: NO You should just not define _DEBUG then. You don't need to define _DEBUG to perform debugging; instead, _DEBUG requests that the debug version of the MS CRT is linked to your application. As mixing different CRTs (e.g. debug and non-debug) in a single application can cause crashes, you *must* use a python2x.dll that is linked with the debug CRT; this will be python2x_d.dll. So no, something like this should not be added to Python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1612190&group_id=5470 From noreply at sourceforge.net Fri Mar 30 16:50:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Mar 2007 07:50:12 -0700 Subject: [ python-Feature Requests-815563 ] bug with ill-formed rfc822 attachments Message-ID: Feature Requests item #815563, was opened at 2003-09-30 22:32 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=815563&group_id=5470 Please note that this 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: Fixed Priority: 5 Private: No Submitted By: Stuart D. Gathman (customdesigned) Assigned to: Nobody/Anonymous (nobody) Summary: bug with ill-formed rfc822 attachments Initial Comment: The following proglet gets an except with the attached message: -----te.py-------- import email import sys msg = email.message_from_file(sys.stdin) sys.stdout.write(msg.as_string()) ------------------ python2 te.py <failingmsg Traceback (most recent call last): File "te.py", line 4, in ? msg = email.message_from_file(sys.stdin) File "/usr/lib/python2.2/email/__init__.py", line 63, in message_from_file return Parser(_class, strict=strict).parse(fp) File "/usr/lib/python2.2/email/Parser.py", line 64, in parse self._parsebody(root, fp, firstbodyline) File "/usr/lib/python2.2/email/Parser.py", line 239, in _parsebody msgobj = self.parsestr(part) File "/usr/lib/python2.2/email/Parser.py", line 75, in parsestr return self.parse(StringIO(text), headersonly=headersonly) File "/usr/lib/python2.2/email/Parser.py", line 64, in parse self._parsebody(root, fp, firstbodyline) File "/usr/lib/python2.2/email/Parser.py", line 264, in _parsebody msg = self.parse(fp) File "/usr/lib/python2.2/email/Parser.py", line 64, in parse self._parsebody(root, fp, firstbodyline) File "/usr/lib/python2.2/email/Parser.py", line 205, in _parsebody raise Errors.BoundaryError( email.Errors.BoundaryError: No terminating boundary and no trailing empty line ------------------- The message/rfc822 attachment really is missing the boundary. However, that is why it is being returned as an attachment in the first place! Is it illegal for message/rfc822 attachments to have invalid MIME construction? I suggest that a message attachment that fails MIME boundary decoding, should become a plain rfc822 object, or perhaps a text object. I don't know. Anyway, I get tons of messages with this property that have to be processed by my Python milter. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-30 10:50 Message: Logged In: YES user_id=1344176 Originator: NO I don't see any exception as of Python 2.5. Closing as "fixed". ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-21 16:00 Message: Logged In: YES user_id=12800 Note that if you're looking for something that just parses messages into headers and bodies, you might look at the HeaderParser class. You'd have to write a bit of code to get an outer parser that falls back to a HeaderParser on invalid unparseable inner messages. ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-11-21 15:52 Message: Logged In: YES user_id=142072 Your disposition makes sense. Since all messages with invalid MIME boundaries are either invalid themselves, or bounces or forwards of invalid messages, my work around is to issue an SMTP reject: if exc_type == email.Errors.BoundaryError: self.setreply('554','5.7.7', 'Boundary error in your message, are you a spammer?') For 2.4, I recommend that rfc822 attachments be parsed independently of the enclosing message. If the attachment is invalid, turn it into a plain rfc822 message object or a string. Although the rfc822 module is deprecated, I find it very useful to represent mail that may or may not correctly follow MIME standards. Examples include forwarded spam (using the new innoculation RFC), and generic mailbox processing. I suggest retaining rfc822 as a 'featureless' message with only headers and body. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-21 15:36 Message: Logged In: YES user_id=12800 I'm moving this to a feature request for Python 2.4. There's little that we can do about this in Python 2.3 since the lax parser is only so good at guessing the intent of ill-formed messages. email 2.x can't do what you suggest because that would be a new feature and can't be introduced into Python 2.3. The email-sig is chartered with developing an improved parser for Python 2.4 that might be able to handle this. In the meantime, you could probably derive your own Parser class that might be able to worm around this problem in an application specific way. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=815563&group_id=5470 From noreply at sourceforge.net Fri Mar 30 16:58:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Mar 2007 07:58:14 -0700 Subject: [ python-Feature Requests-795081 ] email.Message param parsing problem II Message-ID: Feature Requests item #795081, was opened at 2003-08-25 23:37 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=795081&group_id=5470 Please note that this 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 Private: No Submitted By: Stuart D. Gathman (customdesigned) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Message param parsing problem II Initial Comment: The enclosed real life (inactivated) virus message causes email.Message to fail to find the multipart attachments. This is because the headers following Content-Type are indented, causing email.Message to properly append them to Content-Type. The trick is that the boundary is quoted, and Outhouse^H^H^H^H^Hlook apparently gets a value of 'bound' for boundary, whereas email.Message gets the value '"bound"\n\tX-Priority...'. email.Utils.unqoute apparently gives up and doesn't remove any quotes. I believe that unqoute should return just what is between the quotes, so that '"abc" def' would be unquoted to 'abc'. In fact, my email filtering software (http://bmsi.com/python/milter.html) works correctly on all kinds of screwy mail using my version of unquote using this heuristic. I believe that header used by the virus is invalid, so a STRICT parser should reject it, but a tolerant parser (such as a virus scanner would use) should use the heuristic. Here is a brief script to show the problem (attached file in test/virus5): ----------t.py---------- import email msg = email.message_from_file(open('test/virus5','r')) print msg.get_params() --------------------- $ python2 t.py [('multipart/mixed', ''), ('boundary', '"bound"\n\tX-Priority: 3\n\tX-MSMail-Priority: Normal\n\tX-Mailer: Microsoft Outlook Express 5.50.4522.1300\n\tX-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1300')] ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-30 10:58 Message: Logged In: YES user_id=1344176 Originator: NO I'm still seeing this behaviour as of Python 2.6a0. Barry: I take it email-sig didn't get around to discussing this? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-21 15:45 Message: Logged In: YES user_id=12800 Moving this to feature requests for Python 2.4. If appropriate, the email-sig should address this in the intended new lax parser for email 3.0 / Python 2.4. We can't add this to the Python 2.3 (or earlier) maintenance releases. ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-08-25 23:57 Message: Logged In: YES user_id=142072 Here is a proposed fix for email.Util.unquote (except it should test for a 'strict' mode flag, which is current only in Parser): def unquote(str): """Remove quotes from a string.""" if len(str) > 1: if str.startswith('"'): if str.endswith('"'): str = str[1:-1] else: # remove garbage after trailing quote try: str = str[1:str[1:].index('"')+1] except: return str return str.replace('\\\\', '\\').replace('\\"', '"') if str.startswith('<') and str.endswith('>'): return str[1:-1] return str Actually, I replaced only email.Message._unquotevalue for my application to minimize the impact. That would also be a good place to check for a STRICT flag stored with the message object. Perhaps the Parser should set the Message _strict flag from its own _strict flag. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=795081&group_id=5470 From noreply at sourceforge.net Fri Mar 30 17:49:24 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Mar 2007 08:49:24 -0700 Subject: [ python-Feature Requests-1691387 ] Call sys.except_hook if exception occurs in __del__ Message-ID: Feature Requests item #1691387, was opened at 2007-03-30 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=355470&aid=1691387&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Ehresman (jpe) Assigned to: Nobody/Anonymous (nobody) Summary: Call sys.except_hook if exception occurs in __del__ Initial Comment: Is there a reason why sys.except_hook isn't called when __del__ returns with an exception? If not, I can write a patch to call sys.except_hook from PyErr_WriteUnraisable. The default of printing the full traceback should be possible in many situations. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1691387&group_id=5470 From noreply at sourceforge.net Fri Mar 30 18:08:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Mar 2007 09:08:03 -0700 Subject: [ python-Feature Requests-588825 ] unittest.py, better error message Message-ID: Feature Requests item #588825, was opened at 2002-07-30 18:29 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=588825&group_id=5470 Please note that this 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 Private: No Submitted By: Stefan Wehr (stefanheimann) >Assigned to: Collin Winter (collinwinter) Summary: unittest.py, better error message Initial Comment: These two methods of the class TestCase are not very good: def failUnlessEqual(self, first, second, msg=None): """Fail if the two objects are unequal as determined by the '!=' operator. """ if first != second: raise self.failureException, \ (msg or '%s != %s' % (`first`, `second`)) def failIfEqual(self, first, second, msg=None): """Fail if the two objects are equal as determined by the '==' operator. """ if first == second: raise self.failureException, \ (msg or '%s == %s' % (`first`, `second`)) The first thing is that you should print the difference of the given values like that: '<%s> == <%s>' % (`first`, `second`) The < and > delimits the string and so is is easier to detect where the string starts and where it ends. The second thing is that I would really like to see the two values that are (not) equal even if I provide a message. Maybe its better to raise the exception like that: if msg is not None: msg += ' Expected: <%s>, is: <%s>' % (first, second) raise self.failureException, \ (msg or '%s != %s' % (`first`, `second`)) bye Stefan ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-21 00:47 Message: Logged In: YES user_id=357491 I am making this an RFE since it is just a suggestion and not a bug. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-08-18 18:19 Message: Logged In: YES user_id=80475 Steve, would you like these implemented or left as is? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=588825&group_id=5470 From noreply at sourceforge.net Fri Mar 30 18:12:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Mar 2007 09:12:52 -0700 Subject: [ python-Bugs-1691411 ] Duplicate "preferences" menu item/Tk Aqua 8.4.14 Message-ID: Bugs item #1691411, was opened at 2007-03-30 11:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1691411&group_id=5470 Please note that this 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 Private: No Submitted By: Kevin Walzer (wordtech) Assigned to: Nobody/Anonymous (nobody) Summary: Duplicate "preferences" menu item/Tk Aqua 8.4.14 Initial Comment: Version 8.4.14 of Tcl/Tk Aqua (for OS X) hard-codes a "Preferences" item in the Apple menu. As a result, IDLE now has two "Preferences" items--the active one that is coded by default, and an inactive item that is hard-coded by Tk. The way to work around this is to check the version of Tk that is present, in this fashion: tkversion=Tkinter.Tk().tk.eval('info patchlevel') If it is 8.4.14 or greater, then you should bind IDLE's "preferences" dialog to the hard-coded menu item in Tk (and remove the "preferences" menu entry that comes with IDLE). It can be done in this fashion: Tkinter.Tk().createcommand('::tk::mac::ShowPreferences', IDLEpreferencesfunction) ##substitute the correction function name here If tkversion <= '8.4.13', leave things as they are. I have tried to put together a patch for this, but I'm not sure where the correct place to add this code is. I've looked at Bindings.py and macosxSupport.py, but it doesn't work as expected (in macosxSupport.py, it simply ignores the code; in Bindings.py, it removes IDLE's preferences item, but doesn't activate the hard-coded one). So I'm leaving this to someone with a greater knowledge of IDLE's internal structure to apply. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1691411&group_id=5470 From noreply at sourceforge.net Fri Mar 30 18:13:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Mar 2007 09:13:29 -0700 Subject: [ python-Feature Requests-478407 ] Need Windows os.link() support Message-ID: Feature Requests item #478407, was opened at 2001-11-05 14:34 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=478407&group_id=5470 Please note that this 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: Duplicate Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Need Windows os.link() support Initial Comment: NTFS has (always?) had hard link support. This functionality is now exposed in Win32 starting with Windows 2000 [see CreateHardLink()]. I've added Windows support to os.link(). I've tried to support FAT, NT, 95 by doing a CopyFile(). 2000 support is enabled by defining _WIN32_WINNT=0x500 in pythoncore.dsp. When this is done, the redundant #include <windows.h> in errnomodule.c gives compilation errors. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-30 12:13 Message: Logged In: YES user_id=1344176 Originator: NO This feature request has been superseded by #1578269, which includes several references on the subject. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 22:08 Message: Logged In: YES user_id=357491 If you would like this to actually be looked at it would be best to create a patch against CVS and upload a diff file instead of a zip file. ---------------------------------------------------------------------- Comment By: Michael Dubner (dubnerm) Date: 2003-01-18 00:49 Message: Logged In: YES user_id=39274 Also one can create os.symlink() and os.readlink() for all windows versions after 95 - using shell links (like cygwin do for symlink emulation). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-05 14:35 Message: Logged In: NO I think that I forgot to add my email address: bcox at semio.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=478407&group_id=5470 From noreply at sourceforge.net Fri Mar 30 18:46:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Mar 2007 09:46:19 -0700 Subject: [ python-Feature Requests-1506171 ] Add "methodcaller" to the operator module Message-ID: Feature Requests item #1506171, was opened at 2006-06-14 11:02 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506171&group_id=5470 Please note that this 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: Rejected Priority: 5 Private: No Submitted By: Gregory Petrosyan (gregory_p) Assigned to: Nobody/Anonymous (nobody) Summary: Add "methodcaller" to the operator module Initial Comment: I found that I (like Alex Martelli, http://mail.python. org/pipermail/python-dev/2006-February/060341.html :-) am writing lambdas like "lambda x: x.do_smth(a,b,c)" a lot (often for filter/map functions). So, I think it would be great to have such a function implemented in C and placed in the standart library. Operator module can be a good place for it. -- Regards, Gregory. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-03-30 11:46 Message: Logged In: YES user_id=80475 Originator: NO Re-opening. There are valid use cases for this request and there are some speed benefits to having a functional form. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-30 09:39 Message: Logged In: YES user_id=1344176 Originator: NO Guido has stated that lambda will not be removed in Python 3000 (see PEP 3099), so I can't see the need for a HOF to avoid lambda-usage, especially when the lambda expression is shorter/clearer: operator.methodcaller('method', x, y, z) lambda x: x.method(x, y, z) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506171&group_id=5470 From noreply at sourceforge.net Fri Mar 30 18:52:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Mar 2007 09:52:01 -0700 Subject: [ python-Feature Requests-588825 ] unittest.py, better error message Message-ID: Feature Requests item #588825, was opened at 2002-07-30 17:29 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=588825&group_id=5470 Please note that this 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 Private: No Submitted By: Stefan Wehr (stefanheimann) Assigned to: Collin Winter (collinwinter) Summary: unittest.py, better error message Initial Comment: These two methods of the class TestCase are not very good: def failUnlessEqual(self, first, second, msg=None): """Fail if the two objects are unequal as determined by the '!=' operator. """ if first != second: raise self.failureException, \ (msg or '%s != %s' % (`first`, `second`)) def failIfEqual(self, first, second, msg=None): """Fail if the two objects are equal as determined by the '==' operator. """ if first == second: raise self.failureException, \ (msg or '%s == %s' % (`first`, `second`)) The first thing is that you should print the difference of the given values like that: '<%s> == <%s>' % (`first`, `second`) The < and > delimits the string and so is is easier to detect where the string starts and where it ends. The second thing is that I would really like to see the two values that are (not) equal even if I provide a message. Maybe its better to raise the exception like that: if msg is not None: msg += ' Expected: <%s>, is: <%s>' % (first, second) raise self.failureException, \ (msg or '%s != %s' % (`first`, `second`)) bye Stefan ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-03-30 11:52 Message: Logged In: YES user_id=80475 Originator: NO Collin, you should probably solicit Steve Purcell's input before proceeding with the one. The request seems reasonable but the module author should have some say in the matter. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-20 23:47 Message: Logged In: YES user_id=357491 I am making this an RFE since it is just a suggestion and not a bug. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-08-18 17:19 Message: Logged In: YES user_id=80475 Steve, would you like these implemented or left as is? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=588825&group_id=5470 From noreply at sourceforge.net Fri Mar 30 19:22:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Mar 2007 10:22:12 -0700 Subject: [ python-Bugs-1685000 ] DoS asyncore vulnerability Message-ID: Bugs item #1685000, was opened at 2007-03-21 02:15 Message generated for change (Comment added) made by rushing You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685000&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: billiejoex (billiejoex) Assigned to: Nobody/Anonymous (nobody) Summary: DoS asyncore vulnerability Initial Comment: DoS asyncore vulnerability asyncore, independently if used with select() or poll(), suffers a DoS-type vulnerability when a high number of simultaneous connections to handle simultaneously is reached. The number of maximum connections is system-dependent as well as the type of error raised. I attached two simple Proof of Concept scripts demonstrating such bug. If you want to try the behaviours listed below run the attached "asyncore_server.py" and "asyncore_client.py" scripts on your local workstation. On my Windows XP system (Python 2.5), independently if asyncore has been used to develop a server or a client, the error is raised by select() inside asyncore's "poll" function when 512 (socket_map's elements) simultaneous connections are reached. Here's the traceback I get: [...] connections: 510 connections: 511 connections: 512 Traceback (most recent call last): File "C:\scripts\asyncore_server.py", line 38, in asyncore.loop() File "C:\Python25\lib\asyncore.py", line 191, in loop poll_fun(timeout, map) File "C:\Python25\lib\asyncore.py", line 121, in poll r, w, e = select.select(r, w, e, timeout) ValueError: too many file descriptors in select() On my Linux Ubuntu 6.10 (kernel 2.6.17-10, Python 2.5) different type of errors are raised depending on the application (client or server). In an asyncore-based client the error is raised by socket module (dispatcher's "self.socket" attribute) inside 'connect' method of 'dispatcher' class: [...] connections: 1018 connections: 1019 connections: 1020 connections: 1021 Traceback (most recent call last): File "asyncore_client.py", line 31, in File "asyncore.py", line 191, in loop File "asyncore.py", line 138, in poll File "asyncore.py", line 80, in write File "asyncore.py", line 76, in write File "asyncore.py", line 395, in handle_write_event File "asyncore_client.py", line 24, in handle_connect File "asyncore_client.py", line 9, in __init__ File "asyncore.py", line 257, in create_socket File "socket.py", line 156, in __init__ socket.error: (24, 'Too many open files') On an asyncore-based server the error is raised by socket module (dispatcher's "self.socket" attribute) inside 'accept' method of 'dispatcher' class: [...] connections: 1019 connections: 1020 connections: 1021 Traceback (most recent call last): File "asyncore_server.py", line 38, in File "asyncore.py", line 191, in loop File "asyncore.py", line 132, in poll File "asyncore.py", line 72, in read File "asyncore.py", line 68, in read File "asyncore.py", line 384, in handle_read_event File "asyncore_server.py", line 16, in handle_accept File "asyncore.py", line 321, in accept File "socket.py", line 170, in accept socket.error: (24, 'Too many open files') ---------------------------------------------------------------------- Comment By: Sam Rushing (rushing) Date: 2007-03-30 10:22 Message: Logged In: YES user_id=73736 Originator: NO Turns out medusa doesn't have a socket counter class, that was some other project I was thinking of. Putting a try/except in place doesn't really help the problem... if you fail to create a new socket what action will you take? A better approach is to have a configurable limit on the number of open connections, and then have a server-specific reaction to exceeding that limit. For example, an SMTP server might respond with a 4XX greeting and close the connection. An additional problem on Unix is that running out of descriptors affects more than just sockets. Once you hit the FD limit you can't open files, or do anything that requires a descriptor. ---------------------------------------------------------------------- Comment By: billiejoex (billiejoex) Date: 2007-03-29 07:03 Message: Logged In: YES user_id=1357589 Originator: YES > The problem is that there's no portable way to know what the limit > on file descriptors is. Why don't put a try/except statement before creating a new socket's file-descriptor? I believe that such problem shouldn't be understimated. Actually asyncore is the only asynchronous module present in Python's stdlib. If asyncore suffers a DoS vulnerability it just means that writing a secure client/server application with Python without using a third-party library isn't possible. I wrote a modified version of asyncore that solves the problem with select (affecting Windows) but still can't find a way to solve the problem with socket's file-descriptors (affecting Unix). ---------------------------------------------------------------------- Comment By: Sam Rushing (rushing) Date: 2007-03-23 12:59 Message: Logged In: YES user_id=73736 Originator: NO The problem is that there's no portable way to know what the limit on file descriptors is. The 'classic' for select/poll is the FD_SETSIZE macro. But on some operating systems there is no such limit. [e.g., win32 does not use the 'lowest-free-int' model common to unix]. I believe that in Medusa there was a derived class or extension that counted the number of open sockets, and limited it, using something like a semaphore. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685000&group_id=5470 From noreply at sourceforge.net Sat Mar 31 02:45:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Mar 2007 17:45:59 -0700 Subject: [ python-Bugs-451607 ] SSL support in socket module needs tests Message-ID: Bugs item #451607, was opened at 2001-08-16 13:00 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=451607&group_id=5470 Please note that this 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 Private: No Submitted By: Barry A. Warsaw (bwarsaw) >Assigned to: Facundo Batista (facundobatista) Summary: SSL support in socket module needs tests Initial Comment: SSL support in the socket module should have a regression test, either in test_socket.py or in a separate test_ssl.py file. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2007-03-30 21:45 Message: Logged In: YES user_id=752496 Originator: NO I'll try to test the socket to a (when available) local openssl server. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-12 05:01 Message: Logged In: YES user_id=21627 I don't think I will do anything about this anytime soon, so unassigning myself. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-10 05:51 Message: Logged In: YES user_id=21627 I don't think this is relevant here: OpenSSL uses whatever device it uses; we need not to concern ourselves with OpenSSL's choice. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-10-10 05:39 Message: Logged In: NO Using /dev/random for a user level application is inappropriate. Use /dev/urandom instead. /dev/random actually tries to suck entropy out of the entropy pool, and blocks if there's not enough. It's best to make sure there's sufficient initial entropy in the pool, then use /dev/urandom which uses the existing entropy to seed a CPRNG. Assuming the CPRNG is properly designed, /dev/urandom should be fine for OpenSSL, since if someone magically breaks the cryptography in the CPRNG then they can probably break OpenSSL's cryptography the same way. --phr ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-10 05:13 Message: Logged In: YES user_id=21627 Things have changed a bit since: Solaris 9 has /dev/random. ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2002-10-09 15:25 Message: Logged In: YES user_id=80200 yes it definitely does because on solaris, which doesn't have a /dev/random, urlretrieve fails to operate because openssl cannot get enough entropy for the PRNG in order to make the SSL connection. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2001-10-11 16:39 Message: Logged In: YES user_id=21627 1) When prngd runs on a TCP socket, it still won't accept connections from remote systems. 2) Sure, but would that simplify testing? 3) My comment was actually directed at bug #232460, which is Solaris specific: Solaris does not have a /dev/[u]random, so prngd is the only choice. I agree that using /dev/random is better if available. Furthermore, OpenSSL will already make this choice for you at installation time. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-11 15:44 Message: Logged In: YES user_id=72053 1) I think it's dangerous to run a prngd on an IP socket instead of a Unix domain socket. It creates the possibility of (either accidentally or by ignorance) running OpenSSL on a separate host from the prngd, making the random numbers vulnerable to network sniffing. That's bad--the numbers are cryptographic secrets and should not be exposed. 2) It's simple to set up a local SSL server with the command line openssl s_server option. 3) I'm not crazy about the whole prngd concept. I haven't looked at the CHILL interface yet, but if it's possible to abandon prngd and get random numbers through CHILL, that might be best. On Linux, /dev/urandom should be used. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2001-10-11 15:32 Message: Logged In: YES user_id=21627 On PRNG problems, it seems we have two options: - wait for, then require OpenSSL 0.9.7. It will look for a prngd socket in default locations (/var/run/egd-pool, /dev/egd-pool, /etc/egd-pool and /etc/entropy); then require administrators to set up OpenSSL that it indeed finds a prngd in these locations when needed. - expose RAND_add. Exposing any other of the interfaces is pointless; on our installation, prngd runs on localhost:708 instead of a Unix domain socket, and none of the other interfaces could use such a configuration. On top of RAND_add, we could communicate with prngd ourselves, e.g. by using the RANDFILE environment variable. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2001-09-03 12:12 Message: Logged In: YES user_id=21627 I'd suggest an approach similar to the one in test_socket, i.e. test only if can_fork. As for the certificates: I think they should be generated in advance and included into the test suite. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2001-08-28 10:53 Message: Logged In: YES user_id=12800 There is currently an extremely minimal test in test_socket_ssl.py, but it is fairly bogus because it requires an outside network connection. The only test there just tries to hit https://sf.net. Ideally, there would be a set of regression tests that only required local resources. I.e. it would set up a local SSL server, then do connects to it to test the various SSL features in socket module. Take a look at test_socket_ssl.py in the 2.2 cvs and see if you can improve matters. From what I understand, the tricky part is generating all the necessary certificates, etc. Also, if you intend to work on this, please log in to SF to continue this dialog so we know who we're talking to! :) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-08-28 02:58 Message: Logged In: NO I may be able to help with this. I'm fairly familiar with SSL in general, though not about the socket module. What's needed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=451607&group_id=5470 From noreply at sourceforge.net Sat Mar 31 03:23:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Mar 2007 18:23:34 -0700 Subject: [ python-Bugs-1027394 ] socket.ssl should explain that it is a 2/3 connection Message-ID: Bugs item #1027394, was opened at 2004-09-13 14:45 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1027394&group_id=5470 Please note that this 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 Private: No Submitted By: adam goucher (adamg-work) Assigned to: Nobody/Anonymous (nobody) Summary: socket.ssl should explain that it is a 2/3 connection Initial Comment: When you try to connect via socket.ssl(), python attempts a ssl2 connection then negotiates up. On some servers however ssl2 is disabled making the connection fail. The documentation should mention this limitation. If you want to connect to an ssl3 or tls1 only server, you need to modify the ssl context this method uses. I submitted a patch (889813) some time ago to allow the context to be specified as an optional argument. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2007-03-30 22:23 Message: Logged In: YES user_id=752496 Originator: NO Please, could you came up with a text that I could use to fix the docs? There's no need of LaTeX format here, just append the parragraph here. Regards, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1027394&group_id=5470 From noreply at sourceforge.net Sat Mar 31 12:32:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 31 Mar 2007 03:32:54 -0700 Subject: [ python-Bugs-1689458 ] pdb unable to jump to first statement Message-ID: Bugs item #1689458, was opened at 2007-03-27 17:07 Message generated for change (Comment added) made by rockyb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689458&group_id=5470 Please note that this 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 Private: No Submitted By: gotgenes (gotgenes) Assigned to: Nobody/Anonymous (nobody) Summary: pdb unable to jump to first statement Initial Comment: The Python debugger is unable to "jump" back to the first executable statement in a frame once that statement has been executed. For example: chris at feathers:~/development/playground$ python -m pdb simple.py > /home/chris/development/playground/simple.py(3)?() -> a = 1 (Pdb) next > /home/chris/development/playground/simple.py(4)?() -> b = 2 (Pdb) jump 3 > /home/chris/development/playground/simple.py(3)?() -> a = 1 (Pdb) list 1 #!/usr/bin/env python 2 3 a = 1 4 -> b = 2 5 6 c = a + b 7 8 print c [EOF] (Pdb) next > /home/chris/development/playground/simple.py(6)?() -> c = a + b One can see that after supposedly "jump"ing to line 3 at the second command, when "list"ing the line, the debugger is actually at line 4. The "next" command further demonstrates this since it re-executes line 4 and moves to line 6. This issue was raised on comp.lang.python. (For example, see or if that link is munged, refer to Duncan Booth offers the following: [quote] I verified (with a print statement in pdb) that assigning to self.curframe.f_lineno sets self.curframe.f_lineno and sel.curframe.f_lasti incorrectly ... The problem looks to be in frameobject.c: addr = 0; line = f->f_code->co_firstlineno; new_lasti = -1; for (offset = 0; offset < lnotab_len; offset += 2) { addr += lnotab[offset]; line += lnotab[offset+1]; if (line >= new_lineno) { new_lasti = addr; new_lineno = line; break; } } The first bytes in lnotab are the length and line increment for line 3 (i.e. 6, 1). If line==f->f_code->co_firstlineno it should set new_lasti=0, new_lineno=line but the loop still executes once which increments new_lasti and new_lineno to the next line (6, 4). [/quote] And Rocky Bernstein offers the following: [quote] Best as I can tell, it looks like a bug in Python. pdb, pydb, rpdb2 all handle the "jump" command by changing the frame f_lineno value. When the corresponding code pointer has offset 0 (or equivalently and more simlply as you put it, is the first statement) this doesn't seem to work properly. [/quote] ---------------------------------------------------------------------- Comment By: Rocky Bernstein (rockyb) Date: 2007-03-31 06:32 Message: Logged In: YES user_id=158581 Originator: NO Although a single file unit test would be nice, below is a short simple program that I think clearly shows the bug. Alas, as a follow-up comment I don't see a way to attach files so I have to paste it inline. However with this example and the information from Duncan Booth, I think the problem and how to fix it is pretty clear. file: jumpbug.py #!/usr/bin/env python import inspect, linecache, sys def tracer(frame, event, arg): global z (filename, line_no) = inspect.getframeinfo(frame)[0:2] print "Event %s at line %d:" % (event, line_no) print "\t", linecache.getline(filename, line_no), print "----------------------" try: if z == 0: if line_no == 4: print "***We jumped back to line 4 but should have gone to 2**" sys.exit(1) frame.f_lineno = 2 # And 3 is broken too. except NameError: pass return tracer # This helps emacs figure indentation out sys.settrace(tracer) execfile("jumpbug2.py") #END first file file jumpbug2.py: #!/usr/bin/env python x = 2 # This statement gets skipped the 2nd time around q = 1 # This statement gets skipped too! try: # tracer() will exit here if z == 0 and line_no == 4 y = z except NameError: z = 0 print "When tracing via tracer(), f_lineno will be set to 2 here." print "You should never get here when tracing" file jumpbug2.py: ---------------------------------------------------------------------- Comment By: gotgenes (gotgenes) Date: 2007-03-28 21:24 Message: Logged In: YES user_id=1180453 Originator: YES Truthfully, I don't have enough know-how to write a full test case or a patch. I have put forth a request on the comp.lang.python thread (link in original report) for those that would to please do so. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-28 17:54 Message: Logged In: YES user_id=1344176 Originator: NO Could you work up a full test case for this? Or better yet, a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689458&group_id=5470 From noreply at sourceforge.net Sat Mar 31 14:05:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 31 Mar 2007 05:05:26 -0700 Subject: [ python-Bugs-1622664 ] language reference index links are broken Message-ID: Bugs item #1622664, was opened at 2006-12-26 22:15 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1622664&group_id=5470 Please note that this 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 Private: No Submitted By: Drew Perttula (drewp) Assigned to: Nobody/Anonymous (nobody) Summary: language reference index links are broken Initial Comment: http://docs.python.org/ref/genindex.html For example, this text "globals() (built-in function)" links to http://docs.python.org/ref/exec.html#l2h-571, which is completely wrong. Some links are correct, but many others are broken. The page footer says "Release 2.5, documentation updated on 19th September, 2006." ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2007-03-31 09:05 Message: Logged In: YES user_id=752496 Originator: NO Where do you think it should point to? Take note that you're looking into the language reference, not the library reference. Regards, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1622664&group_id=5470 From noreply at sourceforge.net Sat Mar 31 14:09:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 31 Mar 2007 05:09:51 -0700 Subject: [ python-Bugs-920573 ] http libraries throw errors internally Message-ID: Bugs item #920573, was opened at 2004-03-21 15:16 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=920573&group_id=5470 Please note that this 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: Rejected Priority: 5 Private: No Submitted By: Bram Cohen (bram_cohen) Assigned to: Nobody/Anonymous (nobody) Summary: http libraries throw errors internally Initial Comment: Here's an error which someone just got running BitTorrent - Exception in thread Thread-2: Traceback (most recent call last): File "/usr/lib/python2.3/threading.py", line 436, in __bootstrap self.run() File "/usr/lib/python2.3/threading.py", line 416, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib/python2.3/site-packages/BitTorrent/Rerequester.py", line 72, in rerequest h = urlopen(url) File "/usr/lib/python2.3/urllib2.py", line 129, in urlopen return _opener.open(url, data) File "/usr/lib/python2.3/urllib2.py", line 326, in open '_open', req) File "/usr/lib/python2.3/urllib2.py", line 306, in _call_chain result = func(*args) File "/usr/lib/python2.3/urllib2.py", line 491, in lambda r, proxy=url, type=type, meth=self.proxy_open: \ File "/usr/lib/python2.3/urllib2.py", line 498, in proxy_open if '@' in host: TypeError: iterable argument required And here's one which people have been getting *forever*, without it ever having been fixed (I've been simply catching and ignoring it) - Exception in thread Thread-60: Traceback (most recent call last): File "/usr/lib/python2.2/threading.py", line 414, in __bootstrap self.run() File "/usr/lib/python2.2/threading.py", line 402, in run apply(self.__target, self.__args, self.__kwargs) File "/home/zkessin/bin/BitTorrent/Rerequester.py", line 85, in rerequest r = h.read() File "/usr/lib/python2.2/httplib.py", line 1140, in read assert not self._line_consumed and self._line_left AssertionError Both of the above were caused by very straightforward calls to httplib. I'm fairly certain (especially with the second one) that they're internal bugs. I'd like to mention while I'm at it that I'm extremely unhappy with httplib. It's buggy, blocking, and doesn't even support timeouts. While it's good to have a library which supports all the vagaries of http, it would be far better for it to be a simple object which you tell when data was received and it tells you when there's data to be sent out. That way it could integrate easily into other applications's event loops. The blocking and buggy nature of httplib has caused me no end of headaches, and I think I'm not the only one. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2007-03-31 09:09 Message: Logged In: YES user_id=752496 Originator: NO For any bug to be solved, we'd need a way to reproduce it. Thes three points are very useful: - What do you do - What do you get - What do you expect "this is an error from somebody running bittorrent" is not specific enough to us to be able to find the bug (if any). Please, consider detail this a bit more. Regards, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=920573&group_id=5470 From noreply at sourceforge.net Sat Mar 31 14:35:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 31 Mar 2007 05:35:07 -0700 Subject: [ python-Bugs-1623153 ] preferred diff format should be mentioned as "unified". Message-ID: Bugs item #1623153, was opened at 2006-12-27 18:18 Message generated for change (Settings changed) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1623153&group_id=5470 Please note that this 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 Private: No Submitted By: Raghuram Devarakonda (draghuram) >Assigned to: Facundo Batista (facundobatista) Summary: preferred diff format should be mentioned as "unified". Initial Comment: The page at http://www.python.org/dev/tools/ mentions that context diffs are preferred. However, the link at http://www.python.org/dev/patches/ mentions that "We like unified diffs. We grudgingly accept contextual diffs.". So "tools" page should preferably mention unified diffs as well. Thanks, Raghu ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1623153&group_id=5470 From noreply at sourceforge.net Sat Mar 31 14:36:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 31 Mar 2007 05:36:54 -0700 Subject: [ python-Bugs-1430435 ] urllib2 has memory leaks Message-ID: Bugs item #1430435, was opened at 2006-02-13 01:30 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1430435&group_id=5470 Please note that this 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 Private: No Submitted By: halfik (halfik) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 has memory leaks Initial Comment: reg = urllib2.Request(url, data, headers) rl_handle = urllib2.urlopen(reg) urllib2 has hot memory leaks. gc: uncollectable <_fileobject memory_adres> gc: uncollectable ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2007-03-31 09:36 Message: Logged In: YES user_id=752496 Originator: NO How did you produce those results? (how can I reproduce them?) In which Python version you did? Regards, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1430435&group_id=5470 From noreply at sourceforge.net Sat Mar 31 14:45:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 31 Mar 2007 05:45:01 -0700 Subject: [ python-Bugs-1379209 ] socket.recv(OOB) raises exception on closed socket Message-ID: Bugs item #1379209, was opened at 2005-12-13 00:14 Message generated for change (Settings changed) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379209&group_id=5470 Please note that this 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 Private: No Submitted By: Roy Smith (roysmith) >Assigned to: Facundo Batista (facundobatista) Summary: socket.recv(OOB) raises exception on closed socket Initial Comment: frame:pyClient$ python Python 2.4.1 (#1, Aug 16 2005, 20:11:22) [GCC 3.4.3] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> ^D frame:pyClient$ uname -a SunOS frame 5.8 Generic_108528-27 sun4u sparc If you try to read out-of-band data on a closed socket, the recv() call raises socket.error, signaling "invalid argument". This seems wrong. Doing a normal (in-band) recv() on a closed socket returns an empty string; trying to read OOB data should do the same thing. At worst, it should raise a more specific error. I'm guessing this exception is reflecting an errno of EBADF. A more specific error would at least make it clear that it's the first argument to recv() which was bad, not the second. frame:pyClient$ cat oob.py #!/usr/bin/env python import socket s = socket.socket() s.connect (("localhost", 13)) # 13 = daytime print "==> ", `s.recv(1024)` print "OOB: ", `s.recv (1024, socket.MSG_OOB)` frame:pyClient$ ./oob.py ==> 'Mon Dec 12 22:00:29 2005\n\r' OOB: Traceback (most recent call last): File "./oob.py", line 8, in ? print "OOB: ", `s.recv (1024, socket.MSG_OOB)` socket.error: (22, 'Invalid argument') frame:pyClient$ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379209&group_id=5470 From noreply at sourceforge.net Sat Mar 31 15:27:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 31 Mar 2007 06:27:26 -0700 Subject: [ python-Bugs-1671676 ] test_mailbox is hanging while doing gmake test on HP-UX v3 Message-ID: Bugs item #1671676, was opened at 2007-03-01 19:24 Message generated for change (Comment added) made by shashikala You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671676&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: shashi (shashikala) Assigned to: Nobody/Anonymous (nobody) Summary: test_mailbox is hanging while doing gmake test on HP-UX v3 Initial Comment: Hi , I am testing Python 2.5 on HP-UX 11iv3 using gmake test , while testing the test test_mailbox.py is hanging . when tried to track the problem i came to know that in the function if pid == 0: # In the child, lock the mailbox. self._box.lock() time.sleep(2) self._box.unlock() os._exit(0) # In the parent, sleep a bit to give the child time to acquire # the lock. time.sleep(0.5) try: self.assertRaises(mailbox.ExternalClashError, self._box.lock) finally: # Wait for child to exit. Locking should now succeed. exited_pid, status = os.waitpid(pid, 0) after forking the child , child is not returning status to the parent while its waiting for the return status. which part of the Python functionality is checked. Please assist me to solve this. Thanks in advance , shashi ---------------------------------------------------------------------- >Comment By: shashi (shashikala) Date: 2007-03-31 20:27 Message: Logged In: YES user_id=1506183 Originator: YES please find attached log stacktrace of test_mailbox.py , assist me to analyse the test hang. File Added: python.txt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671676&group_id=5470 From noreply at sourceforge.net Sat Mar 31 20:57:21 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 31 Mar 2007 11:57:21 -0700 Subject: [ python-Bugs-1688393 ] sock.recvfrom(-24) crashes Message-ID: Bugs item #1688393, was opened at 2007-03-26 07:13 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1688393&group_id=5470 Please note that this 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.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Andrew Bennetts (spiv) Assigned to: Facundo Batista (facundobatista) Summary: sock.recvfrom(-24) crashes Initial Comment: Actually sock.recvfrom(x) crashes or causes memory corruption for all values in -sizeof(PyStringObject) <= x < 0, I think. This script demonstrates the problem: import socket, sys s1 = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) s1.bind(('127.0.0.1', 9999)) s2 = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) s2.sendto('fdsjkldsfkj', ('127.0.0.1', 9999)) print s1.recvfrom(-24) Try e.g. -1 instead of -24 as well. I'm attaching a patch that fixes this bug, and adds a simple test for it too. Other sock_recv* functions in socketmodule.c seem to already catch negative recvlen values and raise ValueError, but for some reason recvfrom missed out. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-31 11:57 Message: Logged In: YES user_id=33168 Originator: NO Committed revision 54635. (2.5) 2.6 fix was in 54594. Also fixed some other copy and paste errors wrt method names when parsing arguments. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2007-03-27 20:46 Message: Logged In: YES user_id=752496 Originator: NO Applied this to the trunk, let's see if we should backport it to 2.5.x before close this bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1688393&group_id=5470 From noreply at sourceforge.net Sat Mar 31 20:58:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 31 Mar 2007 11:58:39 -0700 Subject: [ python-Bugs-1655392 ] thirdparty extensions, --enable-shared, static linking Message-ID: Bugs item #1655392, was opened at 2007-02-08 17:16 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1655392&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Marien Zwart (marienz) Assigned to: Georg Brandl (gbrandl) Summary: thirdparty extensions, --enable-shared, static linking Initial Comment: (I'm filing this under the "Build" category which may not be entirely accurate, but couldn't find a closer match. Is there a description of what the categories mean somewhere?). Python 2.5 built with --enable-shared on linux produces a shared libpython2.5.so in the "normal" libdir and only a static libpython2.5.a in /usr/lib/python2.5/config. Normally when you build extensions you want them to link to the dynamic one. However python-config --ldflags has -L/usr/lib/python2.5/config in its output, causing build processes using it to prefer the static library over the dynamic one. This is somewhat similar to bug 1600860: distutils does the same thing when compiling extensions in an --enable-shared python 2.5. I think either python-config should be modified to not mention that "config" dir on an --enable-shared build or the build process should be modified to put a .so file next to the .a file in that directory. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-31 18:58 Message: Logged In: YES user_id=849994 Originator: NO Fixed in rev. 54634, 54636. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-02-09 12:46 Message: Logged In: YES user_id=21627 Originator: NO The categories aren't described anywhere. python-config should describe the installed code; we shouldn't change what gets installed how for 2.5.1. Georg, with python-config being your code, can you take a look? If not, please unassign (in which case I'd ask marienz whether he would like to contribute a patch). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1655392&group_id=5470 From noreply at sourceforge.net Sat Mar 31 21:29:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 31 Mar 2007 12:29:58 -0700 Subject: [ python-Bugs-920573 ] http libraries throw errors internally Message-ID: Bugs item #920573, was opened at 2004-03-21 13:16 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=920573&group_id=5470 Please note that this 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 Private: No Submitted By: Bram Cohen (bram_cohen) Assigned to: Nobody/Anonymous (nobody) Summary: http libraries throw errors internally Initial Comment: Here's an error which someone just got running BitTorrent - Exception in thread Thread-2: Traceback (most recent call last): File "/usr/lib/python2.3/threading.py", line 436, in __bootstrap self.run() File "/usr/lib/python2.3/threading.py", line 416, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib/python2.3/site-packages/BitTorrent/Rerequester.py", line 72, in rerequest h = urlopen(url) File "/usr/lib/python2.3/urllib2.py", line 129, in urlopen return _opener.open(url, data) File "/usr/lib/python2.3/urllib2.py", line 326, in open '_open', req) File "/usr/lib/python2.3/urllib2.py", line 306, in _call_chain result = func(*args) File "/usr/lib/python2.3/urllib2.py", line 491, in lambda r, proxy=url, type=type, meth=self.proxy_open: \ File "/usr/lib/python2.3/urllib2.py", line 498, in proxy_open if '@' in host: TypeError: iterable argument required And here's one which people have been getting *forever*, without it ever having been fixed (I've been simply catching and ignoring it) - Exception in thread Thread-60: Traceback (most recent call last): File "/usr/lib/python2.2/threading.py", line 414, in __bootstrap self.run() File "/usr/lib/python2.2/threading.py", line 402, in run apply(self.__target, self.__args, self.__kwargs) File "/home/zkessin/bin/BitTorrent/Rerequester.py", line 85, in rerequest r = h.read() File "/usr/lib/python2.2/httplib.py", line 1140, in read assert not self._line_consumed and self._line_left AssertionError Both of the above were caused by very straightforward calls to httplib. I'm fairly certain (especially with the second one) that they're internal bugs. I'd like to mention while I'm at it that I'm extremely unhappy with httplib. It's buggy, blocking, and doesn't even support timeouts. While it's good to have a library which supports all the vagaries of http, it would be far better for it to be a simple object which you tell when data was received and it tells you when there's data to be sent out. That way it could integrate easily into other applications's event loops. The blocking and buggy nature of httplib has caused me no end of headaches, and I think I'm not the only one. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-03-31 14:29 Message: Logged In: YES user_id=80475 Originator: NO Both of these still need to be looked at (whether or not Bram supplies more detail). ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2007-03-31 07:09 Message: Logged In: YES user_id=752496 Originator: NO For any bug to be solved, we'd need a way to reproduce it. Thes three points are very useful: - What do you do - What do you get - What do you expect "this is an error from somebody running bittorrent" is not specific enough to us to be able to find the bug (if any). Please, consider detail this a bit more. Regards, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=920573&group_id=5470 From noreply at sourceforge.net Sat Mar 31 21:38:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 31 Mar 2007 12:38:03 -0700 Subject: [ python-Bugs-1623153 ] preferred diff format should be mentioned as "unified". Message-ID: Bugs item #1623153, was opened at 2006-12-27 16:18 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1623153&group_id=5470 Please note that this 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: Wont Fix Priority: 5 Private: No Submitted By: Raghuram Devarakonda (draghuram) Assigned to: Facundo Batista (facundobatista) Summary: preferred diff format should be mentioned as "unified". Initial Comment: The page at http://www.python.org/dev/tools/ mentions that context diffs are preferred. However, the link at http://www.python.org/dev/patches/ mentions that "We like unified diffs. We grudgingly accept contextual diffs.". So "tools" page should preferably mention unified diffs as well. Thanks, Raghu ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-03-31 14:38 Message: Logged In: YES user_id=80475 Originator: NO I don't think we really do care. Sometimes context diffs are easier to understand and sometimes unified diffs are the way to go depending on the patch. I say, let the world do what the world will do. No unnecessary rules. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1623153&group_id=5470 From noreply at sourceforge.net Sat Mar 31 21:56:35 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 31 Mar 2007 12:56:35 -0700 Subject: [ python-Bugs-1689617 ] Intel icc build fails with optimizations -O2 Message-ID: Bugs item #1689617, was opened at 2007-03-27 21:26 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689617&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michael Forbes (mforbes) Assigned to: Nobody/Anonymous (nobody) Summary: Intel icc build fails with optimizations -O2 Initial Comment: When building python 2.5 with the free Intel compilers for non-commercial use (icc), the build works without optimizations, but fails when optimizations -O2 and -O3 are used. The compilation proceedes without errors (though there are lot's of warnings and remarks) and makes a python executable, but when the python setup starts, the intepreter cannot import certain packages and cannot add two strings. case $MAKEFLAGS in \ *-s*) CC='icc -pthread' LDSHARED='icc -pthread -shared' OPT='-DNDEBUG -g -O2 -Ob2 -w1' ./python -E ./setup.py -q build;; \ *) CC='icc -pthread' LDSHARED='icc -pthread -shared' OPT='-DNDEBUG -g -O2 -Ob2 -w1' ./python -E ./setup.py build;; \ esac 'import site' failed; use -v for traceback Traceback (most recent call last): File "./setup.py", line 6, in import sys, os, imp, re, optparse File "/int/apps/mmf/src/Python-2.5_intel/Lib/optparse.py", line 71, in import textwrap File "/int/apps/mmf/src/Python-2.5_intel/Lib/textwrap.py", line 10, in import string, re File "/int/apps/mmf/src/Python-2.5_intel/Lib/string.py", line 26, in letters = lowercase + uppercase SystemError: error return without exception set make: *** [sharedmods] Error 1 For example: $ ./python 'import site' failed; use -v for traceback Python 2.5 (r25:51908, Mar 27 2007, 20:10:22) [GCC Intel(R) C++ gcc 3.4 mode] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a = "123" >>> a + "12" Traceback (most recent call last): File "", line 1, in SystemError: error return without exception set >>> Note that both the import of the site file fails and the addition fails. Python was configured with the following options: ./configure --with-gcc=icc\ --with-cxx-main=icc\ --prefix=/int/apps/mmf/apps/Python-2.5_intel/\ OPT="-g -O2 -Ob2 -w1" ---------------------------- When compiled with fewer optimiztions, everything seems to work. ./configure --with-gcc=icc\ --with-cxx-main=icc\ --prefix=/int/apps/mmf/apps/Python-2.5_intel/\ OPT="-g -O1 -Ob2 -w1" ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-31 12:56 Message: Logged In: YES user_id=33168 Originator: NO My guess is that it relates to strict aliasing (which Python violates). Can you find the equivalent flag to gcc's -fno-strict-aliasing in icc? ---------------------------------------------------------------------- Comment By: Michael Forbes (mforbes) Date: 2007-03-29 15:06 Message: Logged In: YES user_id=253921 Originator: YES I have spoken with some people who have had similar issues with the intel compilers in other applications, so it looks like it might be a compiler bug. I will look into this. Can anyone confirm this behaviour? (I only have access to one linux box). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-28 04:32 Message: Logged In: YES user_id=21627 Originator: NO Can you debug this further to determine a specific problem? It could be a compiler bug also, for all I can tell. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689617&group_id=5470 From noreply at sourceforge.net Sat Mar 31 22:31:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 31 Mar 2007 13:31:23 -0700 Subject: [ python-Bugs-1689617 ] Intel icc build fails with optimizations -O2 Message-ID: Bugs item #1689617, was opened at 2007-03-28 04:26 Message generated for change (Comment added) made by mforbes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689617&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michael Forbes (mforbes) Assigned to: Nobody/Anonymous (nobody) Summary: Intel icc build fails with optimizations -O2 Initial Comment: When building python 2.5 with the free Intel compilers for non-commercial use (icc), the build works without optimizations, but fails when optimizations -O2 and -O3 are used. The compilation proceedes without errors (though there are lot's of warnings and remarks) and makes a python executable, but when the python setup starts, the intepreter cannot import certain packages and cannot add two strings. case $MAKEFLAGS in \ *-s*) CC='icc -pthread' LDSHARED='icc -pthread -shared' OPT='-DNDEBUG -g -O2 -Ob2 -w1' ./python -E ./setup.py -q build;; \ *) CC='icc -pthread' LDSHARED='icc -pthread -shared' OPT='-DNDEBUG -g -O2 -Ob2 -w1' ./python -E ./setup.py build;; \ esac 'import site' failed; use -v for traceback Traceback (most recent call last): File "./setup.py", line 6, in import sys, os, imp, re, optparse File "/int/apps/mmf/src/Python-2.5_intel/Lib/optparse.py", line 71, in import textwrap File "/int/apps/mmf/src/Python-2.5_intel/Lib/textwrap.py", line 10, in import string, re File "/int/apps/mmf/src/Python-2.5_intel/Lib/string.py", line 26, in letters = lowercase + uppercase SystemError: error return without exception set make: *** [sharedmods] Error 1 For example: $ ./python 'import site' failed; use -v for traceback Python 2.5 (r25:51908, Mar 27 2007, 20:10:22) [GCC Intel(R) C++ gcc 3.4 mode] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a = "123" >>> a + "12" Traceback (most recent call last): File "", line 1, in SystemError: error return without exception set >>> Note that both the import of the site file fails and the addition fails. Python was configured with the following options: ./configure --with-gcc=icc\ --with-cxx-main=icc\ --prefix=/int/apps/mmf/apps/Python-2.5_intel/\ OPT="-g -O2 -Ob2 -w1" ---------------------------- When compiled with fewer optimiztions, everything seems to work. ./configure --with-gcc=icc\ --with-cxx-main=icc\ --prefix=/int/apps/mmf/apps/Python-2.5_intel/\ OPT="-g -O1 -Ob2 -w1" ---------------------------------------------------------------------- >Comment By: Michael Forbes (mforbes) Date: 2007-03-31 20:31 Message: Logged In: YES user_id=253921 Originator: YES It does not appear to be a problem with aliasing (icc accepts the -fno-strict-aliasing flag and it is set by default using ./configure. It is another question of whether or not icc behaves this flag!). This looks similar to a previous problem but I am not using any processor specific optimizations: http://mail.python.org/pipermail/python-list/2005-March/312145.html ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-31 19:56 Message: Logged In: YES user_id=33168 Originator: NO My guess is that it relates to strict aliasing (which Python violates). Can you find the equivalent flag to gcc's -fno-strict-aliasing in icc? ---------------------------------------------------------------------- Comment By: Michael Forbes (mforbes) Date: 2007-03-29 22:06 Message: Logged In: YES user_id=253921 Originator: YES I have spoken with some people who have had similar issues with the intel compilers in other applications, so it looks like it might be a compiler bug. I will look into this. Can anyone confirm this behaviour? (I only have access to one linux box). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-28 11:32 Message: Logged In: YES user_id=21627 Originator: NO Can you debug this further to determine a specific problem? It could be a compiler bug also, for all I can tell. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689617&group_id=5470 From tracker at psf.upfronthosting.co.za Wed Mar 14 18:42:00 2007 From: tracker at psf.upfronthosting.co.za (tracker at psf.upfronthosting.co.za) Date: Wed, 14 Mar 2007 17:42:00 -0000 Subject: Test 2 Message-ID: <20070314174200.80DE61E400B@bag.python.org> From report at bugs.python.org Tue Mar 27 20:08:15 2007 From: report at bugs.python.org (Erik Forsberg) Date: Tue, 27 Mar 2007 18:08:15 -0000 Subject: [issue1026] Test issue, to report@ Message-ID: <1175018429.34.0.0453028907494.issue1026@psf.upfronthosting.co.za> Erik Forsberg added the comment: A change note on a test issue. And hello to the python-bugs list! :-) __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 28 16:35:48 2007 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 28 Mar 2007 14:35:48 -0000 Subject: [issue1023] Buy Tramadol online Message-ID: <1175092543.82.0.260946300942.issue1023@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Closing this issue. ---------- nosy: +amk resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 28 23:42:55 2007 From: report at bugs.python.org (onlinestocktrading) Date: Wed, 28 Mar 2007 21:42:55 -0000 Subject: [issue1027] base64.urlsafe_b64encode() shouldn't use the = character Message-ID: <1175118173.96.0.880342551829.issue1027@psf.upfronthosting.co.za> Changes by onlinestocktrading: ---------- files: soma.html severity: normal status: open title: base64.urlsafe_b64encode() shouldn't use the = character type: rfe __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 28 23:44:09 2007 From: report at bugs.python.org (onlinestocktrading) Date: Wed, 28 Mar 2007 21:44:09 -0000 Subject: [issue1027] base64.urlsafe_b64encode() shouldn't use the = character Message-ID: <1175118248.47.0.342246975054.issue1027@psf.upfronthosting.co.za> Changes by onlinestocktrading: ---------- components: +Windows type: rfe -> versions: +Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Mar 28 23:44:49 2007 From: report at bugs.python.org (onlinestocktrading) Date: Wed, 28 Mar 2007 21:44:49 -0000 Subject: [issue1027] base64.urlsafe_b64encode() shouldn't use the = character Message-ID: <1175118288.44.0.860944466224.issue1027@psf.upfronthosting.co.za> Changes by onlinestocktrading: ---------- components: +Interpreter Core -Windows __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Mar 30 11:15:36 2007 From: report at bugs.python.org (devel) Date: Fri, 30 Mar 2007 09:15:36 -0000 Subject: [issue1027] base64.urlsafe_b64encode() shouldn't use the = character Message-ID: <1175246135.04.0.946256540513.issue1027@psf.upfronthosting.co.za> Changes by devel: __________________________________ Tracker __________________________________