From noreply at sourceforge.net Sun Jan 1 01:06:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 31 Dec 2005 16:06:19 -0800 Subject: [ python-Bugs-1394612 ] 'Plus' filemode exposes uninitialized memory on win32 Message-ID: Bugs item #1394612, was opened at 2005-12-31 16: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=1394612&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Cory Dodt (corydodt) Assigned to: Nobody/Anonymous (nobody) Summary: 'Plus' filemode exposes uninitialized memory on win32 Initial Comment: (Note: I'm using cygwin zsh, hence the prompts. I am using standard, python.org Python for these tests.) % echo abcdef > foo % python 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. >>> f = file('foo','r+b') >>> f.write('ghi') >>> f.read() '\x00x\x01\x83\x00\xe8\x03\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00e\x00\x00i\x01 \x00d\x00\x00\x83\x01\x00Fd\x01\x00S\x00S\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00[...lots and lots and lots of uninitialized memory deleted...]\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\x00abcdef\n' >>> f.close() >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394612&group_id=5470 From noreply at sourceforge.net Sun Jan 1 06:38:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 31 Dec 2005 21:38:06 -0800 Subject: [ python-Bugs-1394612 ] 'Plus' filemode exposes uninitialized memory on win32 Message-ID: Bugs item #1394612, was opened at 2006-01-01 00:06 Message generated for change (Comment added) made by clintonroy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394612&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Cory Dodt (corydodt) Assigned to: Nobody/Anonymous (nobody) Summary: 'Plus' filemode exposes uninitialized memory on win32 Initial Comment: (Note: I'm using cygwin zsh, hence the prompts. I am using standard, python.org Python for these tests.) % echo abcdef > foo % python 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. >>> f = file('foo','r+b') >>> f.write('ghi') >>> f.read() '\x00x\x01\x83\x00\xe8\x03\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00e\x00\x00i\x01 \x00d\x00\x00\x83\x01\x00Fd\x01\x00S\x00S\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00[...lots and lots and lots of uninitialized memory deleted...]\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\x00abcdef\n' >>> f.close() >>> ---------------------------------------------------------------------- Comment By: Clinton Roy (clintonroy) Date: 2006-01-01 05:38 Message: Logged In: YES user_id=31446 Hi Cory, I don't think r+ mode will create the file if it doesn't exist, so at a guess I think what you're seeing is the actual contents of a file named foo that are on the disk, not junk. If you delete the file foo and run your test again, you should get an error to that effect. cheers, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394612&group_id=5470 From noreply at sourceforge.net Sun Jan 1 07:06:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 31 Dec 2005 22:06:43 -0800 Subject: [ python-Bugs-1394612 ] 'Plus' filemode exposes uninitialized memory on win32 Message-ID: Bugs item #1394612, was opened at 2005-12-31 19:06 Message generated for change (Settings changed) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394612&group_id=5470 Please note that this message will contain 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: Closed >Resolution: Invalid Priority: 5 Submitted By: Cory Dodt (corydodt) Assigned to: Nobody/Anonymous (nobody) Summary: 'Plus' filemode exposes uninitialized memory on win32 Initial Comment: (Note: I'm using cygwin zsh, hence the prompts. I am using standard, python.org Python for these tests.) % echo abcdef > foo % python 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. >>> f = file('foo','r+b') >>> f.write('ghi') >>> f.read() '\x00x\x01\x83\x00\xe8\x03\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00e\x00\x00i\x01 \x00d\x00\x00\x83\x01\x00Fd\x01\x00S\x00S\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00[...lots and lots and lots of uninitialized memory deleted...]\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\x00abcdef\n' >>> f.close() >>> ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-01-01 01:06 Message: Logged In: YES user_id=31435 This is actually pilot error (not a bug!), although it's subtle: Python uses the platform C I/O implementation, and in standard C mixing reads with writes yields undefined behavior unless a file-positioning operation (typically a seek()) occurs between switching from reading to writing (or vice versa); here from the C standard: When a file is opened with update mode (???+??? as the second or third character in the above list of mode argument values), both input and output may be performed on the associated stream. However, output shall not be directly followed by input without an intervening call to the fflush function or to a file positioning function (fseek, fsetpos, or rewind), and input shall not be directly followed by output without an intervening call to a file positioning function, unless the input operation encounters end-of-file. In other words, the result of running your sample code is undefined: nothing is guaranteed about its behavior, which both can and does vary across platforms. If you want defined behavior, then, for example, add >>> f.seek(0) between your write() and read() calls. ---------------------------------------------------------------------- Comment By: Clinton Roy (clintonroy) Date: 2006-01-01 00:38 Message: Logged In: YES user_id=31446 Hi Cory, I don't think r+ mode will create the file if it doesn't exist, so at a guess I think what you're seeing is the actual contents of a file named foo that are on the disk, not junk. If you delete the file foo and run your test again, you should get an error to that effect. cheers, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394612&group_id=5470 From noreply at sourceforge.net Sun Jan 1 17:53:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 01 Jan 2006 08:53:34 -0800 Subject: [ python-Bugs-1394868 ] errata Message-ID: Bugs item #1394868, was opened at 2006-01-01 11: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=1394868&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chad Whitacre (whit537) Assigned to: Nobody/Anonymous (nobody) Summary: errata Initial Comment: lib/node235.html -- opened as a text files lib/module-logging.html -- an event, an LogRecord instance lib/typessseq-strings.html -- The length modifier may be h, l, and L may be present lib/bltin-file-objects.html -- possibilities include that file may ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394868&group_id=5470 From noreply at sourceforge.net Sun Jan 1 22:36:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 01 Jan 2006 13:36:13 -0800 Subject: [ python-Bugs-1394868 ] doc errata Message-ID: Bugs item #1394868, was opened at 2006-01-01 17:53 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394868&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Chad Whitacre (whit537) >Assigned to: Reinhold Birkenfeld (birkenfeld) >Summary: doc errata Initial Comment: lib/node235.html -- opened as a text files lib/module-logging.html -- an event, an LogRecord instance lib/typessseq-strings.html -- The length modifier may be h, l, and L may be present lib/bltin-file-objects.html -- possibilities include that file may ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2006-01-01 22:36 Message: Logged In: YES user_id=1188172 Thanks for pointing them out, fixed in rev. 41862/41863. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394868&group_id=5470 From noreply at sourceforge.net Sun Jan 1 23:08:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 01 Jan 2006 14:08:14 -0800 Subject: [ python-Bugs-1394612 ] 'Plus' filemode exposes uninitialized memory on win32 Message-ID: Bugs item #1394612, was opened at 2005-12-31 19:06 Message generated for change (Comment added) made by kuran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394612&group_id=5470 Please note that this message will contain 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: Closed Resolution: Invalid Priority: 5 Submitted By: Cory Dodt (corydodt) Assigned to: Nobody/Anonymous (nobody) Summary: 'Plus' filemode exposes uninitialized memory on win32 Initial Comment: (Note: I'm using cygwin zsh, hence the prompts. I am using standard, python.org Python for these tests.) % echo abcdef > foo % python 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. >>> f = file('foo','r+b') >>> f.write('ghi') >>> f.read() '\x00x\x01\x83\x00\xe8\x03\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00e\x00\x00i\x01 \x00d\x00\x00\x83\x01\x00Fd\x01\x00S\x00S\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00[...lots and lots and lots of uninitialized memory deleted...]\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\x00abcdef\n' >>> f.close() >>> ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2006-01-01 17:08 Message: Logged In: YES user_id=366566 I think Cory was aware of the underlying requirement to interpose a seek operation between the write and read operations, but was concerned about the consequences of not doing so. Python normally protects one from doing things that are *too* dangerous: I guess it's unclear to him (and perhaps others) whether the current behavior of file is just (relatively) obscure or if it could lead to real problems (exposing sensitive data, crashing the process). It seems like the latter is somewhat unlikely in practice, but since the behavior is unspecified, it seems like it *could* happen. I guess since Tim closed this, he thinks it's not too dangerous. In this case, the documentation could probably stand to be improved somewhat. The section () that documents the various modes which can be used to open a file could updated to include a warning along the lines of that in the C standard. It should probably explicitly state which file methods can be used to satisfy this requirement, since it's not clear otherwise except by reading the implementation of the file type (one could guess, from that file.flush() and file.seek() are suitable, but the documentation for these only says "like stdio ...", so you can't be completely sure). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-01-01 01:06 Message: Logged In: YES user_id=31435 This is actually pilot error (not a bug!), although it's subtle: Python uses the platform C I/O implementation, and in standard C mixing reads with writes yields undefined behavior unless a file-positioning operation (typically a seek()) occurs between switching from reading to writing (or vice versa); here from the C standard: When a file is opened with update mode (???+??? as the second or third character in the above list of mode argument values), both input and output may be performed on the associated stream. However, output shall not be directly followed by input without an intervening call to the fflush function or to a file positioning function (fseek, fsetpos, or rewind), and input shall not be directly followed by output without an intervening call to a file positioning function, unless the input operation encounters end-of-file. In other words, the result of running your sample code is undefined: nothing is guaranteed about its behavior, which both can and does vary across platforms. If you want defined behavior, then, for example, add >>> f.seek(0) between your write() and read() calls. ---------------------------------------------------------------------- Comment By: Clinton Roy (clintonroy) Date: 2006-01-01 00:38 Message: Logged In: YES user_id=31446 Hi Cory, I don't think r+ mode will create the file if it doesn't exist, so at a guess I think what you're seeing is the actual contents of a file named foo that are on the disk, not junk. If you delete the file foo and run your test again, you should get an error to that effect. cheers, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394612&group_id=5470 From noreply at sourceforge.net Mon Jan 2 01:24:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 01 Jan 2006 16:24:01 -0800 Subject: [ python-Bugs-1394612 ] 'Plus' filemode exposes uninitialized memory on win32 Message-ID: Bugs item #1394612, was opened at 2005-12-31 19:06 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394612&group_id=5470 Please note that this message will contain 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: Closed Resolution: Invalid Priority: 5 Submitted By: Cory Dodt (corydodt) Assigned to: Nobody/Anonymous (nobody) Summary: 'Plus' filemode exposes uninitialized memory on win32 Initial Comment: (Note: I'm using cygwin zsh, hence the prompts. I am using standard, python.org Python for these tests.) % echo abcdef > foo % python 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. >>> f = file('foo','r+b') >>> f.write('ghi') >>> f.read() '\x00x\x01\x83\x00\xe8\x03\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00e\x00\x00i\x01 \x00d\x00\x00\x83\x01\x00Fd\x01\x00S\x00S\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00[...lots and lots and lots of uninitialized memory deleted...]\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\x00abcdef\n' >>> f.close() >>> ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-01-01 19:24 Message: Logged In: YES user_id=31435 There's nothing Python can do about this short of implementing I/O itself. That isn't likely. If someone is truly bothered by this behavior on Windows (or any other platform), they need to convince Microsoft (or other relevant C vendors) to change _their_ stdio implementation -- Python inherits the platform C's behavior, quirks and all. I'll note that I'm not bothered by it. It's one of those "doctor, doctor, it hurts when I do this!" kinds of pseudo-problems, IMO: so don't do that. It's not like hostile user input can "trick" a Python application into doing I/O operations in an undefined order. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2006-01-01 17:08 Message: Logged In: YES user_id=366566 I think Cory was aware of the underlying requirement to interpose a seek operation between the write and read operations, but was concerned about the consequences of not doing so. Python normally protects one from doing things that are *too* dangerous: I guess it's unclear to him (and perhaps others) whether the current behavior of file is just (relatively) obscure or if it could lead to real problems (exposing sensitive data, crashing the process). It seems like the latter is somewhat unlikely in practice, but since the behavior is unspecified, it seems like it *could* happen. I guess since Tim closed this, he thinks it's not too dangerous. In this case, the documentation could probably stand to be improved somewhat. The section () that documents the various modes which can be used to open a file could updated to include a warning along the lines of that in the C standard. It should probably explicitly state which file methods can be used to satisfy this requirement, since it's not clear otherwise except by reading the implementation of the file type (one could guess, from that file.flush() and file.seek() are suitable, but the documentation for these only says "like stdio ...", so you can't be completely sure). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-01-01 01:06 Message: Logged In: YES user_id=31435 This is actually pilot error (not a bug!), although it's subtle: Python uses the platform C I/O implementation, and in standard C mixing reads with writes yields undefined behavior unless a file-positioning operation (typically a seek()) occurs between switching from reading to writing (or vice versa); here from the C standard: When a file is opened with update mode (???+??? as the second or third character in the above list of mode argument values), both input and output may be performed on the associated stream. However, output shall not be directly followed by input without an intervening call to the fflush function or to a file positioning function (fseek, fsetpos, or rewind), and input shall not be directly followed by output without an intervening call to a file positioning function, unless the input operation encounters end-of-file. In other words, the result of running your sample code is undefined: nothing is guaranteed about its behavior, which both can and does vary across platforms. If you want defined behavior, then, for example, add >>> f.seek(0) between your write() and read() calls. ---------------------------------------------------------------------- Comment By: Clinton Roy (clintonroy) Date: 2006-01-01 00:38 Message: Logged In: YES user_id=31446 Hi Cory, I don't think r+ mode will create the file if it doesn't exist, so at a guess I think what you're seeing is the actual contents of a file named foo that are on the disk, not junk. If you delete the file foo and run your test again, you should get an error to that effect. cheers, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394612&group_id=5470 From noreply at sourceforge.net Mon Jan 2 01:43:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 01 Jan 2006 16:43:30 -0800 Subject: [ python-Bugs-1394612 ] 'Plus' filemode exposes uninitialized memory on win32 Message-ID: Bugs item #1394612, was opened at 2005-12-31 16:06 Message generated for change (Comment added) made by corydodt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394612&group_id=5470 Please note that this message will contain 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: Closed Resolution: Invalid Priority: 5 Submitted By: Cory Dodt (corydodt) Assigned to: Nobody/Anonymous (nobody) Summary: 'Plus' filemode exposes uninitialized memory on win32 Initial Comment: (Note: I'm using cygwin zsh, hence the prompts. I am using standard, python.org Python for these tests.) % echo abcdef > foo % python 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. >>> f = file('foo','r+b') >>> f.write('ghi') >>> f.read() '\x00x\x01\x83\x00\xe8\x03\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00e\x00\x00i\x01 \x00d\x00\x00\x83\x01\x00Fd\x01\x00S\x00S\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00[...lots and lots and lots of uninitialized memory deleted...]\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\x00abcdef\n' >>> f.close() >>> ---------------------------------------------------------------------- >Comment By: Cory Dodt (corydodt) Date: 2006-01-01 16:43 Message: Logged In: YES user_id=889183 Tim - at a minimum this should be documented; even if it's just a link to the ANSI C documentation. Python is not ANSI C, we shouldn't expect the Python user to seek out ANSI C documentation. Want me to open a separate doc bug? The current doc only says this (about the file builtin): """ Modes 'r+', 'w+' and 'a+' open the file for updating (note that 'w+' truncates the file). Append 'b' to the mode to open the file in binary mode, on systems that differentiate between binary and text files (else it is ignored). If the file cannot be opened, IOError is raised. """ Either here, or perhaps in section 2.3.9, a clear description should be given of how to properly operate a + mode file. Failing that, a pointer to ANSI C documentation so the user can read about it on its own (and so the user knows that this behavior conforms to the underlying platform API in every ugly detail). I'm also dubious that this exposed memory is innocuous, but I'll defer to your expertise on that one. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-01-01 16:24 Message: Logged In: YES user_id=31435 There's nothing Python can do about this short of implementing I/O itself. That isn't likely. If someone is truly bothered by this behavior on Windows (or any other platform), they need to convince Microsoft (or other relevant C vendors) to change _their_ stdio implementation -- Python inherits the platform C's behavior, quirks and all. I'll note that I'm not bothered by it. It's one of those "doctor, doctor, it hurts when I do this!" kinds of pseudo-problems, IMO: so don't do that. It's not like hostile user input can "trick" a Python application into doing I/O operations in an undefined order. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2006-01-01 14:08 Message: Logged In: YES user_id=366566 I think Cory was aware of the underlying requirement to interpose a seek operation between the write and read operations, but was concerned about the consequences of not doing so. Python normally protects one from doing things that are *too* dangerous: I guess it's unclear to him (and perhaps others) whether the current behavior of file is just (relatively) obscure or if it could lead to real problems (exposing sensitive data, crashing the process). It seems like the latter is somewhat unlikely in practice, but since the behavior is unspecified, it seems like it *could* happen. I guess since Tim closed this, he thinks it's not too dangerous. In this case, the documentation could probably stand to be improved somewhat. The section () that documents the various modes which can be used to open a file could updated to include a warning along the lines of that in the C standard. It should probably explicitly state which file methods can be used to satisfy this requirement, since it's not clear otherwise except by reading the implementation of the file type (one could guess, from that file.flush() and file.seek() are suitable, but the documentation for these only says "like stdio ...", so you can't be completely sure). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-12-31 22:06 Message: Logged In: YES user_id=31435 This is actually pilot error (not a bug!), although it's subtle: Python uses the platform C I/O implementation, and in standard C mixing reads with writes yields undefined behavior unless a file-positioning operation (typically a seek()) occurs between switching from reading to writing (or vice versa); here from the C standard: When a file is opened with update mode (???+??? as the second or third character in the above list of mode argument values), both input and output may be performed on the associated stream. However, output shall not be directly followed by input without an intervening call to the fflush function or to a file positioning function (fseek, fsetpos, or rewind), and input shall not be directly followed by output without an intervening call to a file positioning function, unless the input operation encounters end-of-file. In other words, the result of running your sample code is undefined: nothing is guaranteed about its behavior, which both can and does vary across platforms. If you want defined behavior, then, for example, add >>> f.seek(0) between your write() and read() calls. ---------------------------------------------------------------------- Comment By: Clinton Roy (clintonroy) Date: 2005-12-31 21:38 Message: Logged In: YES user_id=31446 Hi Cory, I don't think r+ mode will create the file if it doesn't exist, so at a guess I think what you're seeing is the actual contents of a file named foo that are on the disk, not junk. If you delete the file foo and run your test again, you should get an error to that effect. cheers, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394612&group_id=5470 From noreply at sourceforge.net Mon Jan 2 05:31:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 01 Jan 2006 20:31:36 -0800 Subject: [ python-Bugs-1393109 ] cannot build SVN trunk on old systems Message-ID: Bugs item #1393109, was opened at 2005-12-29 12:25 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1393109&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: cannot build SVN trunk on old systems Initial Comment: Parser/asdl_c.py uses "/usr/bin/env python" to find a proper python, but the script don't work on old Pythons (at least it fails on 2.1 and older). iirc, various solutions to this were discussed on python-dev, but nobody seems to have done anything about it. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-01 20:31 Message: Logged In: YES user_id=33168 One issue I see in asdl.py is that new-style classes are used. I don't know if they are really necessary. You could try adding something like this to the top of asdl.py and see if that fixes things: try: object except NameError: class object: pass Or maybe we just shouldn't make them new-style if that does fix things. I don't have an old version of python around. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1393109&group_id=5470 From noreply at sourceforge.net Mon Jan 2 11:48:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Jan 2006 02:48:42 -0800 Subject: [ python-Bugs-1390608 ] split() breaks no-break spaces Message-ID: Bugs item #1390608, was opened at 2005-12-26 16:03 Message generated for change (Comment added) made by sjoerd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390608&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: MvR (maxim_razin) Assigned to: M.-A. Lemburg (lemburg) Summary: split() breaks no-break spaces Initial Comment: string.split(), str.split() and unicode.split() without parameters break strings by the No-break space (U+00A0) character. This character is specially intended not to be a split border. >>> u"Hello\u00A0world".split() [u'Hello', u'world'] ---------------------------------------------------------------------- >Comment By: Sjoerd Mullender (sjoerd) Date: 2006-01-02 11:48 Message: Logged In: YES user_id=43607 Walter and MAL, did you actually try that work around? It doesn't work: >>> import sys, unicodedata >>> spaces = u"".join(unichr(c) for c in xrange(0, sys.maxunicode) if unicodedata.category(unichr(c))=="Zs" and c != 160) >>> foo = u"Hello\u00A0world" >>> foo.split(spaces) [u'Hello\xa0world'] That's because split() takes the whole separator argument as separator, not any of the characters in it. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-12-30 14:06 Message: Logged In: YES user_id=38388 Maxim, you are right that \xA0 is a non-break space. However, like the others already mentioned, the .split() method defaults to breaking a string on whitespace characters, not breakable whitespace characters. The intent is not a typographical one, but originates from the desire to quickly tokenize a string. If you'd rather like to see a different set of whitespace characters used, you can pass such a template string to the .split() method (Walter gave an example). Closing this as "Won't fix". ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-12-30 13:35 Message: Logged In: YES user_id=89016 What's wrong with the following? import sys, unicodedata spaces = u"".join(unichr(c) for c in xrange(0, sys.maxunicode) if unicodedata.category(unichr(c))=="Zs" and c != 160) foo.split(spaces) ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-12-30 01:30 Message: Logged In: YES user_id=55188 Python documentation says that it splits in "whitespace characters" not "breaking characters". So, current behavior is correct according to the documentation. And even rationale among string methods are heavily depends on ctype functions on libc. Therefore, we can't serve special treatment for the NBSP. However, I feel the need for the splitting function that awares what character is breaking or not. How about to add it as unicodedata.split()? ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-29 21:42 Message: Logged In: YES user_id=38376 split isn't a word-wrapping split, so I'm not sure that's the right place to fix this. ("no-break space" is white- space, according to the Unicode standard, and split breaks on whitespace). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390608&group_id=5470 From noreply at sourceforge.net Mon Jan 2 12:13:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Jan 2006 03:13:25 -0800 Subject: [ python-Bugs-1390608 ] split() breaks no-break spaces Message-ID: Bugs item #1390608, was opened at 2005-12-26 16:03 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390608&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: MvR (maxim_razin) Assigned to: M.-A. Lemburg (lemburg) Summary: split() breaks no-break spaces Initial Comment: string.split(), str.split() and unicode.split() without parameters break strings by the No-break space (U+00A0) character. This character is specially intended not to be a split border. >>> u"Hello\u00A0world".split() [u'Hello', u'world'] ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-01-02 12:13 Message: Logged In: YES user_id=38388 Oops. You're right, Sjoerd. Still, you could achieve the splitting by using a re-expression that is build from the set of characters fetched from the Unicode database and then using the .split() method of the re object. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2006-01-02 11:48 Message: Logged In: YES user_id=43607 Walter and MAL, did you actually try that work around? It doesn't work: >>> import sys, unicodedata >>> spaces = u"".join(unichr(c) for c in xrange(0, sys.maxunicode) if unicodedata.category(unichr(c))=="Zs" and c != 160) >>> foo = u"Hello\u00A0world" >>> foo.split(spaces) [u'Hello\xa0world'] That's because split() takes the whole separator argument as separator, not any of the characters in it. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-12-30 14:06 Message: Logged In: YES user_id=38388 Maxim, you are right that \xA0 is a non-break space. However, like the others already mentioned, the .split() method defaults to breaking a string on whitespace characters, not breakable whitespace characters. The intent is not a typographical one, but originates from the desire to quickly tokenize a string. If you'd rather like to see a different set of whitespace characters used, you can pass such a template string to the .split() method (Walter gave an example). Closing this as "Won't fix". ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-12-30 13:35 Message: Logged In: YES user_id=89016 What's wrong with the following? import sys, unicodedata spaces = u"".join(unichr(c) for c in xrange(0, sys.maxunicode) if unicodedata.category(unichr(c))=="Zs" and c != 160) foo.split(spaces) ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-12-30 01:30 Message: Logged In: YES user_id=55188 Python documentation says that it splits in "whitespace characters" not "breaking characters". So, current behavior is correct according to the documentation. And even rationale among string methods are heavily depends on ctype functions on libc. Therefore, we can't serve special treatment for the NBSP. However, I feel the need for the splitting function that awares what character is breaking or not. How about to add it as unicodedata.split()? ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-29 21:42 Message: Logged In: YES user_id=38376 split isn't a word-wrapping split, so I'm not sure that's the right place to fix this. ("no-break space" is white- space, according to the Unicode standard, and split breaks on whitespace). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390608&group_id=5470 From noreply at sourceforge.net Mon Jan 2 17:51:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Jan 2006 08:51:52 -0800 Subject: [ python-Bugs-1395442 ] os.remove should behave like rm, not unlink Message-ID: Bugs item #1395442, was opened at 2006-01-02 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=1395442&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Chad Whitacre (whit537) Assigned to: Nobody/Anonymous (nobody) Summary: os.remove should behave like rm, not unlink Initial Comment: Description =========== As expected, os.unlink only removes the file reference explicitly named, so if you have multiple links to the same file, os.unlink leaves those not named. However, I would expect os.remove to be equivalent to rm -- removing all references -- but it is a straight alias for os.unlink. Environment =========== Python 2.4.2 FreeBSD 4.11 Steps to Reproduce ================== $ touch foo $ ls -i 1689942 foo $ ln foo bar $ ls -i 1689942 bar 1689942 foo $ python -c 'import os; os.remove("bar")' $ l -i Expected Result =============== $ Actual Result ============= 1689942 foo $ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1395442&group_id=5470 From noreply at sourceforge.net Mon Jan 2 18:22:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Jan 2006 09:22:15 -0800 Subject: [ python-Bugs-1395442 ] os.remove should behave like rm, not unlink Message-ID: Bugs item #1395442, was opened at 2006-01-02 11:51 Message generated for change (Comment added) made by whit537 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1395442&group_id=5470 Please note that this message will contain 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: Deleted Resolution: None Priority: 5 Submitted By: Chad Whitacre (whit537) Assigned to: Nobody/Anonymous (nobody) Summary: os.remove should behave like rm, not unlink Initial Comment: Description =========== As expected, os.unlink only removes the file reference explicitly named, so if you have multiple links to the same file, os.unlink leaves those not named. However, I would expect os.remove to be equivalent to rm -- removing all references -- but it is a straight alias for os.unlink. Environment =========== Python 2.4.2 FreeBSD 4.11 Steps to Reproduce ================== $ touch foo $ ls -i 1689942 foo $ ln foo bar $ ls -i 1689942 bar 1689942 foo $ python -c 'import os; os.remove("bar")' $ l -i Expected Result =============== $ Actual Result ============= 1689942 foo $ ---------------------------------------------------------------------- >Comment By: Chad Whitacre (whit537) Date: 2006-01-02 12:22 Message: Logged In: YES user_id=340931 Nevermind, that's not how rm behaves. *blush* ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1395442&group_id=5470 From noreply at sourceforge.net Mon Jan 2 20:27:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Jan 2006 11:27:37 -0800 Subject: [ python-Bugs-1395511 ] Please document pyc format guarantees Message-ID: Bugs item #1395511, was opened at 2006-01-02 19: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=1395511&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Joe Wreschnig (piman) Assigned to: Nobody/Anonymous (nobody) Summary: Please document pyc format guarantees Initial Comment: There's conventional wisdom that .pyc files are compatible within a single minor revision of Python, but I can't find any documentation that says this explicitly. This assumption is important to Debian's Python packaging policy, so if it's true, could it be documented somewhere (probably the marshal or compileall module documentation)? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1395511&group_id=5470 From noreply at sourceforge.net Mon Jan 2 22:32:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Jan 2006 13:32:52 -0800 Subject: [ python-Bugs-1394612 ] 'Plus' filemode exposes uninitialized memory on win32 Message-ID: Bugs item #1394612, was opened at 2005-12-31 19:06 Message generated for change (Comment added) made by paul_g You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394612&group_id=5470 Please note that this message will contain 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: Closed Resolution: Invalid Priority: 5 Submitted By: Cory Dodt (corydodt) Assigned to: Nobody/Anonymous (nobody) Summary: 'Plus' filemode exposes uninitialized memory on win32 Initial Comment: (Note: I'm using cygwin zsh, hence the prompts. I am using standard, python.org Python for these tests.) % echo abcdef > foo % python 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. >>> f = file('foo','r+b') >>> f.write('ghi') >>> f.read() '\x00x\x01\x83\x00\xe8\x03\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00e\x00\x00i\x01 \x00d\x00\x00\x83\x01\x00Fd\x01\x00S\x00S\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00[...lots and lots and lots of uninitialized memory deleted...]\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\x00abcdef\n' >>> f.close() >>> ---------------------------------------------------------------------- Comment By: Paul G (paul_g) Date: 2006-01-02 16:32 Message: Logged In: YES user_id=1417712 i think there's a bit of confusion here as to what exactly the problem is. ansi c says that for files fopen()ed for reading and writing (ie r+, w+ etc), you must issue an fflush(), fseek(), fsetpos(), or rewind() between a read and a write. the exception to this is if the read last read EOF. the behaviour we are seeing using python file objects: with glibc: 1. read + write + read result in no data being returned by the last read. this is the case regardless of whether we do f.readlines()+f.writelines()+f.readlines() or f.read()+f.write()+f.read(). this does not comnform to expected behaviour (as per ansi c and glibc fopen(3)), because at least in the latter (read() with no size parameter) case, python docs promise to stop at EOF, triggering the exception ansi c/glibc make to the intervening synchronization with file positioning requirement. with msvscrt: 1. in the f.read()+f.write()+f.read() case, the f.write() generates an IOError. this deviates from ansi c, but is in line with msdn docs. 2. in the f.readlines()+f.writelines()+f.readlines() case, you see the type of results quoted in the bug submission. this deviates from ansi c if you expect readlines() to read EOF, but is still in line with msdn docs. there are 3 issues here: 1. if we give users a high level interface for file i/o, as we do by giving them a File object, should we expect them to research, be aware of and deal with the requirements imposed by the low level implementation used? if it is reasonable to require that when they use read() and write(), is it still reasonable to require it when they user readlines() and writelines()? 2. if we expect users to be aware of ansi c requirements for file stream usage and deal with them, is it reasonable to expect them to deal with the differences in libc implementations, including the differing requirements they impose and differing failure modes being seen? should we not attempt to present an ansi c compliant interface to them, performing workarounds as is necessary on a given platform (or libc make as is the case here)? we certainly do that in some cases (but not in this one) based on my brief reading of Objects/fileobject.c. 3. if we leave users to deal with this mess, should we not at least document this in some fashion? whether it be a detailed explanation or just a pointer to look at the appropriate docs, or even just a mention that they should be reading up on fopen(), since that is the underlying implemention behind file objects. is it reasonable to expect folks for whom python is their first language, as some folks seem to promote python, to figure all of this out when they haven't the foggiest about ansi c? to recap, the real issue, imo, seems to be that we shouldn't be exposing users to this, rather than the funky results of not doing this right. there are 4 options for dealing with this: 1. do nothing (what tim currently fabours, it appears) 2. document this to some extent 3. make this work the same across all libcs 4. perform the syncrhonization (fflush, fsetpos etc depending on libc) for the user, behind the scenes, if we see a write coming in and the previous op was a read. the latter option, from the perspective of "this is exactly what a high level interface should do for the user", makes the most sense to me. but then, maybe that's why i'm not a python core dev ;) cheers, -p ---------------------------------------------------------------------- Comment By: Cory Dodt (corydodt) Date: 2006-01-01 19:43 Message: Logged In: YES user_id=889183 Tim - at a minimum this should be documented; even if it's just a link to the ANSI C documentation. Python is not ANSI C, we shouldn't expect the Python user to seek out ANSI C documentation. Want me to open a separate doc bug? The current doc only says this (about the file builtin): """ Modes 'r+', 'w+' and 'a+' open the file for updating (note that 'w+' truncates the file). Append 'b' to the mode to open the file in binary mode, on systems that differentiate between binary and text files (else it is ignored). If the file cannot be opened, IOError is raised. """ Either here, or perhaps in section 2.3.9, a clear description should be given of how to properly operate a + mode file. Failing that, a pointer to ANSI C documentation so the user can read about it on its own (and so the user knows that this behavior conforms to the underlying platform API in every ugly detail). I'm also dubious that this exposed memory is innocuous, but I'll defer to your expertise on that one. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-01-01 19:24 Message: Logged In: YES user_id=31435 There's nothing Python can do about this short of implementing I/O itself. That isn't likely. If someone is truly bothered by this behavior on Windows (or any other platform), they need to convince Microsoft (or other relevant C vendors) to change _their_ stdio implementation -- Python inherits the platform C's behavior, quirks and all. I'll note that I'm not bothered by it. It's one of those "doctor, doctor, it hurts when I do this!" kinds of pseudo-problems, IMO: so don't do that. It's not like hostile user input can "trick" a Python application into doing I/O operations in an undefined order. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2006-01-01 17:08 Message: Logged In: YES user_id=366566 I think Cory was aware of the underlying requirement to interpose a seek operation between the write and read operations, but was concerned about the consequences of not doing so. Python normally protects one from doing things that are *too* dangerous: I guess it's unclear to him (and perhaps others) whether the current behavior of file is just (relatively) obscure or if it could lead to real problems (exposing sensitive data, crashing the process). It seems like the latter is somewhat unlikely in practice, but since the behavior is unspecified, it seems like it *could* happen. I guess since Tim closed this, he thinks it's not too dangerous. In this case, the documentation could probably stand to be improved somewhat. The section () that documents the various modes which can be used to open a file could updated to include a warning along the lines of that in the C standard. It should probably explicitly state which file methods can be used to satisfy this requirement, since it's not clear otherwise except by reading the implementation of the file type (one could guess, from that file.flush() and file.seek() are suitable, but the documentation for these only says "like stdio ...", so you can't be completely sure). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-01-01 01:06 Message: Logged In: YES user_id=31435 This is actually pilot error (not a bug!), although it's subtle: Python uses the platform C I/O implementation, and in standard C mixing reads with writes yields undefined behavior unless a file-positioning operation (typically a seek()) occurs between switching from reading to writing (or vice versa); here from the C standard: When a file is opened with update mode (???+??? as the second or third character in the above list of mode argument values), both input and output may be performed on the associated stream. However, output shall not be directly followed by input without an intervening call to the fflush function or to a file positioning function (fseek, fsetpos, or rewind), and input shall not be directly followed by output without an intervening call to a file positioning function, unless the input operation encounters end-of-file. In other words, the result of running your sample code is undefined: nothing is guaranteed about its behavior, which both can and does vary across platforms. If you want defined behavior, then, for example, add >>> f.seek(0) between your write() and read() calls. ---------------------------------------------------------------------- Comment By: Clinton Roy (clintonroy) Date: 2006-01-01 00:38 Message: Logged In: YES user_id=31446 Hi Cory, I don't think r+ mode will create the file if it doesn't exist, so at a guess I think what you're seeing is the actual contents of a file named foo that are on the disk, not junk. If you delete the file foo and run your test again, you should get an error to that effect. cheers, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394612&group_id=5470 From noreply at sourceforge.net Mon Jan 2 22:58:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Jan 2006 13:58:43 -0800 Subject: [ python-Bugs-1395597 ] module os, very small doc inconsistency Message-ID: Bugs item #1395597, was opened at 2006-01-02 22: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=1395597&group_id=5470 Please note that this 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: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: tiissa (tiissa) Assigned to: Nobody/Anonymous (nobody) Summary: module os, very small doc inconsistency Initial Comment: In the description of function mknod of module os, the name of the node is called "filename", whereas the argument of mknod in the prototype is called "path". I join a patch changing path in filename (to be consistent with the inline doc). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1395597&group_id=5470 From noreply at sourceforge.net Mon Jan 2 23:00:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Jan 2006 14:00:16 -0800 Subject: [ python-Bugs-1395597 ] module os, very small doc inconsistency Message-ID: Bugs item #1395597, was opened at 2006-01-02 22:58 Message generated for change (Settings changed) made by tiissa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1395597&group_id=5470 Please note that this 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: Not a Bug Status: Open Resolution: None >Priority: 1 Submitted By: tiissa (tiissa) Assigned to: Nobody/Anonymous (nobody) Summary: module os, very small doc inconsistency Initial Comment: In the description of function mknod of module os, the name of the node is called "filename", whereas the argument of mknod in the prototype is called "path". I join a patch changing path in filename (to be consistent with the inline doc). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1395597&group_id=5470 From noreply at sourceforge.net Mon Jan 2 23:07:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Jan 2006 14:07:55 -0800 Subject: [ python-Bugs-1395597 ] module os, very small doc inconsistency Message-ID: Bugs item #1395597, was opened at 2006-01-02 22:58 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1395597&group_id=5470 Please note that this 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: Not a Bug >Status: Closed >Resolution: Fixed Priority: 1 Submitted By: tiissa (tiissa) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: module os, very small doc inconsistency Initial Comment: In the description of function mknod of module os, the name of the node is called "filename", whereas the argument of mknod in the prototype is called "path". I join a patch changing path in filename (to be consistent with the inline doc). ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2006-01-02 23:07 Message: Logged In: YES user_id=1188172 I love priority 1 bugs! Corrected in revision 41881, 41882. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1395597&group_id=5470 From noreply at sourceforge.net Mon Jan 2 23:09:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Jan 2006 14:09:32 -0800 Subject: [ python-Bugs-959576 ] Can't build Python on POSIX w/o $HOME Message-ID: Bugs item #959576, was opened at 2004-05-24 19:16 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=959576&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 >Status: Open Resolution: Fixed Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) >Assigned to: Nobody/Anonymous (nobody) Summary: Can't build Python on POSIX w/o $HOME Initial Comment: If you're building Python on os.name == 'posix' but when there is no $HOME defined in your environment, you cannot build Python. This is because in the bowels of distutils, you end up in check_environ(), which has these lines: if os.name == 'posix' and not os.environ.has_key('HOME'): import pwd os.environ['HOME'] = pwd.getpwuid(os.getuid())[5] However, in a from-scratch build, the pwd module isn't built by the time you get here. I found this when using SCons to build Python, since by default the enclosing environment isn't passed to subprocesses. I can work around this in my builds but Python's setup.py should probably synthesize a $HOME if one doesn't exist. (Or maybe someone has a better idea for a workaround). ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2006-01-02 23:09 Message: Logged In: YES user_id=1188172 Guido said: """ Hm. Methinks that the distutils code should have been patched to survive the possibility of "import pwd" failing (or pwd.getpwuid() failing!) rather than hiding the problem by forcing pwd to be built. The latter seems a much less robust solution. """ Who is responsible for distutils? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 18:37 Message: Logged In: YES user_id=1188172 I made the suggested change in revision 41834/41835. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-10-02 10:57 Message: Logged In: YES user_id=21627 Making pwd builtin is fine with me. Make sure you move the line to the other builtin modules, and add a comment telling why it is need (i.e. when HOME isn't set). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 22:04 Message: Logged In: YES user_id=1188172 Well, pwd will be built-in then, if that's a problem. Assigning to loewis to look over it. ---------------------------------------------------------------------- Comment By: John Hein (jhein-sf) Date: 2005-09-29 21:28 Message: Logged In: YES user_id=59465 Let me revise that last comment. There are some build differences when this is done. Uncommenting pwd in Setup.dist allows python to build, but the 'pwd' extension (and pwd.so) does not get built. And pwdmodule.o is ar'd into libpython2.4.a (& linked into libpython2.4.so) ---------------------------------------------------------------------- Comment By: John Hein (jhein-sf) Date: 2005-09-29 21:14 Message: Logged In: YES user_id=59465 I had this problem, too. The fix proposed by birkenfeld on 9/22 works for me. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-22 09:19 Message: Logged In: YES user_id=1188172 Seems that the pwdmodule entry in Modules/Setup.dist must be uncommented. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=959576&group_id=5470 From noreply at sourceforge.net Mon Jan 2 23:11:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Jan 2006 14:11:14 -0800 Subject: [ python-Bugs-959576 ] Can't build Python on POSIX w/o $HOME Message-ID: Bugs item #959576, was opened at 2004-05-24 19:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=959576&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: Fixed Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Nobody/Anonymous (nobody) Summary: Can't build Python on POSIX w/o $HOME Initial Comment: If you're building Python on os.name == 'posix' but when there is no $HOME defined in your environment, you cannot build Python. This is because in the bowels of distutils, you end up in check_environ(), which has these lines: if os.name == 'posix' and not os.environ.has_key('HOME'): import pwd os.environ['HOME'] = pwd.getpwuid(os.getuid())[5] However, in a from-scratch build, the pwd module isn't built by the time you get here. I found this when using SCons to build Python, since by default the enclosing environment isn't passed to subprocesses. I can work around this in my builds but Python's setup.py should probably synthesize a $HOME if one doesn't exist. (Or maybe someone has a better idea for a workaround). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-01-02 23:11 Message: Logged In: YES user_id=21627 There isn't a specific maintainer for distutils; it's nearly unmaintained. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2006-01-02 23:09 Message: Logged In: YES user_id=1188172 Guido said: """ Hm. Methinks that the distutils code should have been patched to survive the possibility of "import pwd" failing (or pwd.getpwuid() failing!) rather than hiding the problem by forcing pwd to be built. The latter seems a much less robust solution. """ Who is responsible for distutils? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 18:37 Message: Logged In: YES user_id=1188172 I made the suggested change in revision 41834/41835. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-10-02 10:57 Message: Logged In: YES user_id=21627 Making pwd builtin is fine with me. Make sure you move the line to the other builtin modules, and add a comment telling why it is need (i.e. when HOME isn't set). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 22:04 Message: Logged In: YES user_id=1188172 Well, pwd will be built-in then, if that's a problem. Assigning to loewis to look over it. ---------------------------------------------------------------------- Comment By: John Hein (jhein-sf) Date: 2005-09-29 21:28 Message: Logged In: YES user_id=59465 Let me revise that last comment. There are some build differences when this is done. Uncommenting pwd in Setup.dist allows python to build, but the 'pwd' extension (and pwd.so) does not get built. And pwdmodule.o is ar'd into libpython2.4.a (& linked into libpython2.4.so) ---------------------------------------------------------------------- Comment By: John Hein (jhein-sf) Date: 2005-09-29 21:14 Message: Logged In: YES user_id=59465 I had this problem, too. The fix proposed by birkenfeld on 9/22 works for me. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-22 09:19 Message: Logged In: YES user_id=1188172 Seems that the pwdmodule entry in Modules/Setup.dist must be uncommented. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=959576&group_id=5470 From noreply at sourceforge.net Mon Jan 2 23:15:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Jan 2006 14:15:05 -0800 Subject: [ python-Bugs-959576 ] Can't build Python on POSIX w/o $HOME Message-ID: Bugs item #959576, was opened at 2004-05-24 19:16 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=959576&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: Fixed Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Nobody/Anonymous (nobody) Summary: Can't build Python on POSIX w/o $HOME Initial Comment: If you're building Python on os.name == 'posix' but when there is no $HOME defined in your environment, you cannot build Python. This is because in the bowels of distutils, you end up in check_environ(), which has these lines: if os.name == 'posix' and not os.environ.has_key('HOME'): import pwd os.environ['HOME'] = pwd.getpwuid(os.getuid())[5] However, in a from-scratch build, the pwd module isn't built by the time you get here. I found this when using SCons to build Python, since by default the enclosing environment isn't passed to subprocesses. I can work around this in my builds but Python's setup.py should probably synthesize a $HOME if one doesn't exist. (Or maybe someone has a better idea for a workaround). ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2006-01-02 23:15 Message: Logged In: YES user_id=1188172 Okay, so I think I'll leave the fix in for the time being. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-01-02 23:11 Message: Logged In: YES user_id=21627 There isn't a specific maintainer for distutils; it's nearly unmaintained. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2006-01-02 23:09 Message: Logged In: YES user_id=1188172 Guido said: """ Hm. Methinks that the distutils code should have been patched to survive the possibility of "import pwd" failing (or pwd.getpwuid() failing!) rather than hiding the problem by forcing pwd to be built. The latter seems a much less robust solution. """ Who is responsible for distutils? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-27 18:37 Message: Logged In: YES user_id=1188172 I made the suggested change in revision 41834/41835. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-10-02 10:57 Message: Logged In: YES user_id=21627 Making pwd builtin is fine with me. Make sure you move the line to the other builtin modules, and add a comment telling why it is need (i.e. when HOME isn't set). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 22:04 Message: Logged In: YES user_id=1188172 Well, pwd will be built-in then, if that's a problem. Assigning to loewis to look over it. ---------------------------------------------------------------------- Comment By: John Hein (jhein-sf) Date: 2005-09-29 21:28 Message: Logged In: YES user_id=59465 Let me revise that last comment. There are some build differences when this is done. Uncommenting pwd in Setup.dist allows python to build, but the 'pwd' extension (and pwd.so) does not get built. And pwdmodule.o is ar'd into libpython2.4.a (& linked into libpython2.4.so) ---------------------------------------------------------------------- Comment By: John Hein (jhein-sf) Date: 2005-09-29 21:14 Message: Logged In: YES user_id=59465 I had this problem, too. The fix proposed by birkenfeld on 9/22 works for me. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-22 09:19 Message: Logged In: YES user_id=1188172 Seems that the pwdmodule entry in Modules/Setup.dist must be uncommented. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=959576&group_id=5470 From noreply at sourceforge.net Tue Jan 3 01:08:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Jan 2006 16:08:44 -0800 Subject: [ python-Bugs-1394612 ] 'Plus' filemode exposes uninitialized memory on win32 Message-ID: Bugs item #1394612, was opened at 2005-12-31 19:06 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394612&group_id=5470 Please note that this message will contain 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: Closed Resolution: Invalid Priority: 5 Submitted By: Cory Dodt (corydodt) Assigned to: Nobody/Anonymous (nobody) Summary: 'Plus' filemode exposes uninitialized memory on win32 Initial Comment: (Note: I'm using cygwin zsh, hence the prompts. I am using standard, python.org Python for these tests.) % echo abcdef > foo % python 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. >>> f = file('foo','r+b') >>> f.write('ghi') >>> f.read() '\x00x\x01\x83\x00\xe8\x03\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00e\x00\x00i\x01 \x00d\x00\x00\x83\x01\x00Fd\x01\x00S\x00S\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00[...lots and lots and lots of uninitialized memory deleted...]\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\x00abcdef\n' >>> f.close() >>> ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-01-02 19:08 Message: Logged In: YES user_id=31435 paul_g's option #1 is the only that takes no work, so is the only one I'm volunteering for <0.5 wink>. Docs would be good. #4 is in general impossible short of Python implementing its own I/O -- "the last" operation done on a C stream isn't necessarily visible to the Python implementation (extensions can and do perform their own I/O on C streams directly via platform C stdio calls -- Python has no way to know about that now even in theory). BTW, I don't understand: """1. in the f.read()+f.write()+f.read() case, the f.write() generates an IOError. this deviates from ansi c, but is in line with msdn docs.""" All behavior in that case is explicitly not defined by ANSI C if there isn't a file-positioning operation too between the read() and write(), and again between the write() and read(). Raising an exception is fine by ANSI C in that case. So is a segfault. So is reading nothing, or reading a terabtye, or wiping the disk clean, etc: nothing is defined about it. ---------------------------------------------------------------------- Comment By: Paul G (paul_g) Date: 2006-01-02 16:32 Message: Logged In: YES user_id=1417712 i think there's a bit of confusion here as to what exactly the problem is. ansi c says that for files fopen()ed for reading and writing (ie r+, w+ etc), you must issue an fflush(), fseek(), fsetpos(), or rewind() between a read and a write. the exception to this is if the read last read EOF. the behaviour we are seeing using python file objects: with glibc: 1. read + write + read result in no data being returned by the last read. this is the case regardless of whether we do f.readlines()+f.writelines()+f.readlines() or f.read()+f.write()+f.read(). this does not comnform to expected behaviour (as per ansi c and glibc fopen(3)), because at least in the latter (read() with no size parameter) case, python docs promise to stop at EOF, triggering the exception ansi c/glibc make to the intervening synchronization with file positioning requirement. with msvscrt: 1. in the f.read()+f.write()+f.read() case, the f.write() generates an IOError. this deviates from ansi c, but is in line with msdn docs. 2. in the f.readlines()+f.writelines()+f.readlines() case, you see the type of results quoted in the bug submission. this deviates from ansi c if you expect readlines() to read EOF, but is still in line with msdn docs. there are 3 issues here: 1. if we give users a high level interface for file i/o, as we do by giving them a File object, should we expect them to research, be aware of and deal with the requirements imposed by the low level implementation used? if it is reasonable to require that when they use read() and write(), is it still reasonable to require it when they user readlines() and writelines()? 2. if we expect users to be aware of ansi c requirements for file stream usage and deal with them, is it reasonable to expect them to deal with the differences in libc implementations, including the differing requirements they impose and differing failure modes being seen? should we not attempt to present an ansi c compliant interface to them, performing workarounds as is necessary on a given platform (or libc make as is the case here)? we certainly do that in some cases (but not in this one) based on my brief reading of Objects/fileobject.c. 3. if we leave users to deal with this mess, should we not at least document this in some fashion? whether it be a detailed explanation or just a pointer to look at the appropriate docs, or even just a mention that they should be reading up on fopen(), since that is the underlying implemention behind file objects. is it reasonable to expect folks for whom python is their first language, as some folks seem to promote python, to figure all of this out when they haven't the foggiest about ansi c? to recap, the real issue, imo, seems to be that we shouldn't be exposing users to this, rather than the funky results of not doing this right. there are 4 options for dealing with this: 1. do nothing (what tim currently fabours, it appears) 2. document this to some extent 3. make this work the same across all libcs 4. perform the syncrhonization (fflush, fsetpos etc depending on libc) for the user, behind the scenes, if we see a write coming in and the previous op was a read. the latter option, from the perspective of "this is exactly what a high level interface should do for the user", makes the most sense to me. but then, maybe that's why i'm not a python core dev ;) cheers, -p ---------------------------------------------------------------------- Comment By: Cory Dodt (corydodt) Date: 2006-01-01 19:43 Message: Logged In: YES user_id=889183 Tim - at a minimum this should be documented; even if it's just a link to the ANSI C documentation. Python is not ANSI C, we shouldn't expect the Python user to seek out ANSI C documentation. Want me to open a separate doc bug? The current doc only says this (about the file builtin): """ Modes 'r+', 'w+' and 'a+' open the file for updating (note that 'w+' truncates the file). Append 'b' to the mode to open the file in binary mode, on systems that differentiate between binary and text files (else it is ignored). If the file cannot be opened, IOError is raised. """ Either here, or perhaps in section 2.3.9, a clear description should be given of how to properly operate a + mode file. Failing that, a pointer to ANSI C documentation so the user can read about it on its own (and so the user knows that this behavior conforms to the underlying platform API in every ugly detail). I'm also dubious that this exposed memory is innocuous, but I'll defer to your expertise on that one. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-01-01 19:24 Message: Logged In: YES user_id=31435 There's nothing Python can do about this short of implementing I/O itself. That isn't likely. If someone is truly bothered by this behavior on Windows (or any other platform), they need to convince Microsoft (or other relevant C vendors) to change _their_ stdio implementation -- Python inherits the platform C's behavior, quirks and all. I'll note that I'm not bothered by it. It's one of those "doctor, doctor, it hurts when I do this!" kinds of pseudo-problems, IMO: so don't do that. It's not like hostile user input can "trick" a Python application into doing I/O operations in an undefined order. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2006-01-01 17:08 Message: Logged In: YES user_id=366566 I think Cory was aware of the underlying requirement to interpose a seek operation between the write and read operations, but was concerned about the consequences of not doing so. Python normally protects one from doing things that are *too* dangerous: I guess it's unclear to him (and perhaps others) whether the current behavior of file is just (relatively) obscure or if it could lead to real problems (exposing sensitive data, crashing the process). It seems like the latter is somewhat unlikely in practice, but since the behavior is unspecified, it seems like it *could* happen. I guess since Tim closed this, he thinks it's not too dangerous. In this case, the documentation could probably stand to be improved somewhat. The section () that documents the various modes which can be used to open a file could updated to include a warning along the lines of that in the C standard. It should probably explicitly state which file methods can be used to satisfy this requirement, since it's not clear otherwise except by reading the implementation of the file type (one could guess, from that file.flush() and file.seek() are suitable, but the documentation for these only says "like stdio ...", so you can't be completely sure). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-01-01 01:06 Message: Logged In: YES user_id=31435 This is actually pilot error (not a bug!), although it's subtle: Python uses the platform C I/O implementation, and in standard C mixing reads with writes yields undefined behavior unless a file-positioning operation (typically a seek()) occurs between switching from reading to writing (or vice versa); here from the C standard: When a file is opened with update mode (???+??? as the second or third character in the above list of mode argument values), both input and output may be performed on the associated stream. However, output shall not be directly followed by input without an intervening call to the fflush function or to a file positioning function (fseek, fsetpos, or rewind), and input shall not be directly followed by output without an intervening call to a file positioning function, unless the input operation encounters end-of-file. In other words, the result of running your sample code is undefined: nothing is guaranteed about its behavior, which both can and does vary across platforms. If you want defined behavior, then, for example, add >>> f.seek(0) between your write() and read() calls. ---------------------------------------------------------------------- Comment By: Clinton Roy (clintonroy) Date: 2006-01-01 00:38 Message: Logged In: YES user_id=31446 Hi Cory, I don't think r+ mode will create the file if it doesn't exist, so at a guess I think what you're seeing is the actual contents of a file named foo that are on the disk, not junk. If you delete the file foo and run your test again, you should get an error to that effect. cheers, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394612&group_id=5470 From noreply at sourceforge.net Tue Jan 3 01:22:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Jan 2006 16:22:35 -0800 Subject: [ python-Bugs-1394612 ] 'Plus' filemode exposes uninitialized memory on win32 Message-ID: Bugs item #1394612, was opened at 2005-12-31 19:06 Message generated for change (Comment added) made by paul_g You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394612&group_id=5470 Please note that this message will contain 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: Closed Resolution: Invalid Priority: 5 Submitted By: Cory Dodt (corydodt) Assigned to: Nobody/Anonymous (nobody) Summary: 'Plus' filemode exposes uninitialized memory on win32 Initial Comment: (Note: I'm using cygwin zsh, hence the prompts. I am using standard, python.org Python for these tests.) % echo abcdef > foo % python 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. >>> f = file('foo','r+b') >>> f.write('ghi') >>> f.read() '\x00x\x01\x83\x00\xe8\x03\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00e\x00\x00i\x01 \x00d\x00\x00\x83\x01\x00Fd\x01\x00S\x00S\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00[...lots and lots and lots of uninitialized memory deleted...]\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\x00abcdef\n' >>> f.close() >>> ---------------------------------------------------------------------- Comment By: Paul G (paul_g) Date: 2006-01-02 19:22 Message: Logged In: YES user_id=1417712 i'll comment about the rest later, but re not understanding: here is what ansi says: "If the file has been opened for read/write, a read may not be followed by a write. Or vice versa, without first calling either fflush(), fseek(), fsetpos(), or rewind(). Unless EOF was the last character read by fread(). " note the last sentence. python docs say that f.read() with no size parameter will read all data until it hits EOF. this means that any ansi c compliant implementation should perform synchronization when you fread() an EOF. glibc fopen(3) man page states that it follows this; it does not. msvscrt docs do not state that it follows this; it does not. so glibc promises ansi c compliance, but does not deliver. msvscrt does not promise ansi c compliance and doesn't deliver either, but at least it behaves as advertised in this respect. make sense? -p ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-01-02 19:08 Message: Logged In: YES user_id=31435 paul_g's option #1 is the only that takes no work, so is the only one I'm volunteering for <0.5 wink>. Docs would be good. #4 is in general impossible short of Python implementing its own I/O -- "the last" operation done on a C stream isn't necessarily visible to the Python implementation (extensions can and do perform their own I/O on C streams directly via platform C stdio calls -- Python has no way to know about that now even in theory). BTW, I don't understand: """1. in the f.read()+f.write()+f.read() case, the f.write() generates an IOError. this deviates from ansi c, but is in line with msdn docs.""" All behavior in that case is explicitly not defined by ANSI C if there isn't a file-positioning operation too between the read() and write(), and again between the write() and read(). Raising an exception is fine by ANSI C in that case. So is a segfault. So is reading nothing, or reading a terabtye, or wiping the disk clean, etc: nothing is defined about it. ---------------------------------------------------------------------- Comment By: Paul G (paul_g) Date: 2006-01-02 16:32 Message: Logged In: YES user_id=1417712 i think there's a bit of confusion here as to what exactly the problem is. ansi c says that for files fopen()ed for reading and writing (ie r+, w+ etc), you must issue an fflush(), fseek(), fsetpos(), or rewind() between a read and a write. the exception to this is if the read last read EOF. the behaviour we are seeing using python file objects: with glibc: 1. read + write + read result in no data being returned by the last read. this is the case regardless of whether we do f.readlines()+f.writelines()+f.readlines() or f.read()+f.write()+f.read(). this does not comnform to expected behaviour (as per ansi c and glibc fopen(3)), because at least in the latter (read() with no size parameter) case, python docs promise to stop at EOF, triggering the exception ansi c/glibc make to the intervening synchronization with file positioning requirement. with msvscrt: 1. in the f.read()+f.write()+f.read() case, the f.write() generates an IOError. this deviates from ansi c, but is in line with msdn docs. 2. in the f.readlines()+f.writelines()+f.readlines() case, you see the type of results quoted in the bug submission. this deviates from ansi c if you expect readlines() to read EOF, but is still in line with msdn docs. there are 3 issues here: 1. if we give users a high level interface for file i/o, as we do by giving them a File object, should we expect them to research, be aware of and deal with the requirements imposed by the low level implementation used? if it is reasonable to require that when they use read() and write(), is it still reasonable to require it when they user readlines() and writelines()? 2. if we expect users to be aware of ansi c requirements for file stream usage and deal with them, is it reasonable to expect them to deal with the differences in libc implementations, including the differing requirements they impose and differing failure modes being seen? should we not attempt to present an ansi c compliant interface to them, performing workarounds as is necessary on a given platform (or libc make as is the case here)? we certainly do that in some cases (but not in this one) based on my brief reading of Objects/fileobject.c. 3. if we leave users to deal with this mess, should we not at least document this in some fashion? whether it be a detailed explanation or just a pointer to look at the appropriate docs, or even just a mention that they should be reading up on fopen(), since that is the underlying implemention behind file objects. is it reasonable to expect folks for whom python is their first language, as some folks seem to promote python, to figure all of this out when they haven't the foggiest about ansi c? to recap, the real issue, imo, seems to be that we shouldn't be exposing users to this, rather than the funky results of not doing this right. there are 4 options for dealing with this: 1. do nothing (what tim currently fabours, it appears) 2. document this to some extent 3. make this work the same across all libcs 4. perform the syncrhonization (fflush, fsetpos etc depending on libc) for the user, behind the scenes, if we see a write coming in and the previous op was a read. the latter option, from the perspective of "this is exactly what a high level interface should do for the user", makes the most sense to me. but then, maybe that's why i'm not a python core dev ;) cheers, -p ---------------------------------------------------------------------- Comment By: Cory Dodt (corydodt) Date: 2006-01-01 19:43 Message: Logged In: YES user_id=889183 Tim - at a minimum this should be documented; even if it's just a link to the ANSI C documentation. Python is not ANSI C, we shouldn't expect the Python user to seek out ANSI C documentation. Want me to open a separate doc bug? The current doc only says this (about the file builtin): """ Modes 'r+', 'w+' and 'a+' open the file for updating (note that 'w+' truncates the file). Append 'b' to the mode to open the file in binary mode, on systems that differentiate between binary and text files (else it is ignored). If the file cannot be opened, IOError is raised. """ Either here, or perhaps in section 2.3.9, a clear description should be given of how to properly operate a + mode file. Failing that, a pointer to ANSI C documentation so the user can read about it on its own (and so the user knows that this behavior conforms to the underlying platform API in every ugly detail). I'm also dubious that this exposed memory is innocuous, but I'll defer to your expertise on that one. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-01-01 19:24 Message: Logged In: YES user_id=31435 There's nothing Python can do about this short of implementing I/O itself. That isn't likely. If someone is truly bothered by this behavior on Windows (or any other platform), they need to convince Microsoft (or other relevant C vendors) to change _their_ stdio implementation -- Python inherits the platform C's behavior, quirks and all. I'll note that I'm not bothered by it. It's one of those "doctor, doctor, it hurts when I do this!" kinds of pseudo-problems, IMO: so don't do that. It's not like hostile user input can "trick" a Python application into doing I/O operations in an undefined order. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2006-01-01 17:08 Message: Logged In: YES user_id=366566 I think Cory was aware of the underlying requirement to interpose a seek operation between the write and read operations, but was concerned about the consequences of not doing so. Python normally protects one from doing things that are *too* dangerous: I guess it's unclear to him (and perhaps others) whether the current behavior of file is just (relatively) obscure or if it could lead to real problems (exposing sensitive data, crashing the process). It seems like the latter is somewhat unlikely in practice, but since the behavior is unspecified, it seems like it *could* happen. I guess since Tim closed this, he thinks it's not too dangerous. In this case, the documentation could probably stand to be improved somewhat. The section () that documents the various modes which can be used to open a file could updated to include a warning along the lines of that in the C standard. It should probably explicitly state which file methods can be used to satisfy this requirement, since it's not clear otherwise except by reading the implementation of the file type (one could guess, from that file.flush() and file.seek() are suitable, but the documentation for these only says "like stdio ...", so you can't be completely sure). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-01-01 01:06 Message: Logged In: YES user_id=31435 This is actually pilot error (not a bug!), although it's subtle: Python uses the platform C I/O implementation, and in standard C mixing reads with writes yields undefined behavior unless a file-positioning operation (typically a seek()) occurs between switching from reading to writing (or vice versa); here from the C standard: When a file is opened with update mode (???+??? as the second or third character in the above list of mode argument values), both input and output may be performed on the associated stream. However, output shall not be directly followed by input without an intervening call to the fflush function or to a file positioning function (fseek, fsetpos, or rewind), and input shall not be directly followed by output without an intervening call to a file positioning function, unless the input operation encounters end-of-file. In other words, the result of running your sample code is undefined: nothing is guaranteed about its behavior, which both can and does vary across platforms. If you want defined behavior, then, for example, add >>> f.seek(0) between your write() and read() calls. ---------------------------------------------------------------------- Comment By: Clinton Roy (clintonroy) Date: 2006-01-01 00:38 Message: Logged In: YES user_id=31446 Hi Cory, I don't think r+ mode will create the file if it doesn't exist, so at a guess I think what you're seeing is the actual contents of a file named foo that are on the disk, not junk. If you delete the file foo and run your test again, you should get an error to that effect. cheers, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394612&group_id=5470 From noreply at sourceforge.net Tue Jan 3 01:55:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Jan 2006 16:55:06 -0800 Subject: [ python-Bugs-1394612 ] 'Plus' filemode exposes uninitialized memory on win32 Message-ID: Bugs item #1394612, was opened at 2005-12-31 19:06 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394612&group_id=5470 Please note that this message will contain 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: Closed Resolution: Invalid Priority: 5 Submitted By: Cory Dodt (corydodt) Assigned to: Nobody/Anonymous (nobody) Summary: 'Plus' filemode exposes uninitialized memory on win32 Initial Comment: (Note: I'm using cygwin zsh, hence the prompts. I am using standard, python.org Python for these tests.) % echo abcdef > foo % python 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. >>> f = file('foo','r+b') >>> f.write('ghi') >>> f.read() '\x00x\x01\x83\x00\xe8\x03\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00e\x00\x00i\x01 \x00d\x00\x00\x83\x01\x00Fd\x01\x00S\x00S\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00[...lots and lots and lots of uninitialized memory deleted...]\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\x00abcdef\n' >>> f.close() >>> ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-01-02 19:55 Message: Logged In: YES user_id=31435 "make sense?" So far as it goes, yes -- thanks. At a higher level ;-), I've been slinging Python for 15 years and have never had any trouble with this stuff because I never push on the end cases (I always seek when switching between reading and writing, even if only by using the peculiar- looking f.seek(f.tell()), and regardless of the platform du jour). Pushing beyond that doesn't interest me. Note that Python's file_read() (in fileobject.c) is already much more complicated than simply calling C's fread(). Because of this, it may be that Python is adding strange end case behavior beyond what the platform C would exhibit if the latter were used directly. ---------------------------------------------------------------------- Comment By: Paul G (paul_g) Date: 2006-01-02 19:22 Message: Logged In: YES user_id=1417712 i'll comment about the rest later, but re not understanding: here is what ansi says: "If the file has been opened for read/write, a read may not be followed by a write. Or vice versa, without first calling either fflush(), fseek(), fsetpos(), or rewind(). Unless EOF was the last character read by fread(). " note the last sentence. python docs say that f.read() with no size parameter will read all data until it hits EOF. this means that any ansi c compliant implementation should perform synchronization when you fread() an EOF. glibc fopen(3) man page states that it follows this; it does not. msvscrt docs do not state that it follows this; it does not. so glibc promises ansi c compliance, but does not deliver. msvscrt does not promise ansi c compliance and doesn't deliver either, but at least it behaves as advertised in this respect. make sense? -p ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-01-02 19:08 Message: Logged In: YES user_id=31435 paul_g's option #1 is the only that takes no work, so is the only one I'm volunteering for <0.5 wink>. Docs would be good. #4 is in general impossible short of Python implementing its own I/O -- "the last" operation done on a C stream isn't necessarily visible to the Python implementation (extensions can and do perform their own I/O on C streams directly via platform C stdio calls -- Python has no way to know about that now even in theory). BTW, I don't understand: """1. in the f.read()+f.write()+f.read() case, the f.write() generates an IOError. this deviates from ansi c, but is in line with msdn docs.""" All behavior in that case is explicitly not defined by ANSI C if there isn't a file-positioning operation too between the read() and write(), and again between the write() and read(). Raising an exception is fine by ANSI C in that case. So is a segfault. So is reading nothing, or reading a terabtye, or wiping the disk clean, etc: nothing is defined about it. ---------------------------------------------------------------------- Comment By: Paul G (paul_g) Date: 2006-01-02 16:32 Message: Logged In: YES user_id=1417712 i think there's a bit of confusion here as to what exactly the problem is. ansi c says that for files fopen()ed for reading and writing (ie r+, w+ etc), you must issue an fflush(), fseek(), fsetpos(), or rewind() between a read and a write. the exception to this is if the read last read EOF. the behaviour we are seeing using python file objects: with glibc: 1. read + write + read result in no data being returned by the last read. this is the case regardless of whether we do f.readlines()+f.writelines()+f.readlines() or f.read()+f.write()+f.read(). this does not comnform to expected behaviour (as per ansi c and glibc fopen(3)), because at least in the latter (read() with no size parameter) case, python docs promise to stop at EOF, triggering the exception ansi c/glibc make to the intervening synchronization with file positioning requirement. with msvscrt: 1. in the f.read()+f.write()+f.read() case, the f.write() generates an IOError. this deviates from ansi c, but is in line with msdn docs. 2. in the f.readlines()+f.writelines()+f.readlines() case, you see the type of results quoted in the bug submission. this deviates from ansi c if you expect readlines() to read EOF, but is still in line with msdn docs. there are 3 issues here: 1. if we give users a high level interface for file i/o, as we do by giving them a File object, should we expect them to research, be aware of and deal with the requirements imposed by the low level implementation used? if it is reasonable to require that when they use read() and write(), is it still reasonable to require it when they user readlines() and writelines()? 2. if we expect users to be aware of ansi c requirements for file stream usage and deal with them, is it reasonable to expect them to deal with the differences in libc implementations, including the differing requirements they impose and differing failure modes being seen? should we not attempt to present an ansi c compliant interface to them, performing workarounds as is necessary on a given platform (or libc make as is the case here)? we certainly do that in some cases (but not in this one) based on my brief reading of Objects/fileobject.c. 3. if we leave users to deal with this mess, should we not at least document this in some fashion? whether it be a detailed explanation or just a pointer to look at the appropriate docs, or even just a mention that they should be reading up on fopen(), since that is the underlying implemention behind file objects. is it reasonable to expect folks for whom python is their first language, as some folks seem to promote python, to figure all of this out when they haven't the foggiest about ansi c? to recap, the real issue, imo, seems to be that we shouldn't be exposing users to this, rather than the funky results of not doing this right. there are 4 options for dealing with this: 1. do nothing (what tim currently fabours, it appears) 2. document this to some extent 3. make this work the same across all libcs 4. perform the syncrhonization (fflush, fsetpos etc depending on libc) for the user, behind the scenes, if we see a write coming in and the previous op was a read. the latter option, from the perspective of "this is exactly what a high level interface should do for the user", makes the most sense to me. but then, maybe that's why i'm not a python core dev ;) cheers, -p ---------------------------------------------------------------------- Comment By: Cory Dodt (corydodt) Date: 2006-01-01 19:43 Message: Logged In: YES user_id=889183 Tim - at a minimum this should be documented; even if it's just a link to the ANSI C documentation. Python is not ANSI C, we shouldn't expect the Python user to seek out ANSI C documentation. Want me to open a separate doc bug? The current doc only says this (about the file builtin): """ Modes 'r+', 'w+' and 'a+' open the file for updating (note that 'w+' truncates the file). Append 'b' to the mode to open the file in binary mode, on systems that differentiate between binary and text files (else it is ignored). If the file cannot be opened, IOError is raised. """ Either here, or perhaps in section 2.3.9, a clear description should be given of how to properly operate a + mode file. Failing that, a pointer to ANSI C documentation so the user can read about it on its own (and so the user knows that this behavior conforms to the underlying platform API in every ugly detail). I'm also dubious that this exposed memory is innocuous, but I'll defer to your expertise on that one. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-01-01 19:24 Message: Logged In: YES user_id=31435 There's nothing Python can do about this short of implementing I/O itself. That isn't likely. If someone is truly bothered by this behavior on Windows (or any other platform), they need to convince Microsoft (or other relevant C vendors) to change _their_ stdio implementation -- Python inherits the platform C's behavior, quirks and all. I'll note that I'm not bothered by it. It's one of those "doctor, doctor, it hurts when I do this!" kinds of pseudo-problems, IMO: so don't do that. It's not like hostile user input can "trick" a Python application into doing I/O operations in an undefined order. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2006-01-01 17:08 Message: Logged In: YES user_id=366566 I think Cory was aware of the underlying requirement to interpose a seek operation between the write and read operations, but was concerned about the consequences of not doing so. Python normally protects one from doing things that are *too* dangerous: I guess it's unclear to him (and perhaps others) whether the current behavior of file is just (relatively) obscure or if it could lead to real problems (exposing sensitive data, crashing the process). It seems like the latter is somewhat unlikely in practice, but since the behavior is unspecified, it seems like it *could* happen. I guess since Tim closed this, he thinks it's not too dangerous. In this case, the documentation could probably stand to be improved somewhat. The section () that documents the various modes which can be used to open a file could updated to include a warning along the lines of that in the C standard. It should probably explicitly state which file methods can be used to satisfy this requirement, since it's not clear otherwise except by reading the implementation of the file type (one could guess, from that file.flush() and file.seek() are suitable, but the documentation for these only says "like stdio ...", so you can't be completely sure). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-01-01 01:06 Message: Logged In: YES user_id=31435 This is actually pilot error (not a bug!), although it's subtle: Python uses the platform C I/O implementation, and in standard C mixing reads with writes yields undefined behavior unless a file-positioning operation (typically a seek()) occurs between switching from reading to writing (or vice versa); here from the C standard: When a file is opened with update mode (???+??? as the second or third character in the above list of mode argument values), both input and output may be performed on the associated stream. However, output shall not be directly followed by input without an intervening call to the fflush function or to a file positioning function (fseek, fsetpos, or rewind), and input shall not be directly followed by output without an intervening call to a file positioning function, unless the input operation encounters end-of-file. In other words, the result of running your sample code is undefined: nothing is guaranteed about its behavior, which both can and does vary across platforms. If you want defined behavior, then, for example, add >>> f.seek(0) between your write() and read() calls. ---------------------------------------------------------------------- Comment By: Clinton Roy (clintonroy) Date: 2006-01-01 00:38 Message: Logged In: YES user_id=31446 Hi Cory, I don't think r+ mode will create the file if it doesn't exist, so at a guess I think what you're seeing is the actual contents of a file named foo that are on the disk, not junk. If you delete the file foo and run your test again, you should get an error to that effect. cheers, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394612&group_id=5470 From noreply at sourceforge.net Tue Jan 3 02:02:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Jan 2006 17:02:58 -0800 Subject: [ python-Bugs-1394612 ] 'Plus' filemode exposes uninitialized memory on win32 Message-ID: Bugs item #1394612, was opened at 2005-12-31 19:06 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394612&group_id=5470 Please note that this message will contain 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: Closed Resolution: Invalid Priority: 5 Submitted By: Cory Dodt (corydodt) Assigned to: Nobody/Anonymous (nobody) Summary: 'Plus' filemode exposes uninitialized memory on win32 Initial Comment: (Note: I'm using cygwin zsh, hence the prompts. I am using standard, python.org Python for these tests.) % echo abcdef > foo % python 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. >>> f = file('foo','r+b') >>> f.write('ghi') >>> f.read() '\x00x\x01\x83\x00\xe8\x03\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00e\x00\x00i\x01 \x00d\x00\x00\x83\x01\x00Fd\x01\x00S\x00S\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00[...lots and lots and lots of uninitialized memory deleted...]\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\x00abcdef\n' >>> f.close() >>> ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-01-02 20:02 Message: Logged In: YES user_id=31435 BTW, the standard actually says: and input shall not be directly followed by output without an intervening call to a file positioning function, unless the input operation encounters end-of-file. In your f.read() + f.write() example, that doesn't happen. It _would_ happen if the sequence were f.read() + f.read() + f.write() instead. It's the second f.read() that "encounters end-of-file". The first f.read() merely reads _up to_ EOF, leaving the file pointer _at_ EOF. On Windows, that appears to work fine, too: C:\Code>echo abc > foo C:\Code>\python24\python.exe Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 ... >>> f = open('foo', 'r+b') >>> f.read() 'abc \r\n' >>> f.read() # _this_ read "encounters EOF" '' >>> f.write('xyz') >>> f.seek(0) >>> f.read() 'abc \r\nxyz' >>> ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-01-02 19:55 Message: Logged In: YES user_id=31435 "make sense?" So far as it goes, yes -- thanks. At a higher level ;-), I've been slinging Python for 15 years and have never had any trouble with this stuff because I never push on the end cases (I always seek when switching between reading and writing, even if only by using the peculiar- looking f.seek(f.tell()), and regardless of the platform du jour). Pushing beyond that doesn't interest me. Note that Python's file_read() (in fileobject.c) is already much more complicated than simply calling C's fread(). Because of this, it may be that Python is adding strange end case behavior beyond what the platform C would exhibit if the latter were used directly. ---------------------------------------------------------------------- Comment By: Paul G (paul_g) Date: 2006-01-02 19:22 Message: Logged In: YES user_id=1417712 i'll comment about the rest later, but re not understanding: here is what ansi says: "If the file has been opened for read/write, a read may not be followed by a write. Or vice versa, without first calling either fflush(), fseek(), fsetpos(), or rewind(). Unless EOF was the last character read by fread(). " note the last sentence. python docs say that f.read() with no size parameter will read all data until it hits EOF. this means that any ansi c compliant implementation should perform synchronization when you fread() an EOF. glibc fopen(3) man page states that it follows this; it does not. msvscrt docs do not state that it follows this; it does not. so glibc promises ansi c compliance, but does not deliver. msvscrt does not promise ansi c compliance and doesn't deliver either, but at least it behaves as advertised in this respect. make sense? -p ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-01-02 19:08 Message: Logged In: YES user_id=31435 paul_g's option #1 is the only that takes no work, so is the only one I'm volunteering for <0.5 wink>. Docs would be good. #4 is in general impossible short of Python implementing its own I/O -- "the last" operation done on a C stream isn't necessarily visible to the Python implementation (extensions can and do perform their own I/O on C streams directly via platform C stdio calls -- Python has no way to know about that now even in theory). BTW, I don't understand: """1. in the f.read()+f.write()+f.read() case, the f.write() generates an IOError. this deviates from ansi c, but is in line with msdn docs.""" All behavior in that case is explicitly not defined by ANSI C if there isn't a file-positioning operation too between the read() and write(), and again between the write() and read(). Raising an exception is fine by ANSI C in that case. So is a segfault. So is reading nothing, or reading a terabtye, or wiping the disk clean, etc: nothing is defined about it. ---------------------------------------------------------------------- Comment By: Paul G (paul_g) Date: 2006-01-02 16:32 Message: Logged In: YES user_id=1417712 i think there's a bit of confusion here as to what exactly the problem is. ansi c says that for files fopen()ed for reading and writing (ie r+, w+ etc), you must issue an fflush(), fseek(), fsetpos(), or rewind() between a read and a write. the exception to this is if the read last read EOF. the behaviour we are seeing using python file objects: with glibc: 1. read + write + read result in no data being returned by the last read. this is the case regardless of whether we do f.readlines()+f.writelines()+f.readlines() or f.read()+f.write()+f.read(). this does not comnform to expected behaviour (as per ansi c and glibc fopen(3)), because at least in the latter (read() with no size parameter) case, python docs promise to stop at EOF, triggering the exception ansi c/glibc make to the intervening synchronization with file positioning requirement. with msvscrt: 1. in the f.read()+f.write()+f.read() case, the f.write() generates an IOError. this deviates from ansi c, but is in line with msdn docs. 2. in the f.readlines()+f.writelines()+f.readlines() case, you see the type of results quoted in the bug submission. this deviates from ansi c if you expect readlines() to read EOF, but is still in line with msdn docs. there are 3 issues here: 1. if we give users a high level interface for file i/o, as we do by giving them a File object, should we expect them to research, be aware of and deal with the requirements imposed by the low level implementation used? if it is reasonable to require that when they use read() and write(), is it still reasonable to require it when they user readlines() and writelines()? 2. if we expect users to be aware of ansi c requirements for file stream usage and deal with them, is it reasonable to expect them to deal with the differences in libc implementations, including the differing requirements they impose and differing failure modes being seen? should we not attempt to present an ansi c compliant interface to them, performing workarounds as is necessary on a given platform (or libc make as is the case here)? we certainly do that in some cases (but not in this one) based on my brief reading of Objects/fileobject.c. 3. if we leave users to deal with this mess, should we not at least document this in some fashion? whether it be a detailed explanation or just a pointer to look at the appropriate docs, or even just a mention that they should be reading up on fopen(), since that is the underlying implemention behind file objects. is it reasonable to expect folks for whom python is their first language, as some folks seem to promote python, to figure all of this out when they haven't the foggiest about ansi c? to recap, the real issue, imo, seems to be that we shouldn't be exposing users to this, rather than the funky results of not doing this right. there are 4 options for dealing with this: 1. do nothing (what tim currently fabours, it appears) 2. document this to some extent 3. make this work the same across all libcs 4. perform the syncrhonization (fflush, fsetpos etc depending on libc) for the user, behind the scenes, if we see a write coming in and the previous op was a read. the latter option, from the perspective of "this is exactly what a high level interface should do for the user", makes the most sense to me. but then, maybe that's why i'm not a python core dev ;) cheers, -p ---------------------------------------------------------------------- Comment By: Cory Dodt (corydodt) Date: 2006-01-01 19:43 Message: Logged In: YES user_id=889183 Tim - at a minimum this should be documented; even if it's just a link to the ANSI C documentation. Python is not ANSI C, we shouldn't expect the Python user to seek out ANSI C documentation. Want me to open a separate doc bug? The current doc only says this (about the file builtin): """ Modes 'r+', 'w+' and 'a+' open the file for updating (note that 'w+' truncates the file). Append 'b' to the mode to open the file in binary mode, on systems that differentiate between binary and text files (else it is ignored). If the file cannot be opened, IOError is raised. """ Either here, or perhaps in section 2.3.9, a clear description should be given of how to properly operate a + mode file. Failing that, a pointer to ANSI C documentation so the user can read about it on its own (and so the user knows that this behavior conforms to the underlying platform API in every ugly detail). I'm also dubious that this exposed memory is innocuous, but I'll defer to your expertise on that one. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-01-01 19:24 Message: Logged In: YES user_id=31435 There's nothing Python can do about this short of implementing I/O itself. That isn't likely. If someone is truly bothered by this behavior on Windows (or any other platform), they need to convince Microsoft (or other relevant C vendors) to change _their_ stdio implementation -- Python inherits the platform C's behavior, quirks and all. I'll note that I'm not bothered by it. It's one of those "doctor, doctor, it hurts when I do this!" kinds of pseudo-problems, IMO: so don't do that. It's not like hostile user input can "trick" a Python application into doing I/O operations in an undefined order. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2006-01-01 17:08 Message: Logged In: YES user_id=366566 I think Cory was aware of the underlying requirement to interpose a seek operation between the write and read operations, but was concerned about the consequences of not doing so. Python normally protects one from doing things that are *too* dangerous: I guess it's unclear to him (and perhaps others) whether the current behavior of file is just (relatively) obscure or if it could lead to real problems (exposing sensitive data, crashing the process). It seems like the latter is somewhat unlikely in practice, but since the behavior is unspecified, it seems like it *could* happen. I guess since Tim closed this, he thinks it's not too dangerous. In this case, the documentation could probably stand to be improved somewhat. The section () that documents the various modes which can be used to open a file could updated to include a warning along the lines of that in the C standard. It should probably explicitly state which file methods can be used to satisfy this requirement, since it's not clear otherwise except by reading the implementation of the file type (one could guess, from that file.flush() and file.seek() are suitable, but the documentation for these only says "like stdio ...", so you can't be completely sure). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-01-01 01:06 Message: Logged In: YES user_id=31435 This is actually pilot error (not a bug!), although it's subtle: Python uses the platform C I/O implementation, and in standard C mixing reads with writes yields undefined behavior unless a file-positioning operation (typically a seek()) occurs between switching from reading to writing (or vice versa); here from the C standard: When a file is opened with update mode (???+??? as the second or third character in the above list of mode argument values), both input and output may be performed on the associated stream. However, output shall not be directly followed by input without an intervening call to the fflush function or to a file positioning function (fseek, fsetpos, or rewind), and input shall not be directly followed by output without an intervening call to a file positioning function, unless the input operation encounters end-of-file. In other words, the result of running your sample code is undefined: nothing is guaranteed about its behavior, which both can and does vary across platforms. If you want defined behavior, then, for example, add >>> f.seek(0) between your write() and read() calls. ---------------------------------------------------------------------- Comment By: Clinton Roy (clintonroy) Date: 2006-01-01 00:38 Message: Logged In: YES user_id=31446 Hi Cory, I don't think r+ mode will create the file if it doesn't exist, so at a guess I think what you're seeing is the actual contents of a file named foo that are on the disk, not junk. If you delete the file foo and run your test again, you should get an error to that effect. cheers, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394612&group_id=5470 From noreply at sourceforge.net Tue Jan 3 02:39:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 02 Jan 2006 17:39:51 -0800 Subject: [ python-Bugs-1394612 ] 'Plus' filemode exposes uninitialized memory on win32 Message-ID: Bugs item #1394612, was opened at 2005-12-31 19:06 Message generated for change (Comment added) made by paul_g You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394612&group_id=5470 Please note that this message will contain 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: Closed Resolution: Invalid Priority: 5 Submitted By: Cory Dodt (corydodt) Assigned to: Nobody/Anonymous (nobody) Summary: 'Plus' filemode exposes uninitialized memory on win32 Initial Comment: (Note: I'm using cygwin zsh, hence the prompts. I am using standard, python.org Python for these tests.) % echo abcdef > foo % python 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. >>> f = file('foo','r+b') >>> f.write('ghi') >>> f.read() '\x00x\x01\x83\x00\xe8\x03\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00e\x00\x00i\x01 \x00d\x00\x00\x83\x01\x00Fd\x01\x00S\x00S\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00[...lots and lots and lots of uninitialized memory deleted...]\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\x00abcdef\n' >>> f.close() >>> ---------------------------------------------------------------------- Comment By: Paul G (paul_g) Date: 2006-01-02 20:39 Message: Logged In: YES user_id=1417712 i haven't ecnountered this edge case either, in my c days or otherwise. for those who are familiar with this (and in python's case, realize what the underlying implementation is), it simply wouldn't occur to them to *omit* flushes. this issue actually cropped up in a unit test in twisted which was failing on windows and not failing elsewhere. the explanation of read() and why this isn't working as i initially expected makes sense. however, this is what python docs say: "Read at most size bytes from the file (less if the read hits EOF before obtaining size bytes). If the size argument is negative or omitted, read all data until EOF is reached. The bytes are returned as a string object. An empty string is returned when EOF is encountered immediately. (For certain files, like ttys, it makes sense to continue reading after an EOF is hit.) " this states, absolutely unequivocally, that the first read does 'encounter' or 'hit' EOF. as i stated previously, the correct solution in my view is to handle this for the users. however, in light of the issue of extensions doing their own thing, doing this would require making extensions use python's fread wrapper. this is unlikely (understatement *ahem*) to happen. as such, this becomes a documentation issue. users should be made aware that they are expected to deal with this. ideally, they would also be told what to do. wording in the read() docs should be corrected to remove any implication that EOF actually gets encountered in the sense of ansi c until "" is returned. make sense? -p ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-01-02 20:02 Message: Logged In: YES user_id=31435 BTW, the standard actually says: and input shall not be directly followed by output without an intervening call to a file positioning function, unless the input operation encounters end-of-file. In your f.read() + f.write() example, that doesn't happen. It _would_ happen if the sequence were f.read() + f.read() + f.write() instead. It's the second f.read() that "encounters end-of-file". The first f.read() merely reads _up to_ EOF, leaving the file pointer _at_ EOF. On Windows, that appears to work fine, too: C:\Code>echo abc > foo C:\Code>\python24\python.exe Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 ... >>> f = open('foo', 'r+b') >>> f.read() 'abc \r\n' >>> f.read() # _this_ read "encounters EOF" '' >>> f.write('xyz') >>> f.seek(0) >>> f.read() 'abc \r\nxyz' >>> ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-01-02 19:55 Message: Logged In: YES user_id=31435 "make sense?" So far as it goes, yes -- thanks. At a higher level ;-), I've been slinging Python for 15 years and have never had any trouble with this stuff because I never push on the end cases (I always seek when switching between reading and writing, even if only by using the peculiar- looking f.seek(f.tell()), and regardless of the platform du jour). Pushing beyond that doesn't interest me. Note that Python's file_read() (in fileobject.c) is already much more complicated than simply calling C's fread(). Because of this, it may be that Python is adding strange end case behavior beyond what the platform C would exhibit if the latter were used directly. ---------------------------------------------------------------------- Comment By: Paul G (paul_g) Date: 2006-01-02 19:22 Message: Logged In: YES user_id=1417712 i'll comment about the rest later, but re not understanding: here is what ansi says: "If the file has been opened for read/write, a read may not be followed by a write. Or vice versa, without first calling either fflush(), fseek(), fsetpos(), or rewind(). Unless EOF was the last character read by fread(). " note the last sentence. python docs say that f.read() with no size parameter will read all data until it hits EOF. this means that any ansi c compliant implementation should perform synchronization when you fread() an EOF. glibc fopen(3) man page states that it follows this; it does not. msvscrt docs do not state that it follows this; it does not. so glibc promises ansi c compliance, but does not deliver. msvscrt does not promise ansi c compliance and doesn't deliver either, but at least it behaves as advertised in this respect. make sense? -p ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-01-02 19:08 Message: Logged In: YES user_id=31435 paul_g's option #1 is the only that takes no work, so is the only one I'm volunteering for <0.5 wink>. Docs would be good. #4 is in general impossible short of Python implementing its own I/O -- "the last" operation done on a C stream isn't necessarily visible to the Python implementation (extensions can and do perform their own I/O on C streams directly via platform C stdio calls -- Python has no way to know about that now even in theory). BTW, I don't understand: """1. in the f.read()+f.write()+f.read() case, the f.write() generates an IOError. this deviates from ansi c, but is in line with msdn docs.""" All behavior in that case is explicitly not defined by ANSI C if there isn't a file-positioning operation too between the read() and write(), and again between the write() and read(). Raising an exception is fine by ANSI C in that case. So is a segfault. So is reading nothing, or reading a terabtye, or wiping the disk clean, etc: nothing is defined about it. ---------------------------------------------------------------------- Comment By: Paul G (paul_g) Date: 2006-01-02 16:32 Message: Logged In: YES user_id=1417712 i think there's a bit of confusion here as to what exactly the problem is. ansi c says that for files fopen()ed for reading and writing (ie r+, w+ etc), you must issue an fflush(), fseek(), fsetpos(), or rewind() between a read and a write. the exception to this is if the read last read EOF. the behaviour we are seeing using python file objects: with glibc: 1. read + write + read result in no data being returned by the last read. this is the case regardless of whether we do f.readlines()+f.writelines()+f.readlines() or f.read()+f.write()+f.read(). this does not comnform to expected behaviour (as per ansi c and glibc fopen(3)), because at least in the latter (read() with no size parameter) case, python docs promise to stop at EOF, triggering the exception ansi c/glibc make to the intervening synchronization with file positioning requirement. with msvscrt: 1. in the f.read()+f.write()+f.read() case, the f.write() generates an IOError. this deviates from ansi c, but is in line with msdn docs. 2. in the f.readlines()+f.writelines()+f.readlines() case, you see the type of results quoted in the bug submission. this deviates from ansi c if you expect readlines() to read EOF, but is still in line with msdn docs. there are 3 issues here: 1. if we give users a high level interface for file i/o, as we do by giving them a File object, should we expect them to research, be aware of and deal with the requirements imposed by the low level implementation used? if it is reasonable to require that when they use read() and write(), is it still reasonable to require it when they user readlines() and writelines()? 2. if we expect users to be aware of ansi c requirements for file stream usage and deal with them, is it reasonable to expect them to deal with the differences in libc implementations, including the differing requirements they impose and differing failure modes being seen? should we not attempt to present an ansi c compliant interface to them, performing workarounds as is necessary on a given platform (or libc make as is the case here)? we certainly do that in some cases (but not in this one) based on my brief reading of Objects/fileobject.c. 3. if we leave users to deal with this mess, should we not at least document this in some fashion? whether it be a detailed explanation or just a pointer to look at the appropriate docs, or even just a mention that they should be reading up on fopen(), since that is the underlying implemention behind file objects. is it reasonable to expect folks for whom python is their first language, as some folks seem to promote python, to figure all of this out when they haven't the foggiest about ansi c? to recap, the real issue, imo, seems to be that we shouldn't be exposing users to this, rather than the funky results of not doing this right. there are 4 options for dealing with this: 1. do nothing (what tim currently fabours, it appears) 2. document this to some extent 3. make this work the same across all libcs 4. perform the syncrhonization (fflush, fsetpos etc depending on libc) for the user, behind the scenes, if we see a write coming in and the previous op was a read. the latter option, from the perspective of "this is exactly what a high level interface should do for the user", makes the most sense to me. but then, maybe that's why i'm not a python core dev ;) cheers, -p ---------------------------------------------------------------------- Comment By: Cory Dodt (corydodt) Date: 2006-01-01 19:43 Message: Logged In: YES user_id=889183 Tim - at a minimum this should be documented; even if it's just a link to the ANSI C documentation. Python is not ANSI C, we shouldn't expect the Python user to seek out ANSI C documentation. Want me to open a separate doc bug? The current doc only says this (about the file builtin): """ Modes 'r+', 'w+' and 'a+' open the file for updating (note that 'w+' truncates the file). Append 'b' to the mode to open the file in binary mode, on systems that differentiate between binary and text files (else it is ignored). If the file cannot be opened, IOError is raised. """ Either here, or perhaps in section 2.3.9, a clear description should be given of how to properly operate a + mode file. Failing that, a pointer to ANSI C documentation so the user can read about it on its own (and so the user knows that this behavior conforms to the underlying platform API in every ugly detail). I'm also dubious that this exposed memory is innocuous, but I'll defer to your expertise on that one. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-01-01 19:24 Message: Logged In: YES user_id=31435 There's nothing Python can do about this short of implementing I/O itself. That isn't likely. If someone is truly bothered by this behavior on Windows (or any other platform), they need to convince Microsoft (or other relevant C vendors) to change _their_ stdio implementation -- Python inherits the platform C's behavior, quirks and all. I'll note that I'm not bothered by it. It's one of those "doctor, doctor, it hurts when I do this!" kinds of pseudo-problems, IMO: so don't do that. It's not like hostile user input can "trick" a Python application into doing I/O operations in an undefined order. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2006-01-01 17:08 Message: Logged In: YES user_id=366566 I think Cory was aware of the underlying requirement to interpose a seek operation between the write and read operations, but was concerned about the consequences of not doing so. Python normally protects one from doing things that are *too* dangerous: I guess it's unclear to him (and perhaps others) whether the current behavior of file is just (relatively) obscure or if it could lead to real problems (exposing sensitive data, crashing the process). It seems like the latter is somewhat unlikely in practice, but since the behavior is unspecified, it seems like it *could* happen. I guess since Tim closed this, he thinks it's not too dangerous. In this case, the documentation could probably stand to be improved somewhat. The section () that documents the various modes which can be used to open a file could updated to include a warning along the lines of that in the C standard. It should probably explicitly state which file methods can be used to satisfy this requirement, since it's not clear otherwise except by reading the implementation of the file type (one could guess, from that file.flush() and file.seek() are suitable, but the documentation for these only says "like stdio ...", so you can't be completely sure). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-01-01 01:06 Message: Logged In: YES user_id=31435 This is actually pilot error (not a bug!), although it's subtle: Python uses the platform C I/O implementation, and in standard C mixing reads with writes yields undefined behavior unless a file-positioning operation (typically a seek()) occurs between switching from reading to writing (or vice versa); here from the C standard: When a file is opened with update mode (???+??? as the second or third character in the above list of mode argument values), both input and output may be performed on the associated stream. However, output shall not be directly followed by input without an intervening call to the fflush function or to a file positioning function (fseek, fsetpos, or rewind), and input shall not be directly followed by output without an intervening call to a file positioning function, unless the input operation encounters end-of-file. In other words, the result of running your sample code is undefined: nothing is guaranteed about its behavior, which both can and does vary across platforms. If you want defined behavior, then, for example, add >>> f.seek(0) between your write() and read() calls. ---------------------------------------------------------------------- Comment By: Clinton Roy (clintonroy) Date: 2006-01-01 00:38 Message: Logged In: YES user_id=31446 Hi Cory, I don't think r+ mode will create the file if it doesn't exist, so at a guess I think what you're seeing is the actual contents of a file named foo that are on the disk, not junk. If you delete the file foo and run your test again, you should get an error to that effect. cheers, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394612&group_id=5470 From noreply at sourceforge.net Tue Jan 3 09:57:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 Jan 2006 00:57:00 -0800 Subject: [ python-Bugs-1381476 ] csv.reader endless loop Message-ID: Bugs item #1381476, was opened at 2005-12-15 11:04 Message generated for change (Comment added) made by wwwingman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381476&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Christian Harms (wwwingman) Assigned to: Andrew McNamara (andrewmcnamara) Summary: csv.reader endless loop Initial Comment: Hi, the csv.reader produce a endless loop, ifan parsing Error is in the last line of the CSV-File. If you put an "\r" in the last line, cvs.Error is raised and StopIteration will lost. import csv, StringIO fp = StringIO.StringIO("line1\nline2\rerror") reader = csv.reader(fp) while 1: try: print reader.next() except csv.Error: print "Error" except StopIteration: break Die Problem is in python 2.3 AND python 2.4. Other version are not checked. ---------------------------------------------------------------------- >Comment By: Christian Harms (wwwingman) Date: 2006-01-03 08:56 Message: Logged In: YES user_id=1405594 >birkenfeld: csv.Error would imply a StopIteration/break ... No, this Error says only: "Can not parse THIS line ...". This exception is used for reading buggy outlook-Export-CSV-Files und trying to read some lines (not all). And if the error is in the last line, the StopIteration will be forgotten and the Error will be produced in a endless-loop. input = StringIO.StringIO("1.\rerror\n2.ok\n3.\rerr") #insert my while-loop #Output: >Error >2.ok >Error >Error ... ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-17 17:02 Message: Logged In: YES user_id=1188172 Let the expert judge. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-12-17 16:56 Message: Logged In: YES user_id=315535 Actually, the problem may not be a problem with the csv module at all, it may be a misinterpretation of the API on the submitters part. Is there any time a non-fatal csv.Error would/could be raised? Seems to me that a csv.Error would imply a StopIteration/break ... ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-12-17 15:17 Message: Logged In: YES user_id=315535 I think this may be fixed in subversion: tom at vanilla:~/work/python$ svn info Path: . URL: http://svn.python.org/projects/python/trunk Repository UUID: 6015fed2-1504-0410-9fe1-9d1591cc4771 Revision: 41731 Node Kind: directory Schedule: normal Last Changed Author: fredrik.lundh Last Changed Rev: 41729 Last Changed Date: 2005-12-17 18:33:21 +1000 (Sat, 17 Dec 2005) Properties Last Updated: 2005-12-17 21:44:46 +1000 (Sat, 17 Dec 2005) tom at vanilla:~/work/python$ python -V Python 2.4.2 tom at vanilla:~/work/python$ python Sandbox/csv_reader_test.py ['line1'] ERROR: newline inside string tom at vanilla:~/work/python$ ./python -V Python 2.5a0 tom at vanilla:~/work/python$ ./python Sandbox/csv_reader_test.py ['line1'] ERROR: new-line character seen in unquoted field - do you need to open the file in universal-newline mode? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381476&group_id=5470 From noreply at sourceforge.net Tue Jan 3 11:33:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 Jan 2006 02:33:34 -0800 Subject: [ python-Bugs-1390608 ] split() breaks no-break spaces Message-ID: Bugs item #1390608, was opened at 2005-12-26 16:03 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390608&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: MvR (maxim_razin) Assigned to: M.-A. Lemburg (lemburg) Summary: split() breaks no-break spaces Initial Comment: string.split(), str.split() and unicode.split() without parameters break strings by the No-break space (U+00A0) character. This character is specially intended not to be a split border. >>> u"Hello\u00A0world".split() [u'Hello', u'world'] ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-01-03 11:33 Message: Logged In: YES user_id=89016 Seems I confused strip() with split(). I *did* try that work around, and it did what I expected: It *didn't* split on U+00A0 ;) If we want to fix this discrepancy, we could add methods stripchars(), (as a synonym for strip()) and stripstring(), as well as splitchars() and splitstring() (as a synonym for split()). ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-01-02 12:13 Message: Logged In: YES user_id=38388 Oops. You're right, Sjoerd. Still, you could achieve the splitting by using a re-expression that is build from the set of characters fetched from the Unicode database and then using the .split() method of the re object. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2006-01-02 11:48 Message: Logged In: YES user_id=43607 Walter and MAL, did you actually try that work around? It doesn't work: >>> import sys, unicodedata >>> spaces = u"".join(unichr(c) for c in xrange(0, sys.maxunicode) if unicodedata.category(unichr(c))=="Zs" and c != 160) >>> foo = u"Hello\u00A0world" >>> foo.split(spaces) [u'Hello\xa0world'] That's because split() takes the whole separator argument as separator, not any of the characters in it. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-12-30 14:06 Message: Logged In: YES user_id=38388 Maxim, you are right that \xA0 is a non-break space. However, like the others already mentioned, the .split() method defaults to breaking a string on whitespace characters, not breakable whitespace characters. The intent is not a typographical one, but originates from the desire to quickly tokenize a string. If you'd rather like to see a different set of whitespace characters used, you can pass such a template string to the .split() method (Walter gave an example). Closing this as "Won't fix". ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-12-30 13:35 Message: Logged In: YES user_id=89016 What's wrong with the following? import sys, unicodedata spaces = u"".join(unichr(c) for c in xrange(0, sys.maxunicode) if unicodedata.category(unichr(c))=="Zs" and c != 160) foo.split(spaces) ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-12-30 01:30 Message: Logged In: YES user_id=55188 Python documentation says that it splits in "whitespace characters" not "breaking characters". So, current behavior is correct according to the documentation. And even rationale among string methods are heavily depends on ctype functions on libc. Therefore, we can't serve special treatment for the NBSP. However, I feel the need for the splitting function that awares what character is breaking or not. How about to add it as unicodedata.split()? ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-29 21:42 Message: Logged In: YES user_id=38376 split isn't a word-wrapping split, so I'm not sure that's the right place to fix this. ("no-break space" is white- space, according to the Unicode standard, and split breaks on whitespace). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390608&group_id=5470 From noreply at sourceforge.net Tue Jan 3 12:07:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 Jan 2006 03:07:40 -0800 Subject: [ python-Bugs-1390608 ] split() breaks no-break spaces Message-ID: Bugs item #1390608, was opened at 2005-12-26 16:03 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390608&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: MvR (maxim_razin) Assigned to: M.-A. Lemburg (lemburg) Summary: split() breaks no-break spaces Initial Comment: string.split(), str.split() and unicode.split() without parameters break strings by the No-break space (U+00A0) character. This character is specially intended not to be a split border. >>> u"Hello\u00A0world".split() [u'Hello', u'world'] ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-01-03 12:07 Message: Logged In: YES user_id=38388 No. These things are application scope details and should thus be implemented in the application rather than as method on an object. The methods always work on whitespace and that's clearly defined. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-01-03 11:33 Message: Logged In: YES user_id=89016 Seems I confused strip() with split(). I *did* try that work around, and it did what I expected: It *didn't* split on U+00A0 ;) If we want to fix this discrepancy, we could add methods stripchars(), (as a synonym for strip()) and stripstring(), as well as splitchars() and splitstring() (as a synonym for split()). ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-01-02 12:13 Message: Logged In: YES user_id=38388 Oops. You're right, Sjoerd. Still, you could achieve the splitting by using a re-expression that is build from the set of characters fetched from the Unicode database and then using the .split() method of the re object. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2006-01-02 11:48 Message: Logged In: YES user_id=43607 Walter and MAL, did you actually try that work around? It doesn't work: >>> import sys, unicodedata >>> spaces = u"".join(unichr(c) for c in xrange(0, sys.maxunicode) if unicodedata.category(unichr(c))=="Zs" and c != 160) >>> foo = u"Hello\u00A0world" >>> foo.split(spaces) [u'Hello\xa0world'] That's because split() takes the whole separator argument as separator, not any of the characters in it. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-12-30 14:06 Message: Logged In: YES user_id=38388 Maxim, you are right that \xA0 is a non-break space. However, like the others already mentioned, the .split() method defaults to breaking a string on whitespace characters, not breakable whitespace characters. The intent is not a typographical one, but originates from the desire to quickly tokenize a string. If you'd rather like to see a different set of whitespace characters used, you can pass such a template string to the .split() method (Walter gave an example). Closing this as "Won't fix". ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-12-30 13:35 Message: Logged In: YES user_id=89016 What's wrong with the following? import sys, unicodedata spaces = u"".join(unichr(c) for c in xrange(0, sys.maxunicode) if unicodedata.category(unichr(c))=="Zs" and c != 160) foo.split(spaces) ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-12-30 01:30 Message: Logged In: YES user_id=55188 Python documentation says that it splits in "whitespace characters" not "breaking characters". So, current behavior is correct according to the documentation. And even rationale among string methods are heavily depends on ctype functions on libc. Therefore, we can't serve special treatment for the NBSP. However, I feel the need for the splitting function that awares what character is breaking or not. How about to add it as unicodedata.split()? ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-29 21:42 Message: Logged In: YES user_id=38376 split isn't a word-wrapping split, so I'm not sure that's the right place to fix this. ("no-break space" is white- space, according to the Unicode standard, and split breaks on whitespace). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390608&group_id=5470 From noreply at sourceforge.net Tue Jan 3 12:30:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 Jan 2006 03:30:10 -0800 Subject: [ python-Bugs-1395926 ] make fails trying to run svnversion Message-ID: Bugs item #1395926, was opened at 2006-01-03 12:30 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=1395926&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Barry A. Warsaw (bwarsaw) Summary: make fails trying to run svnversion Initial Comment: If you run make in a directory that has an .svn subdir, make fails if there's no usable subversion installation on the PATH: if test -d ./.svn; then \ svnversion . >buildno; \ elif test -f buildno; then \ expr `cat buildno` + 1 >buildno1; \ mv -f buildno1 buildno; \ else echo 1 >buildno; fi /bin/sh: svnversion: command not found The above test should probably also check for the availability of svnversion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1395926&group_id=5470 From noreply at sourceforge.net Tue Jan 3 15:26:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 Jan 2006 06:26:58 -0800 Subject: [ python-Bugs-1396030 ] TimedRotatingFileHandler at midnight rolls over at 01:00 Message-ID: Bugs item #1396030, was opened at 2006-01-03 14: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=1396030&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Waters (awaters) Assigned to: Nobody/Anonymous (nobody) Summary: TimedRotatingFileHandler at midnight rolls over at 01:00 Initial Comment: Using TimedRotatingFileHandler with interval set to midnight rolls the log over at 1:00am rather than midnight. (LocalTime = GMT). This is because the calculation of seconds until midnight is incorrect (it behaves as if there are 24 hours, 59 minutes and 59 seconds in the day). It also means that should a program stop between midnight and 1:00am and restart it fails to roll over the log as the log over time is set to 1:00am the next day. Occurs on Linux (FC3), Windows XP (SP2). Bug occurs (2.4.2 and currently exists in most recent 2.5 SVN code). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396030&group_id=5470 From noreply at sourceforge.net Tue Jan 3 15:31:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 Jan 2006 06:31:24 -0800 Subject: [ python-Bugs-1395926 ] make fails trying to run svnversion Message-ID: Bugs item #1395926, was opened at 2006-01-03 06:30 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1395926&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Barry A. Warsaw (bwarsaw) Summary: make fails trying to run svnversion Initial Comment: If you run make in a directory that has an .svn subdir, make fails if there's no usable subversion installation on the PATH: if test -d ./.svn; then \ svnversion . >buildno; \ elif test -f buildno; then \ expr `cat buildno` + 1 >buildno1; \ mv -f buildno1 buildno; \ else echo 1 >buildno; fi /bin/sh: svnversion: command not found The above test should probably also check for the availability of svnversion. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-03 09:31 Message: Logged In: YES user_id=12800 r41907 -- added a test for svnversion command on $PATH ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1395926&group_id=5470 From noreply at sourceforge.net Tue Jan 3 15:38:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 Jan 2006 06:38:54 -0800 Subject: [ python-Bugs-1396040 ] TimedRotatingFileHandler does not recover from open error Message-ID: Bugs item #1396040, was opened at 2006-01-03 14: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=1396040&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Waters (awaters) Assigned to: Nobody/Anonymous (nobody) Summary: TimedRotatingFileHandler does not recover from open error Initial Comment: When doing a rollover TimedRotatingFileHandler doRollover does not recover if there is an open error. This is because when the rollover function fails at the open (e.g. too many files open) and is called again at the next attempt to write to the log doRollover attempts to rename (the now no longer existing) original file which raises an exception. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396040&group_id=5470 From noreply at sourceforge.net Tue Jan 3 20:06:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 Jan 2006 11:06:26 -0800 Subject: [ python-Feature Requests-1303434 ] Please include pdb with windows distribution Message-ID: Feature Requests item #1303434, was opened at 2005-09-24 19:30 Message generated for change (Comment added) made by lylefile You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1303434&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lyle Thompson (lylefile) Assigned to: Nobody/Anonymous (nobody) Summary: Please include pdb with windows distribution Initial Comment: Checking out the source files and rebuilding is not guaranteed to build a program database (pdb) file that represents the distribution python DLL. This may be due to a differences in the windows version or visual studio service pack on my system vs the one used to build the distribution, but tracking it down can be very time consuming. Including the pdb in the distribution should be trivial and avoid this problem entirely. Although I can fix the problem for future releases of our product, I am also supporting previous releases that included the standard DLL included in the distribution. ---------------------------------------------------------------------- >Comment By: Lyle Thompson (lylefile) Date: 2006-01-03 19:06 Message: Logged In: YES user_id=1351115 A PDB file is required for debugging crash dumps from complex pythonic programs. This ability is absolutely critical for commercial programs using python. Technically, the crashes only happen within pyds or dlls, but it is often very vitally important to be able to find out what python code was being interpreted at the time. Unfortunately, I've even seen "pure" python crash in one of the supplied pyd's. Of course, the pdb file should be in a separate download, as few users require the ability to reverse engineer crash dumps. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-12-28 00:12 Message: Logged In: YES user_id=21627 Update: distribution in a separate zipfile would be possible, provided that a patch to the build process (in Tools/msi/msi.py) would be contributed. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-09-27 20:03 Message: Logged In: YES user_id=21627 Including the PDB files in the MSI is probably not acceptable to the majority of the users. python24.pdb is 3.5MiB in size, so the MSI file to download would grow considerably. Why do you need the PDB file in the first place? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1303434&group_id=5470 From noreply at sourceforge.net Tue Jan 3 21:04:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 Jan 2006 12:04:59 -0800 Subject: [ python-Bugs-1396258 ] KeyboardInterrupt prevents return to Windows console Message-ID: Bugs item #1396258, was opened at 2006-01-03 13: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=1396258&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Vernon Cole (kf7xm) Assigned to: Nobody/Anonymous (nobody) Summary: KeyboardInterrupt prevents return to Windows console Initial Comment: Environment: Python 2.4, Windows 2000 Professional, windows command prompt. Python is using a join(), waiting for threads to finish, when a KeyboardInterrupt occurs. (A KeyboardInterrupt handler is defined for the main thread.) The handler appears to work as expected, but control is never returned to Windows, leaving the console window unusable. Directions to reproduce bug: 1) run the attached program from a console prompt like: c:\mydir> threadingSample.py 2) when the program suggests, hit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396258&group_id=5470 From noreply at sourceforge.net Tue Jan 3 23:01:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 Jan 2006 14:01:00 -0800 Subject: [ python-Feature Requests-1303434 ] Please include pdb with windows distribution Message-ID: Feature Requests item #1303434, was opened at 2005-09-24 21:30 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1303434&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lyle Thompson (lylefile) Assigned to: Nobody/Anonymous (nobody) Summary: Please include pdb with windows distribution Initial Comment: Checking out the source files and rebuilding is not guaranteed to build a program database (pdb) file that represents the distribution python DLL. This may be due to a differences in the windows version or visual studio service pack on my system vs the one used to build the distribution, but tracking it down can be very time consuming. Including the pdb in the distribution should be trivial and avoid this problem entirely. Although I can fix the problem for future releases of our product, I am also supporting previous releases that included the standard DLL included in the distribution. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-01-03 23:01 Message: Logged In: YES user_id=21627 Just in case I wasn't clear in my last message: patches in that direction are appreciate; without a contributed patch, nothing will happen. ---------------------------------------------------------------------- Comment By: Lyle Thompson (lylefile) Date: 2006-01-03 20:06 Message: Logged In: YES user_id=1351115 A PDB file is required for debugging crash dumps from complex pythonic programs. This ability is absolutely critical for commercial programs using python. Technically, the crashes only happen within pyds or dlls, but it is often very vitally important to be able to find out what python code was being interpreted at the time. Unfortunately, I've even seen "pure" python crash in one of the supplied pyd's. Of course, the pdb file should be in a separate download, as few users require the ability to reverse engineer crash dumps. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-12-28 01:12 Message: Logged In: YES user_id=21627 Update: distribution in a separate zipfile would be possible, provided that a patch to the build process (in Tools/msi/msi.py) would be contributed. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-09-27 22:03 Message: Logged In: YES user_id=21627 Including the PDB files in the MSI is probably not acceptable to the majority of the users. python24.pdb is 3.5MiB in size, so the MSI file to download would grow considerably. Why do you need the PDB file in the first place? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1303434&group_id=5470 From noreply at sourceforge.net Wed Jan 4 02:53:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 Jan 2006 17:53:18 -0800 Subject: [ python-Bugs-1396471 ] file.tell() returns illegal value on Windows Message-ID: Bugs item #1396471, was opened at 2006-01-03 17: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=1396471&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tom Goddard (tom_goddard) Assigned to: Nobody/Anonymous (nobody) Summary: file.tell() returns illegal value on Windows Initial Comment: The file tell() method returns an illegal value that causes an exception when passed to seek(). This happens on Windows when a file that contains unix-style newlines '\n' is opened and read in text mode 'r'. Below is code that produces the problem on Windows 2.4.2 in an IDLE shell. The bug does not occur when using mode 'rU' or 'rb'. But I expect correct behaviour with mode 'r'. My understanding is that 'rU' translates line endings to '\n' in the returned string while mode 'r' still correctly reads the lines using readline(), recognizing all 3 common endline conventions, but does not translate (ie includes \n\r or \r or \n in returned string). The error in the tell() return value depends on how long the file is. Changing the 'more\n'*10 line in the example code will cause different incorrect return values. Previous bug reports have mentioned problems with tell/seek when using file iterators, the file.next() method and the "for line in file:" construct. This bug is different and just involves readline() and tell() with mode 'r'. Example code tellbug.py follows: wf = open('testdata', 'wb') wf.write('01234\n56789\n'+ 'more\n'*10) wf.close() f = open('testdata', 'r') f.readline() t = f.tell() print t f.seek(t) ------- Running gives: >>> execfile('tellbug.py') -5 Traceback (most recent call last): File "", line 1, in -toplevel- execfile('tellbug.py') File "tellbug.py", line 9, in -toplevel- f.seek(t) IOError: [Errno 22] Invalid argument ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396471&group_id=5470 From noreply at sourceforge.net Wed Jan 4 05:57:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 Jan 2006 20:57:49 -0800 Subject: [ python-Bugs-1396543 ] urlparse is confused by / Message-ID: Bugs item #1396543, was opened at 2006-01-04 04: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=1396543&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John Hansen (johnhansen) Assigned to: Nobody/Anonymous (nobody) Summary: urlparse is confused by / Initial Comment: If the parameter field of a URL contains a '/', urlparse does not enter date in the parameter field, but leaves it attached to the path. The simplified example is: >>> urlparse.urlparse("http://f/adi;s=a;c=b/") ('http', 'f', '/adi;s=a;c=b/', '', '', '') >>> urlparse.urlparse("http://f/adi;s=a;c=b") ('http', 'f', '/adi', 's=a;c=b', '', '') The realworld case was: >>> urlparse.urlparse("http://ad.doubleclick.net/adi/ N3691.VibrantMedia/B1733031.2;sz=160x600;click=http%3A/ adforce.adtech.de/adlink%7C82%7C59111%7C1%7C168%7CAdId% 3D1023327%3BBnId%3D4%3Bitime%3D335264036%3Bku%3D12900% 3Bkey%3Dcomputing%2Bbetanews%5Fgeneral%3Blink%3D") (''http'', 'ad.doubleclick.net/adi/N3691.VibrantMedia/ B1733031.2;sz=160x600;click=http%3A/adforce.adtech.de/adlink% 7C82%7C59111%7C1%7C168%7CAdId%3D1023327%3BBnId%3D4%3Bitime %3D335264036%3Bku%3D12900%3Bkey%3Dcomputing%2Bbetanews% 5Fgeneral%3Blink%3D', '', '', '') What's odd is that the code specifically says to do this: def _splitparams(url): if '/' in url: i = url.find(';', url.rfind('/')) if i < 0: return url, '' Is there a reason for the rfind? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396543&group_id=5470 From noreply at sourceforge.net Wed Jan 4 06:00:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 03 Jan 2006 21:00:58 -0800 Subject: [ python-Bugs-1396543 ] urlparse is confused by / Message-ID: Bugs item #1396543, was opened at 2006-01-04 04:57 Message generated for change (Comment added) made by johnhansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396543&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John Hansen (johnhansen) Assigned to: Nobody/Anonymous (nobody) Summary: urlparse is confused by / Initial Comment: If the parameter field of a URL contains a '/', urlparse does not enter date in the parameter field, but leaves it attached to the path. The simplified example is: >>> urlparse.urlparse("http://f/adi;s=a;c=b/") ('http', 'f', '/adi;s=a;c=b/', '', '', '') >>> urlparse.urlparse("http://f/adi;s=a;c=b") ('http', 'f', '/adi', 's=a;c=b', '', '') The realworld case was: >>> urlparse.urlparse("http://ad.doubleclick.net/adi/ N3691.VibrantMedia/B1733031.2;sz=160x600;click=http%3A/ adforce.adtech.de/adlink%7C82%7C59111%7C1%7C168%7CAdId% 3D1023327%3BBnId%3D4%3Bitime%3D335264036%3Bku%3D12900% 3Bkey%3Dcomputing%2Bbetanews%5Fgeneral%3Blink%3D") (''http'', 'ad.doubleclick.net/adi/N3691.VibrantMedia/ B1733031.2;sz=160x600;click=http%3A/adforce.adtech.de/adlink% 7C82%7C59111%7C1%7C168%7CAdId%3D1023327%3BBnId%3D4%3Bitime %3D335264036%3Bku%3D12900%3Bkey%3Dcomputing%2Bbetanews% 5Fgeneral%3Blink%3D', '', '', '') What's odd is that the code specifically says to do this: def _splitparams(url): if '/' in url: i = url.find(';', url.rfind('/')) if i < 0: return url, '' Is there a reason for the rfind? ---------------------------------------------------------------------- >Comment By: John Hansen (johnhansen) Date: 2006-01-04 05:00 Message: Logged In: YES user_id=1418831 The first line should have read: If the parameter field of a URL contains a '/', urlparse does not enter it into the parameter field, but leaves it attached to the path. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396543&group_id=5470 From noreply at sourceforge.net Wed Jan 4 09:25:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 Jan 2006 00:25:41 -0800 Subject: [ python-Bugs-1396622 ] TimedRotatingFileHandler midnight rollover time increases Message-ID: Bugs item #1396622, was opened at 2006-01-04 08:25 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=1396622&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Waters (awaters) Assigned to: Nobody/Anonymous (nobody) Summary: TimedRotatingFileHandler midnight rollover time increases Initial Comment: When calculating the next rollover time the calculation uses the current time plus the interval. Unless the log file is written exactly at midnight the rollover time becomes the current time + 1 day. So for example, if the log is written at 2:00am then the next rollover time will be 2:00am the following day rather than midnight. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396622&group_id=5470 From noreply at sourceforge.net Wed Jan 4 10:56:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 Jan 2006 01:56:32 -0800 Subject: [ python-Bugs-1396678 ] bsddb.__init__ causes error Message-ID: Bugs item #1396678, was opened at 2006-01-04 10:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396678&group_id=5470 Please note that this 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 Submitted By: Fabian_M (fmareyen) Assigned to: Nobody/Anonymous (nobody) Summary: bsddb.__init__ causes error Initial Comment: I've found an Error in the bsddb.__init__.py-module: pythonversion = 2.4 (problem may also be in version 2.3) After creating and closing a db with bsddb.hashopen I called globals(). Next there occured an Error: #Error-Message --------------------------------------------- >>> globals() {'__builtins__': , 'f4': , 'dbtest1': Traceback (most recent call last): File "", line 1, in ? File "D:\Programme\python24\lib\UserDict.py", line 162, in __repr__ return repr(dict(self.iteritems())) File "", line 46, in iteritems File "", line 4, in _make_iter_cursor AttributeError: 'NoneType' object has no attribute 'cursor' >>> ---------------------------------------------- #Way of the Error The way of the Error is: 1. globals() asked for bsddb._DBWithCursor.__repr__ with the __repr__-method inherriting from bsddb._iter_mixin based on UserDict.DictMixin. 2. The __repr__-method in UserDict.DictMixin at line 162 calls self.iteritems overwritten by bsddb._iter_mixin.iteritems at line 113. 3. This method calls self._make_iter_cursor (line 115). bsddb._iter_mixin._make_iter_cursor calls bsddb.db which was set to None at closing the bd with db.close() at line 223. #Solution: That way the error was created. To avoid this, the bsddb._iter_mixin.iteritems-method should be something like this: ------------------------- def iteritems(self): if not self.db: return "" try: cur = self._make_iter_cursor() ... ... ------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396678&group_id=5470 From noreply at sourceforge.net Wed Jan 4 14:21:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 Jan 2006 05:21:41 -0800 Subject: [ python-Feature Requests-1396825 ] subprocess: wait for a period of time Message-ID: Feature Requests item #1396825, was opened at 2006-01-04 14: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=1396825&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ragnar Ouchterlony (ragnar) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess: wait for a period of time Initial Comment: I would appreciate if the wait() method of Popen() would be able to take a time argument, to wait at most this time, before returning. It would be nice to be able to wait for a program, and if it has hanged, you still get back to the program. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1396825&group_id=5470 From noreply at sourceforge.net Wed Jan 4 16:24:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 Jan 2006 07:24:46 -0800 Subject: [ python-Bugs-1396946 ] %ehrntDRT support for time.strptime Message-ID: Bugs item #1396946, was opened at 2006-01-04 06: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=1396946&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Johan Dahlin (zilche) Assigned to: Nobody/Anonymous (nobody) Summary: %ehrntDRT support for time.strptime Initial Comment: As defined in: http://www.opengroup.org/onlinepubs/009695399/functions/strptime.html %r -> locales representation of time + AM/PM %e -> %d %h -> %b %D -> %m/%d/%y %R -> %H:%M %T -> %H:%M:%S %n/%t -> whitespace ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396946&group_id=5470 From noreply at sourceforge.net Wed Jan 4 17:31:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 Jan 2006 08:31:24 -0800 Subject: [ python-Bugs-1396543 ] urlparse is confused by / Message-ID: Bugs item #1396543, was opened at 2006-01-04 04:57 Message generated for change (Comment added) made by johnhansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396543&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John Hansen (johnhansen) Assigned to: Nobody/Anonymous (nobody) Summary: urlparse is confused by / Initial Comment: If the parameter field of a URL contains a '/', urlparse does not enter date in the parameter field, but leaves it attached to the path. The simplified example is: >>> urlparse.urlparse("http://f/adi;s=a;c=b/") ('http', 'f', '/adi;s=a;c=b/', '', '', '') >>> urlparse.urlparse("http://f/adi;s=a;c=b") ('http', 'f', '/adi', 's=a;c=b', '', '') The realworld case was: >>> urlparse.urlparse("http://ad.doubleclick.net/adi/ N3691.VibrantMedia/B1733031.2;sz=160x600;click=http%3A/ adforce.adtech.de/adlink%7C82%7C59111%7C1%7C168%7CAdId% 3D1023327%3BBnId%3D4%3Bitime%3D335264036%3Bku%3D12900% 3Bkey%3Dcomputing%2Bbetanews%5Fgeneral%3Blink%3D") (''http'', 'ad.doubleclick.net/adi/N3691.VibrantMedia/ B1733031.2;sz=160x600;click=http%3A/adforce.adtech.de/adlink% 7C82%7C59111%7C1%7C168%7CAdId%3D1023327%3BBnId%3D4%3Bitime %3D335264036%3Bku%3D12900%3Bkey%3Dcomputing%2Bbetanews% 5Fgeneral%3Blink%3D', '', '', '') What's odd is that the code specifically says to do this: def _splitparams(url): if '/' in url: i = url.find(';', url.rfind('/')) if i < 0: return url, '' Is there a reason for the rfind? ---------------------------------------------------------------------- >Comment By: John Hansen (johnhansen) Date: 2006-01-04 16:31 Message: Logged In: YES user_id=1418831 The first line should have read: If the parameter field of a URL contains a '/', urlparse does not enter it into the parameter field, but leaves it attached to the path. ---------------------------------------------------------------------- Comment By: John Hansen (johnhansen) Date: 2006-01-04 05:00 Message: Logged In: YES user_id=1418831 The first line should have read: If the parameter field of a URL contains a '/', urlparse does not enter it into the parameter field, but leaves it attached to the path. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396543&group_id=5470 From noreply at sourceforge.net Wed Jan 4 20:05:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 Jan 2006 11:05:51 -0800 Subject: [ python-Feature Requests-1396825 ] subprocess: wait for a period of time Message-ID: Feature Requests item #1396825, was opened at 2006-01-04 14:21 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1396825&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ragnar Ouchterlony (ragnar) >Assigned to: Peter ?strand (astrand) Summary: subprocess: wait for a period of time Initial Comment: I would appreciate if the wait() method of Popen() would be able to take a time argument, to wait at most this time, before returning. It would be nice to be able to wait for a program, and if it has hanged, you still get back to the program. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1396825&group_id=5470 From noreply at sourceforge.net Wed Jan 4 21:34:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 Jan 2006 12:34:01 -0800 Subject: [ python-Bugs-1397205 ] no handler base classes in xml.sax Message-ID: Bugs item #1397205, was opened at 2006-01-04 13: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=1397205&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Alan G (abgrover) Assigned to: Nobody/Anonymous (nobody) Summary: no handler base classes in xml.sax Initial Comment: The 2.4.1 Documentation for xml.sax.handler states: Handler implementations should inherit from the base classes provided in the module xml.sax, so that all methods get default implementations. However, there are no handler base classes in xml.sax. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1397205&group_id=5470 From noreply at sourceforge.net Wed Jan 4 22:06:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 Jan 2006 13:06:34 -0800 Subject: [ python-Bugs-1391608 ] missing module names in email package Message-ID: Bugs item #1391608, was opened at 2005-12-28 03:04 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391608&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gabriel Genellina (gagenellina) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: missing module names in email package Initial Comment: Documentation for modules inside the email package lacks reference to module name in title (and body too). By example, there is no clue in 12.2.1 that the Message class being described is contained in the email.Message module. Or 12.2.2 doesnt menction that FeedParser, HeaderParser and Parser are all classes contained in module email.Parser. And so on. Looking at other similar standard packages (like curses) seems that the module name should appear first in the title. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391608&group_id=5470 From noreply at sourceforge.net Thu Jan 5 04:50:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 Jan 2006 19:50:11 -0800 Subject: [ python-Bugs-1397474 ] timeit execution enviroment Message-ID: Bugs item #1397474, was opened at 2006-01-05 03: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=1397474&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: rurpy (rurpy) Assigned to: Nobody/Anonymous (nobody) Summary: timeit execution enviroment Initial Comment: library reference manual, section 10.10 The documentation for the timeit module does not make clear exactly what enviroment the timed code will be run in, particularly when a function in the current program is being timed (as opposed to an external program.) This information is available in the examples section but examples should illustrate already described behavior, not present new information. I think the following text should be appended below the third paragraph in the "class Timer" section which reads: To measure the execution time of the first statement, use the timeit() method. The repeat() method is a convenience to call timeit() multiple times and return a list of results. Proposed addition: The timed statement is executed in the namespace of the timeit module. If a function in the __main__ module is being timed, it can be made accessible to the timer module by using a setup statement like "from __main__ import xx" where xx is the function's name in __main__. Of course "__main__" can be a different module name if appropriate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1397474&group_id=5470 From noreply at sourceforge.net Thu Jan 5 06:45:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 Jan 2006 21:45:30 -0800 Subject: [ python-Bugs-1332873 ] BSD DB test failures for BSD DB 4.1 Message-ID: Bugs item #1332873, was opened at 2005-10-19 22:30 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1332873&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Gregory P. Smith (greg) Summary: BSD DB test failures for BSD DB 4.1 Initial Comment: ====================================================================== FAIL: test01_associateWithDB (bsddb.test.test_associate.AssociateHashTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 220, in test01_associateWithDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: ('99', 'unknown artist|Unnamed song|Unknown') ====================================================================== FAIL: test02_associateAfterDB (bsddb.test.test_associate.AssociateHashTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 240, in test02_associateAfterDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: ('99', 'unknown artist|Unnamed song|Unknown') ====================================================================== FAIL: test01_associateWithDB (bsddb.test.test_associate.AssociateBTreeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 220, in test01_associateWithDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: ('99', 'unknown artist|Unnamed song|Unknown') ====================================================================== FAIL: test02_associateAfterDB (bsddb.test.test_associate.AssociateBTreeTestCase)---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 240, in test02_associateAfterDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: ('99', 'unknown artist|Unnamed song|Unknown') ====================================================================== FAIL: test01_associateWithDB (bsddb.test.test_associate.AssociateRecnoTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 220, in test01_associateWithDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: (99, 'unknown artist|Unnamed song|Unknown') ====================================================================== FAIL: test02_associateAfterDB (bsddb.test.test_associate.AssociateRecnoTestCase)---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 240, in test02_associateAfterDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: (99, 'unknown artist|Unnamed song|Unknown') ====================================================================== FAIL: test01_associateWithDB (bsddb.test.test_associate.AssociateBTreeTxnTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 220, in test01_associateWithDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: ('99', 'unknown artist|Unnamed song|Unknown') ====================================================================== FAIL: test02_associateAfterDB (bsddb.test.test_associate.AssociateBTreeTxnTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 240, in test02_associateAfterDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: ('99', 'unknown artist|Unnamed song|Unknown') ====================================================================== FAIL: test13_associate_in_transaction (bsddb.test.test_associate.AssociateBTreeTxnTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 364, in test13_associate_in_transaction self.txn_finish_test(self.secDB, txn=txn) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 331, in txn_finish_test self.finish_test(sDB, txn=txn) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: ('99', 'unknown artist|Unnamed song|Unknown') ====================================================================== FAIL: test01_associateWithDB (bsddb.test.test_associate.ShelveAssociateHashTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 220, in test01_associateWithDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: ('99', '(U\x0eunknown artistU\x0cUnnamed songU\x07Unknownq\x01tq\x02.') ====================================================================== FAIL: test02_associateAfterDB (bsddb.test.test_associate.ShelveAssociateHashTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 240, in test02_associateAfterDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: ('99', '(U\x0eunknown artistU\x0cUnnamed songU\x07Unknownq\x01tq\x02.') ====================================================================== FAIL: test01_associateWithDB (bsddb.test.test_associate.ShelveAssociateBTreeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 220, in test01_associateWithDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: ('99', '(U\x0eunknown artistU\x0cUnnamed songU\x07Unknownq\x01tq\x02.') ====================================================================== FAIL: test02_associateAfterDB (bsddb.test.test_associate.ShelveAssociateBTreeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 240, in test02_associateAfterDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: ('99', '(U\x0eunknown artistU\x0cUnnamed songU\x07Unknownq\x01tq\x02.') ====================================================================== FAIL: test01_associateWithDB (bsddb.test.test_associate.ShelveAssociateRecnoTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 220, in test01_associateWithDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: (99, '(U\x0eunknown artistU\x0cUnnamed songU\x07Unknownq\x01tq\x02.') ====================================================================== FAIL: test02_associateAfterDB (bsddb.test.test_associate.ShelveAssociateRecnoTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 240, in test02_associateAfterDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: (180388626531, '(U\x0eunknown artistU\x0cUnnamed songU\x07Unknownq\x01tq\x02.') ====================================================================== FAIL: test01_associateWithDB (bsddb.test.test_associate.ThreadedAssociateHashTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 220, in test01_associateWithDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: ('99', '(U\x0eunknown artistU\x0cUnnamed songU\x07Unknownq\x01tq\x02.') ====================================================================== FAIL: test02_associateAfterDB (bsddb.test.test_associate.ThreadedAssociateHashTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 240, in test02_associateAfterDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: ('99', '(U\x0eunknown artistU\x0cUnnamed songU\x07Unknownq\x01tq\x02.') ====================================================================== FAIL: test01_associateWithDB (bsddb.test.test_associate.ThreadedAssociateBTreeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 220, in test01_associateWithDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: ('99', '(U\x0eunknown artistU\x0cUnnamed songU\x07Unknownq\x01tq\x02.') ====================================================================== FAIL: test02_associateAfterDB (bsddb.test.test_associate.ThreadedAssociateBTreeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 240, in test02_associateAfterDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: ('99', '(U\x0eunknown artistU\x0cUnnamed songU\x07Unknownq\x01tq\x02.') ====================================================================== FAIL: test01_associateWithDB (bsddb.test.test_associate.ThreadedAssociateRecnoTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 220, in test01_associateWithDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: (99, '(U\x0eunknown artistU\x0cUnnamed songU\x07Unknownq\x01tq\x02.') ====================================================================== FAIL: test02_associateAfterDB (bsddb.test.test_associate.ThreadedAssociateRecnoTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 240, in test02_associateAfterDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: (180388626531, '(U\x0eunknown artistU\x0cUnnamed songU\x07Unknownq\x01tq\x02.') ---------------------------------------------------------------------- ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-04 21:45 Message: Logged In: YES user_id=33168 Some of these were a 64 bit problem and were fixed in Committed revision 41915. Committed revision 41916. These are still a problem: test01_associateWithDB (bsddb.test.test_associate.AssociateHashTestCase) ... FAIL test02_associateAfterDB (bsddb.test.test_associate.AssociateHashTestCase) ... FAIL test01_associateWithDB (bsddb.test.test_associate.AssociateBTreeTestCase) ... FAIL test02_associateAfterDB (bsddb.test.test_associate.AssociateBTreeTestCase) ... FAIL test01_associateWithDB (bsddb.test.test_associate.AssociateRecnoTestCase) ... FAIL test02_associateAfterDB (bsddb.test.test_associate.AssociateRecnoTestCase) ... FAIL test01_associateWithDB (bsddb.test.test_associate.AssociateBTreeTxnTestCase) ... FAIL test02_associateAfterDB (bsddb.test.test_associate.AssociateBTreeTxnTestCase) ... FAIL test13_associate_in_transaction (bsddb.test.test_associate.AssociateBTreeTxnTestCase) ... FAIL test01_associateWithDB (bsddb.test.test_associate.ShelveAssociateHashTestCase) ... FAIL test02_associateAfterDB (bsddb.test.test_associate.ShelveAssociateHashTestCase) ... FAIL test01_associateWithDB (bsddb.test.test_associate.ShelveAssociateBTreeTestCase) ... FAIL test02_associateAfterDB (bsddb.test.test_associate.ShelveAssociateBTreeTestCase) ... FAIL test01_associateWithDB (bsddb.test.test_associate.ShelveAssociateRecnoTestCase) ... FAIL test02_associateAfterDB (bsddb.test.test_associate.ShelveAssociateRecnoTestCase) ... FAIL test01_associateWithDB (bsddb.test.test_associate.ThreadedAssociateHashTestCase) ... FAIL test02_associateAfterDB (bsddb.test.test_associate.ThreadedAssociateHashTestCase) ... FAIL test01_associateWithDB (bsddb.test.test_associate.ThreadedAssociateBTreeTestCase) ... FAIL test02_associateAfterDB (bsddb.test.test_associate.ThreadedAssociateBTreeTestCase) ... FAIL test01_associateWithDB (bsddb.test.test_associate.ThreadedAssociateRecnoTestCase) ... FAIL test02_associateAfterDB (bsddb.test.test_associate.ThreadedAssociateRecnoTestCase) ... FAIL ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1332873&group_id=5470 From noreply at sourceforge.net Thu Jan 5 06:47:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 Jan 2006 21:47:00 -0800 Subject: [ python-Bugs-1396622 ] TimedRotatingFileHandler midnight rollover time increases Message-ID: Bugs item #1396622, was opened at 2006-01-04 00:25 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396622&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Waters (awaters) >Assigned to: Vinay Sajip (vsajip) Summary: TimedRotatingFileHandler midnight rollover time increases Initial Comment: When calculating the next rollover time the calculation uses the current time plus the interval. Unless the log file is written exactly at midnight the rollover time becomes the current time + 1 day. So for example, if the log is written at 2:00am then the next rollover time will be 2:00am the following day rather than midnight. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-04 21:46 Message: Logged In: YES user_id=33168 Vinay, any comments? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396622&group_id=5470 From noreply at sourceforge.net Thu Jan 5 06:47:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 Jan 2006 21:47:55 -0800 Subject: [ python-Bugs-1396040 ] TimedRotatingFileHandler does not recover from open error Message-ID: Bugs item #1396040, was opened at 2006-01-03 06:38 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396040&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Waters (awaters) >Assigned to: Vinay Sajip (vsajip) Summary: TimedRotatingFileHandler does not recover from open error Initial Comment: When doing a rollover TimedRotatingFileHandler doRollover does not recover if there is an open error. This is because when the rollover function fails at the open (e.g. too many files open) and is called again at the next attempt to write to the log doRollover attempts to rename (the now no longer existing) original file which raises an exception. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396040&group_id=5470 From noreply at sourceforge.net Thu Jan 5 06:48:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 Jan 2006 21:48:09 -0800 Subject: [ python-Bugs-1396030 ] TimedRotatingFileHandler at midnight rolls over at 01:00 Message-ID: Bugs item #1396030, was opened at 2006-01-03 06:26 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396030&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Waters (awaters) >Assigned to: Vinay Sajip (vsajip) Summary: TimedRotatingFileHandler at midnight rolls over at 01:00 Initial Comment: Using TimedRotatingFileHandler with interval set to midnight rolls the log over at 1:00am rather than midnight. (LocalTime = GMT). This is because the calculation of seconds until midnight is incorrect (it behaves as if there are 24 hours, 59 minutes and 59 seconds in the day). It also means that should a program stop between midnight and 1:00am and restart it fails to roll over the log as the log over time is set to 1:00am the next day. Occurs on Linux (FC3), Windows XP (SP2). Bug occurs (2.4.2 and currently exists in most recent 2.5 SVN code). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396030&group_id=5470 From noreply at sourceforge.net Thu Jan 5 06:52:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 Jan 2006 21:52:36 -0800 Subject: [ python-Bugs-1395511 ] Please document pyc format guarantees Message-ID: Bugs item #1395511, was opened at 2006-01-02 11:27 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1395511&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Joe Wreschnig (piman) Assigned to: Nobody/Anonymous (nobody) Summary: Please document pyc format guarantees Initial Comment: There's conventional wisdom that .pyc files are compatible within a single minor revision of Python, but I can't find any documentation that says this explicitly. This assumption is important to Debian's Python packaging policy, so if it's true, could it be documented somewhere (probably the marshal or compileall module documentation)? Thanks. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-04 21:52 Message: Logged In: YES user_id=33168 It is documented here: http://www.python.org/peps/pep-0006.html Is that sufficient? It's also effectively documented here: http://svn.python.org/projects/python/trunk/Python/import.c That is a list of all magic numbers which denote the python revision. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1395511&group_id=5470 From noreply at sourceforge.net Thu Jan 5 06:54:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 Jan 2006 21:54:31 -0800 Subject: [ python-Bugs-1396678 ] bsddb.__init__ causes error Message-ID: Bugs item #1396678, was opened at 2006-01-04 01:56 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396678&group_id=5470 Please note that this 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 Submitted By: Fabian_M (fmareyen) Assigned to: Nobody/Anonymous (nobody) Summary: bsddb.__init__ causes error Initial Comment: I've found an Error in the bsddb.__init__.py-module: pythonversion = 2.4 (problem may also be in version 2.3) After creating and closing a db with bsddb.hashopen I called globals(). Next there occured an Error: #Error-Message --------------------------------------------- >>> globals() {'__builtins__': , 'f4': , 'dbtest1': Traceback (most recent call last): File "", line 1, in ? File "D:\Programme\python24\lib\UserDict.py", line 162, in __repr__ return repr(dict(self.iteritems())) File "", line 46, in iteritems File "", line 4, in _make_iter_cursor AttributeError: 'NoneType' object has no attribute 'cursor' >>> ---------------------------------------------- #Way of the Error The way of the Error is: 1. globals() asked for bsddb._DBWithCursor.__repr__ with the __repr__-method inherriting from bsddb._iter_mixin based on UserDict.DictMixin. 2. The __repr__-method in UserDict.DictMixin at line 162 calls self.iteritems overwritten by bsddb._iter_mixin.iteritems at line 113. 3. This method calls self._make_iter_cursor (line 115). bsddb._iter_mixin._make_iter_cursor calls bsddb.db which was set to None at closing the bd with db.close() at line 223. #Solution: That way the error was created. To avoid this, the bsddb._iter_mixin.iteritems-method should be something like this: ------------------------- def iteritems(self): if not self.db: return "" try: cur = self._make_iter_cursor() ... ... ------------------------- ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-04 21:54 Message: Logged In: YES user_id=33168 Can you attach a complete test case which demonstrates this behaviour? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396678&group_id=5470 From noreply at sourceforge.net Thu Jan 5 07:19:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 04 Jan 2006 22:19:12 -0800 Subject: [ python-Bugs-1395511 ] Please document pyc format guarantees Message-ID: Bugs item #1395511, was opened at 2006-01-02 19:27 Message generated for change (Comment added) made by piman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1395511&group_id=5470 Please note that this 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: Works For Me Priority: 5 Submitted By: Joe Wreschnig (piman) Assigned to: Nobody/Anonymous (nobody) Summary: Please document pyc format guarantees Initial Comment: There's conventional wisdom that .pyc files are compatible within a single minor revision of Python, but I can't find any documentation that says this explicitly. This assumption is important to Debian's Python packaging policy, so if it's true, could it be documented somewhere (probably the marshal or compileall module documentation)? Thanks. ---------------------------------------------------------------------- >Comment By: Joe Wreschnig (piman) Date: 2006-01-05 06:19 Message: Logged In: YES user_id=796 Yes, PEP 6 is great, thank you! Sorry that I forgot to check there. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-05 05:52 Message: Logged In: YES user_id=33168 It is documented here: http://www.python.org/peps/pep-0006.html Is that sufficient? It's also effectively documented here: http://svn.python.org/projects/python/trunk/Python/import.c That is a list of all magic numbers which denote the python revision. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1395511&group_id=5470 From noreply at sourceforge.net Thu Jan 5 13:28:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Jan 2006 04:28:36 -0800 Subject: [ python-Bugs-1368768 ] clearing up dictionary keys/set member docs Message-ID: Bugs item #1368768, was opened at 2005-11-28 20:40 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368768&group_id=5470 Please note that this 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: 5 Submitted By: Mike Meyer (mwm) Assigned to: Nobody/Anonymous (nobody) Summary: clearing up dictionary keys/set member docs Initial Comment: The documentation for dictionaries says "A dictionary's keys are almost arbitrary values. Only values containing lists, dictionaries or other mutable types (that are compared by value rather than by object identity) may not be used as keys." This is wrong. tuples are an immutable type, but not all tuples can be used as keys. The set documentation says "A set object is an unordered collection of immutable values.". This is also wrong - at least for common definitions of immutable. Immutability is a convenient way of dealing with builtin types, but is a red herring. It's whether or not the object has a hash value that matters, and it's the behavior of that hash value (coupled with comparison) that determine whether or not things behave as expected. The __hash__ documentation deals with these issues. I suggest replacing the current descriptions with one that references hashing, and a footnote pointing to the __hash__ docs for details: Any hashable object(1) can be used as a dictionary key/set element. Lists, sets and dicts are not hashable, and can not be used. Tuples can be used if all the things they contain are hashable. Instances of all other built-in types and most user-defined classes are hashable. (1) Objects for which the hash() function returns an appropriate value. See the __hash__ documentation for details. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-01-05 07:28 Message: Logged In: YES user_id=1344176 I have submitted patch #1397711 which resolves this issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368768&group_id=5470 From noreply at sourceforge.net Thu Jan 5 14:54:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Jan 2006 05:54:50 -0800 Subject: [ python-Bugs-1389157 ] test_tarfile fails with readonly source dir for Python 2.4.2 Message-ID: Bugs item #1389157, was opened at 2005-12-23 22:29 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1389157&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Langly (langly) Assigned to: Nobody/Anonymous (nobody) Summary: test_tarfile fails with readonly source dir for Python 2.4.2 Initial Comment: When compiling Python-2.4.2 and using separate source and build directories, the test_tarfile test fails if the source directory is read-only. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2006-01-05 14:54 Message: Logged In: YES user_id=1188172 How do you compile Python using separate source and build directories? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1389157&group_id=5470 From noreply at sourceforge.net Thu Jan 5 16:08:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Jan 2006 07:08:34 -0800 Subject: [ python-Feature Requests-1397806 ] python.org - add RFE tracker Message-ID: Feature Requests item #1397806, was opened at 2006-01-05 10:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1397806&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: python.org - add RFE tracker Initial Comment: On http://www.python.org/, the left hand column includes a "Community" section with a "Python Project:" subsection. This links to the bugs and patches tracker, (and to svn). It should also link to the Request For Enhancement tracker http://sourceforge.net/tracker/? group_id=5470&atid=355470 to make it a bit more likely that such requests will not be filed as bugs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1397806&group_id=5470 From noreply at sourceforge.net Thu Jan 5 16:34:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Jan 2006 07:34:24 -0800 Subject: [ python-Bugs-1396471 ] file.tell() returns illegal value on Windows Message-ID: Bugs item #1396471, was opened at 2006-01-04 02:53 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396471&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None >Priority: 7 Submitted By: Tom Goddard (tom_goddard) Assigned to: Nobody/Anonymous (nobody) Summary: file.tell() returns illegal value on Windows Initial Comment: The file tell() method returns an illegal value that causes an exception when passed to seek(). This happens on Windows when a file that contains unix-style newlines '\n' is opened and read in text mode 'r'. Below is code that produces the problem on Windows 2.4.2 in an IDLE shell. The bug does not occur when using mode 'rU' or 'rb'. But I expect correct behaviour with mode 'r'. My understanding is that 'rU' translates line endings to '\n' in the returned string while mode 'r' still correctly reads the lines using readline(), recognizing all 3 common endline conventions, but does not translate (ie includes \n\r or \r or \n in returned string). The error in the tell() return value depends on how long the file is. Changing the 'more\n'*10 line in the example code will cause different incorrect return values. Previous bug reports have mentioned problems with tell/seek when using file iterators, the file.next() method and the "for line in file:" construct. This bug is different and just involves readline() and tell() with mode 'r'. Example code tellbug.py follows: wf = open('testdata', 'wb') wf.write('01234\n56789\n'+ 'more\n'*10) wf.close() f = open('testdata', 'r') f.readline() t = f.tell() print t f.seek(t) ------- Running gives: >>> execfile('tellbug.py') -5 Traceback (most recent call last): File "", line 1, in -toplevel- execfile('tellbug.py') File "tellbug.py", line 9, in -toplevel- f.seek(t) IOError: [Errno 22] Invalid argument ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396471&group_id=5470 From noreply at sourceforge.net Thu Jan 5 16:45:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Jan 2006 07:45:24 -0800 Subject: [ python-Bugs-1394565 ] SimpleHTTPServer doesn't understand query arguments Message-ID: Bugs item #1394565, was opened at 2005-12-31 15:46 Message generated for change (Comment added) made by aaronsw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394565&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Aaron Swartz (aaronsw) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleHTTPServer doesn't understand query arguments Initial Comment: If you set the SimpleHTTPServer to serve files and visit /filename it works but if you visit /filename?f=1 it returns a 404. It should strip off the query argument and visit /filename ---------------------------------------------------------------------- >Comment By: Aaron Swartz (aaronsw) Date: 2006-01-05 09:45 Message: Logged In: YES user_id=122141 The patch is to add this line to the top of SimpleHTTPServer.py's translate_path function: path = path.split('?')[0] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394565&group_id=5470 From noreply at sourceforge.net Thu Jan 5 17:01:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 05 Jan 2006 08:01:12 -0800 Subject: [ python-Bugs-1397850 ] libpython2.4.so get not installed Message-ID: Bugs item #1397850, was opened at 2006-01-05 16: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=1397850&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: hajo (hajoehlers) Assigned to: Nobody/Anonymous (nobody) Summary: libpython2.4.so get not installed Initial Comment: Given: AIX 5.1 GCC 3.3.2 Python 2.4.2 ( Python-2.4.2.tar.gz ) ./configure \ --enable-unicode \ --enable-shared \ --with-gcc \ --mandir=/usr/local/man \ --infodir=/usr/local/info Problem: during " gmake install " the libpython2.4.a will not be installed in /usr/local/lib and the link for libpython2.4.so does not exist then. I did not dig further but below is the output from "gmake install" For me the ... if test -f libpython2.4.so; then ... look wrong because it does not contain a Path and will fail. regards Hajo output during "gmake install" ... if test -f libpython2.4.so; then \^M if test ".so" = .dll; then \^M /opt/freeware/bin/install -c -m 555 libpython2.4.so /usr/local/bin; \^M else \^M /opt/freeware/bin/install -c -m 555 libpython2.4.so /usr/local/lib/libpython2.4.a; \^M if test libpython2.4.so != libpython2.4.a; then \^M (cd /usr/local/lib; ln -sf libpython2.4.a libpython2.4.so); \^M fi \^M fi; \^M else true; \^M ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1397850&group_id=5470 From noreply at sourceforge.net Fri Jan 6 17:24:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 06 Jan 2006 08:24:48 -0800 Subject: [ python-Bugs-1397850 ] libpython2.4.so get not installed Message-ID: Bugs item #1397850, was opened at 2006-01-05 16:01 Message generated for change (Comment added) made by hajoehlers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1397850&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: hajo (hajoehlers) Assigned to: Nobody/Anonymous (nobody) Summary: libpython2.4.so get not installed Initial Comment: Given: AIX 5.1 GCC 3.3.2 Python 2.4.2 ( Python-2.4.2.tar.gz ) ./configure \ --enable-unicode \ --enable-shared \ --with-gcc \ --mandir=/usr/local/man \ --infodir=/usr/local/info Problem: during " gmake install " the libpython2.4.a will not be installed in /usr/local/lib and the link for libpython2.4.so does not exist then. I did not dig further but below is the output from "gmake install" For me the ... if test -f libpython2.4.so; then ... look wrong because it does not contain a Path and will fail. regards Hajo output during "gmake install" ... if test -f libpython2.4.so; then \^M if test ".so" = .dll; then \^M /opt/freeware/bin/install -c -m 555 libpython2.4.so /usr/local/bin; \^M else \^M /opt/freeware/bin/install -c -m 555 libpython2.4.so /usr/local/lib/libpython2.4.a; \^M if test libpython2.4.so != libpython2.4.a; then \^M (cd /usr/local/lib; ln -sf libpython2.4.a libpython2.4.so); \^M fi \^M fi; \^M else true; \^M ... ---------------------------------------------------------------------- >Comment By: hajo (hajoehlers) Date: 2006-01-06 16:24 Message: Logged In: YES user_id=1420117 Its looked like that the libpython2.4.so will not be build. I took a lock at the Makefile but could not get a clear view what option is needed to let the system build a libpython2.4.so ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1397850&group_id=5470 From noreply at sourceforge.net Fri Jan 6 20:23:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 06 Jan 2006 11:23:06 -0800 Subject: [ python-Bugs-1370322 ] Float marshaling problems with test_colorsys Message-ID: Bugs item #1370322, was opened at 2005-11-30 20:49 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&group_id=5470 Please note that this message 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: Works For Me Priority: 7 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Michael Hudson (mwh) Summary: Float marshaling problems with test_colorsys Initial Comment: Starting point: "make clean; make" in the 2.5 source tree. "make test" hangs at test_colorsys. Careful investigation shows that when the bytecode is freshly generated by "make all" (precisely in test___all__) the .pyc file is different from what a direct call to "regrtest.py test_colorsys" produces. Curiously, a call to "regrtest.py test___all__" instead of "make test" produces the correct bytecode. System is Linux 2.6, x86, gcc 3.4.4. I have attached both versions of colorsys.pyc. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2006-01-06 20:23 Message: Logged In: YES user_id=1188172 This has now vanished. I don't know why, but I did a glibc update today, maybe... ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-11 21:05 Message: Logged In: YES user_id=33168 I can't reproduce (make test) on linux 2.6, gcc 3.4.4, only diff is amd64. I have some outstanding changes, but none that should affect the outcome. Sorry, I don't know what to tell you, can you try to debug any more? Maybe run under valgrind (or other memory debugger) and see if there's a memory issue. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 18:05 Message: Logged In: YES user_id=1188172 Yep, after "make distclean" and even a fresh checkout the problem is there. I configured with and without "--with-pydebug". Okay, Michael, you are rehabilitated: I restored floatobject.c to the state before your patch, and it behaves the same. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-12-10 14:42 Message: Logged In: YES user_id=6656 Umpf. I suppose the one remaining thing is you say you use "make clean". This makes me very faintly suspicious that "make clean" doesn't really clean everything... could you maybe try a clean checkout? Clutching at straws here, obviously. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 14:35 Message: Logged In: YES user_id=1188172 Yes, it is reproducable. If it's local to me, I don't know what could be causing it. I have a SVN tree without local changes on my local box and my laptop, and both of them show the same bug. I'll boot into some CD Linux later and see if the other environment makes it vanish. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-12-10 12:47 Message: Logged In: YES user_id=6656 Also, is the problem reproducable on *your* system? AFAIK, noone else has reproduced it, but I don't know how many people are actually running make test on development Python these days... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-12-10 12:43 Message: Logged In: YES user_id=6656 I don't think so, no. For a start, I can't reproduce the problem (mind you, I only use a Mac regularly these days). ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 12:07 Message: Logged In: YES user_id=1188172 Michael, you lately corrected a problem with floatobject. Although the problem persists here, could it be caused by a similar bug? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-01 11:32 Message: Logged In: YES user_id=4771 It's again a problem with floats. For example, the constant 0.3 in rgb_to_yiq shows up as 0.0 in bad.pyc. The constant 1.72986 shows up as 1.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&group_id=5470 From noreply at sourceforge.net Fri Jan 6 20:23:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 06 Jan 2006 11:23:52 -0800 Subject: [ python-Bugs-1398781 ] Example in section 5.3 "Pure Embedding" doesn't work. Message-ID: Bugs item #1398781, was opened at 2006-01-06 11:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1398781&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bill Studenmund (wrstuden) Assigned to: Nobody/Anonymous (nobody) Summary: Example in section 5.3 "Pure Embedding" doesn't work. Initial Comment: I want to use Python to script an existing application. So I was trying the code on http://docs.python.org/ext/pure-embedding.html and found it didn't work. I am using pkgsrc on NetBSD. I have run into two issues. First, PyDict_GetAttrString() does not exist. I have found this to be true for both Python 2.2 and 2.4, the two versions I currently have installed. I made the simple change to use PyObject_GetAttrString(), which looks right. Second, python can't find the module. I named the file multiply.py, and it wouldn't load. It turns out that I had to set PYTHONPATH in my envirnment to make it work. Setting it to '' (empty string) worked. The odd thing about the path issue is that if I ran the python interpreter, it was able to find the module w/o my changing the environment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1398781&group_id=5470 From noreply at sourceforge.net Fri Jan 6 20:33:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 06 Jan 2006 11:33:28 -0800 Subject: [ python-Bugs-1398781 ] Example in section 5.3 "Pure Embedding" doesn't work. Message-ID: Bugs item #1398781, was opened at 2006-01-06 20:23 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1398781&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bill Studenmund (wrstuden) Assigned to: Nobody/Anonymous (nobody) Summary: Example in section 5.3 "Pure Embedding" doesn't work. Initial Comment: I want to use Python to script an existing application. So I was trying the code on http://docs.python.org/ext/pure-embedding.html and found it didn't work. I am using pkgsrc on NetBSD. I have run into two issues. First, PyDict_GetAttrString() does not exist. I have found this to be true for both Python 2.2 and 2.4, the two versions I currently have installed. I made the simple change to use PyObject_GetAttrString(), which looks right. Second, python can't find the module. I named the file multiply.py, and it wouldn't load. It turns out that I had to set PYTHONPATH in my envirnment to make it work. Setting it to '' (empty string) worked. The odd thing about the path issue is that if I ran the python interpreter, it was able to find the module w/o my changing the environment. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2006-01-06 20:33 Message: Logged In: YES user_id=1188172 The PyDict_GetAttrString issue is corrected in the current devel docs. No clue about the other. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1398781&group_id=5470 From noreply at sourceforge.net Fri Jan 6 23:48:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 06 Jan 2006 14:48:08 -0800 Subject: [ python-Bugs-1398781 ] Example in section 5.3 "Pure Embedding" doesn't work. Message-ID: Bugs item #1398781, was opened at 2006-01-06 11:23 Message generated for change (Comment added) made by wrstuden You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1398781&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bill Studenmund (wrstuden) Assigned to: Nobody/Anonymous (nobody) Summary: Example in section 5.3 "Pure Embedding" doesn't work. Initial Comment: I want to use Python to script an existing application. So I was trying the code on http://docs.python.org/ext/pure-embedding.html and found it didn't work. I am using pkgsrc on NetBSD. I have run into two issues. First, PyDict_GetAttrString() does not exist. I have found this to be true for both Python 2.2 and 2.4, the two versions I currently have installed. I made the simple change to use PyObject_GetAttrString(), which looks right. Second, python can't find the module. I named the file multiply.py, and it wouldn't load. It turns out that I had to set PYTHONPATH in my envirnment to make it work. Setting it to '' (empty string) worked. The odd thing about the path issue is that if I ran the python interpreter, it was able to find the module w/o my changing the environment. ---------------------------------------------------------------------- >Comment By: Bill Studenmund (wrstuden) Date: 2006-01-06 14:48 Message: Logged In: YES user_id=148388 Great to hear about PyDict_GetAttrString(). I assume that PyObject_GetAttrString() was the correct change? It turns out the second issue deals with path processing in the embedded code being somehow different from processing in the interpreter. I think the interpreter sets something up that isn't present for the embedded example. I will really appreciate it if we could figure out what's different and add it to the docs. The pictured behavior for "call" is exactly what I want, but not what I get. To be more specific, I had my code print Py_GetPath(), and I compared that with sys.path from the interpreter. C code looking for foo.py (which is in '.'): > ./obj.i386/test foo Path is '/usr/pkg/lib/python24.zip:/usr/pkg/lib/python2.4/:/usr/pkg/lib/python2.4/plat-netbsd3:/usr/pkg/lib/python2.4/lib-tk:/usr/pkg/lib/python2.4/lib-dynload' ImportError: No module named foo utest: loading module foo: No such file or directory In the python interpreter: > python2.4 Python 2.4.1 (#1, Dec 28 2005, 15:58:29) [GCC 3.3.3 (Wasabi NetBSD nb3 20040520)] on netbsd3 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> print sys.path ['', '/usr/pkg/lib/python24.zip', '/usr/pkg/lib/python2.4', '/usr/pkg/lib/python2.4/plat-netbsd3', '/usr/pkg/lib/python2.4/lib-tk', '/usr/pkg/lib/python2.4/lib-dynload', '/usr/pkg/lib/python2.4/site-packages'] The key difference is the '' at the front of the path in the interpreter. Any thoughts? Is there a different list or FAQ I should look at? ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2006-01-06 11:33 Message: Logged In: YES user_id=1188172 The PyDict_GetAttrString issue is corrected in the current devel docs. No clue about the other. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1398781&group_id=5470 From noreply at sourceforge.net Sat Jan 7 11:04:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 Jan 2006 02:04:38 -0800 Subject: [ python-Bugs-1399099 ] i get a memory leak after using split() function on windows Message-ID: Bugs item #1399099, was opened at 2006-01-07 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=1399099&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Leo Jay (leojay) Assigned to: Nobody/Anonymous (nobody) Summary: i get a memory leak after using split() function on windows Initial Comment: my environment is: python 2.4.2 on windows xp professional with sp2 what i do is just open a text file and count how many lines in that file: D:\>python Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> f = file('b.txt', 'rt') # the size of b.txt is about 100 mega bytes >>> print len(f.read().split('\n')) 899830 >>> f.close() >>> del f >>> after these steps, the task manager shows that the python process still hog about 125 mega bytes memory. and the python don't release these memory until i quit the python. but i find that if i remove the split() function, python acts right: D:\>python Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> f = file('b.txt', 'rt') >>> print len(f.read()) 95867667 >>> so, is there something wrong with the split function? or it's just my misuse of split? Best Regards, Leo Jay ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1399099&group_id=5470 From noreply at sourceforge.net Sat Jan 7 16:54:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 Jan 2006 07:54:43 -0800 Subject: [ python-Bugs-1399099 ] i get a memory leak after using split() function on windows Message-ID: Bugs item #1399099, was opened at 2006-01-07 19:04 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1399099&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Leo Jay (leojay) Assigned to: Nobody/Anonymous (nobody) Summary: i get a memory leak after using split() function on windows Initial Comment: my environment is: python 2.4.2 on windows xp professional with sp2 what i do is just open a text file and count how many lines in that file: D:\>python Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> f = file('b.txt', 'rt') # the size of b.txt is about 100 mega bytes >>> print len(f.read().split('\n')) 899830 >>> f.close() >>> del f >>> after these steps, the task manager shows that the python process still hog about 125 mega bytes memory. and the python don't release these memory until i quit the python. but i find that if i remove the split() function, python acts right: D:\>python Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> f = file('b.txt', 'rt') >>> print len(f.read()) 95867667 >>> so, is there something wrong with the split function? or it's just my misuse of split? Best Regards, Leo Jay ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2006-01-08 00:54 Message: Logged In: YES user_id=55188 That's came from pymalloc's behavior. Pymalloc never frees allocated memory in heap. For more informations about this, see a mailing list thread http://mail.python.org/pipermail/python-dev/2004-October/049480.html The usual way to resolve the problem is to utilize iterator style loops instead of reading the whole data at a time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1399099&group_id=5470 From noreply at sourceforge.net Sun Jan 8 00:54:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 07 Jan 2006 15:54:47 -0800 Subject: [ python-Bugs-1399099 ] i get a memory leak after using split() function on windows Message-ID: Bugs item #1399099, was opened at 2006-01-07 05:04 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1399099&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Leo Jay (leojay) Assigned to: Nobody/Anonymous (nobody) Summary: i get a memory leak after using split() function on windows Initial Comment: my environment is: python 2.4.2 on windows xp professional with sp2 what i do is just open a text file and count how many lines in that file: D:\>python Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> f = file('b.txt', 'rt') # the size of b.txt is about 100 mega bytes >>> print len(f.read().split('\n')) 899830 >>> f.close() >>> del f >>> after these steps, the task manager shows that the python process still hog about 125 mega bytes memory. and the python don't release these memory until i quit the python. but i find that if i remove the split() function, python acts right: D:\>python Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> f = file('b.txt', 'rt') >>> print len(f.read()) 95867667 >>> so, is there something wrong with the split function? or it's just my misuse of split? Best Regards, Leo Jay ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-01-07 18:54 Message: Logged In: YES user_id=31435 Specifically, you end up with about a million string objects simultaneously alive. That consumes about 24 million bytes for string object headers, + another 100 million bytes for the string contents. Python can reuse all that memory later, but pymalloc does not (as perky said) "give it back". Do note that this is an extraordinarily slow and wasteful way to count lines. If that's what you want and you don't care about peak memory use, then f.read().count('\n') is one simpler and faster way that creates only one string object. The string object is so large in that case (about 100 million bytes) that pymalloc delegates memory management to the platform malloc. Whether or not the platform malloc "gives back" its memory to the OS is a wholly different question, and one over which Python has no control. On Windows NT+ it's very likely to, though. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-01-07 10:54 Message: Logged In: YES user_id=55188 That's came from pymalloc's behavior. Pymalloc never frees allocated memory in heap. For more informations about this, see a mailing list thread http://mail.python.org/pipermail/python-dev/2004-October/049480.html The usual way to resolve the problem is to utilize iterator style loops instead of reading the whole data at a time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1399099&group_id=5470 From noreply at sourceforge.net Sun Jan 8 11:08:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 Jan 2006 02:08:29 -0800 Subject: [ python-Bugs-880996 ] 2.3.3 make fails build posix_openpty' Message-ID: Bugs item #880996, was opened at 2004-01-21 01:28 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=880996&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: David Dyck (dcd) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3.3 make fails build posix_openpty' Initial Comment: I'm trying to build 2.3.3 on an older slackware system that is still libc5 based. (gcc version egcs-2.91.66.1) configure / make reports errors after stripping warnings the error is reported as: ./Modules/posixmodule.c: In function `posix_openpty': ./Modules/posixmodule.c:2623: `I_PUSH' undeclared (first use in this function) ./Modules/posixmodule.c:2623: (Each undeclared identifier is reported only once ./Modules/posixmodule.c:2623: for each function it appears in.) pyconfig.h only defined HAVE_DEV_PTMX #define HAVE_DEV_PTMX 1 /* #undef HAVE_OPENPTY */ /* #undef HAVE__GETPTY */ (I have a recent 2.4.25-pre6 kernel so I do have /dev/ptmx that configure uses to check for HAVE_DEV_PTMX) ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-01-08 11:08 Message: Logged In: YES user_id=21627 This should be fixed with patch #881820 now. ---------------------------------------------------------------------- Comment By: David Dyck (dcd) Date: 2004-01-24 07:17 Message: Logged In: YES user_id=53855 I submitted a patch # 881820 relative to 2.4 ---------------------------------------------------------------------- Comment By: David Dyck (dcd) Date: 2004-01-21 19:58 Message: Logged In: YES user_id=53855 I have found that I have libbsd.a but not libutil (that is checked for openpty by configure) cd /usr/lib nm -g libbsd.a | grep ' T openpty' 00000000 T openpty If I create a fake libutil.a as a symlink to libbsd.a (ln -s libbsd.a libutil.a) configure and make run to completion It would have been "nicer" if configure had looked for libbsd looks like configure.in could be modified to check for libbsd by adding a line like AC_CHECK_FUNCS(openpty,, AC_CHECK_LIB(bsd,openpty,[AC_DEFINE(HAVE_OPENPTY) LIB S="$LIBS -lbsd"])) after AC_CHECK_FUNCS(openpty,, AC_CHECK_LIB(util,openpty, [AC_DEFINE(HAVE_OPENPTY) LIB S="$LIBS -lutil"])) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=880996&group_id=5470 From noreply at sourceforge.net Sun Jan 8 18:07:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 Jan 2006 09:07:03 -0800 Subject: [ python-Bugs-1396678 ] bsddb.__init__ causes error Message-ID: Bugs item #1396678, was opened at 2006-01-04 10:56 Message generated for change (Comment added) made by fmareyen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396678&group_id=5470 Please note that this 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 Submitted By: Fabian_M (fmareyen) Assigned to: Nobody/Anonymous (nobody) Summary: bsddb.__init__ causes error Initial Comment: I've found an Error in the bsddb.__init__.py-module: pythonversion = 2.4 (problem may also be in version 2.3) After creating and closing a db with bsddb.hashopen I called globals(). Next there occured an Error: #Error-Message --------------------------------------------- >>> globals() {'__builtins__': , 'f4': , 'dbtest1': Traceback (most recent call last): File "", line 1, in ? File "D:\Programme\python24\lib\UserDict.py", line 162, in __repr__ return repr(dict(self.iteritems())) File "", line 46, in iteritems File "", line 4, in _make_iter_cursor AttributeError: 'NoneType' object has no attribute 'cursor' >>> ---------------------------------------------- #Way of the Error The way of the Error is: 1. globals() asked for bsddb._DBWithCursor.__repr__ with the __repr__-method inherriting from bsddb._iter_mixin based on UserDict.DictMixin. 2. The __repr__-method in UserDict.DictMixin at line 162 calls self.iteritems overwritten by bsddb._iter_mixin.iteritems at line 113. 3. This method calls self._make_iter_cursor (line 115). bsddb._iter_mixin._make_iter_cursor calls bsddb.db which was set to None at closing the bd with db.close() at line 223. #Solution: That way the error was created. To avoid this, the bsddb._iter_mixin.iteritems-method should be something like this: ------------------------- def iteritems(self): if not self.db: return "" try: cur = self._make_iter_cursor() ... ... ------------------------- ---------------------------------------------------------------------- >Comment By: Fabian_M (fmareyen) Date: 2006-01-08 18:07 Message: Logged In: YES user_id=1418961 I've added an example-file. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-05 06:54 Message: Logged In: YES user_id=33168 Can you attach a complete test case which demonstrates this behaviour? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396678&group_id=5470 From noreply at sourceforge.net Sun Jan 8 22:50:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 Jan 2006 13:50:28 -0800 Subject: [ python-Feature Requests-1399936 ] Add str.partition Message-ID: Feature Requests item #1399936, was opened at 2006-01-08 22:50 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=1399936&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Georg Brandl (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: Add str.partition Initial Comment: This is mostly here that the idea does not get lost. See http://mail.python.org/pipermail/python-dev/2005-August/055781.html for reference implementation and discussion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1399936&group_id=5470 From noreply at sourceforge.net Mon Jan 9 01:50:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 Jan 2006 16:50:28 -0800 Subject: [ python-Feature Requests-1399936 ] Add str.partition Message-ID: Feature Requests item #1399936, was opened at 2006-01-08 16:50 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1399936&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Georg Brandl (birkenfeld) >Assigned to: Raymond Hettinger (rhettinger) Summary: Add str.partition Initial Comment: This is mostly here that the idea does not get lost. See http://mail.python.org/pipermail/python-dev/2005-August/055781.html for reference implementation and discussion. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-01-08 19:50 Message: Logged In: YES user_id=80475 It's not lost. Will stay on my todo list until the time arises. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1399936&group_id=5470 From noreply at sourceforge.net Mon Jan 9 06:21:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 Jan 2006 21:21:11 -0800 Subject: [ python-Bugs-1397850 ] libpython2.4.so get not installed Message-ID: Bugs item #1397850, was opened at 2006-01-05 08:01 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1397850&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: hajo (hajoehlers) Assigned to: Nobody/Anonymous (nobody) Summary: libpython2.4.so get not installed Initial Comment: Given: AIX 5.1 GCC 3.3.2 Python 2.4.2 ( Python-2.4.2.tar.gz ) ./configure \ --enable-unicode \ --enable-shared \ --with-gcc \ --mandir=/usr/local/man \ --infodir=/usr/local/info Problem: during " gmake install " the libpython2.4.a will not be installed in /usr/local/lib and the link for libpython2.4.so does not exist then. I did not dig further but below is the output from "gmake install" For me the ... if test -f libpython2.4.so; then ... look wrong because it does not contain a Path and will fail. regards Hajo output during "gmake install" ... if test -f libpython2.4.so; then \^M if test ".so" = .dll; then \^M /opt/freeware/bin/install -c -m 555 libpython2.4.so /usr/local/bin; \^M else \^M /opt/freeware/bin/install -c -m 555 libpython2.4.so /usr/local/lib/libpython2.4.a; \^M if test libpython2.4.so != libpython2.4.a; then \^M (cd /usr/local/lib; ln -sf libpython2.4.a libpython2.4.so); \^M fi \^M fi; \^M else true; \^M ... ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-08 21:21 Message: Logged In: YES user_id=33168 The problem seems to be in configure.in. Search for Py_ENABLE_SHARED. Try adding a line for LDLIBRARY (like for BeOS). You may also need a line for INSTSONAME and others variables too. After modifying configure.in, you will need to regenerate with autoconf. You can try modifying configure which is generated by autoconf. Then re-run configure. Search for libpython in the generated Makefile. That should have a .so ending. ---------------------------------------------------------------------- Comment By: hajo (hajoehlers) Date: 2006-01-06 08:24 Message: Logged In: YES user_id=1420117 Its looked like that the libpython2.4.so will not be build. I took a lock at the Makefile but could not get a clear view what option is needed to let the system build a libpython2.4.so ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1397850&group_id=5470 From noreply at sourceforge.net Mon Jan 9 06:34:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 Jan 2006 21:34:24 -0800 Subject: [ python-Bugs-1397850 ] libpython2.4.so get not installed Message-ID: Bugs item #1397850, was opened at 2006-01-05 08:01 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1397850&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: hajo (hajoehlers) Assigned to: Nobody/Anonymous (nobody) Summary: libpython2.4.so get not installed Initial Comment: Given: AIX 5.1 GCC 3.3.2 Python 2.4.2 ( Python-2.4.2.tar.gz ) ./configure \ --enable-unicode \ --enable-shared \ --with-gcc \ --mandir=/usr/local/man \ --infodir=/usr/local/info Problem: during " gmake install " the libpython2.4.a will not be installed in /usr/local/lib and the link for libpython2.4.so does not exist then. I did not dig further but below is the output from "gmake install" For me the ... if test -f libpython2.4.so; then ... look wrong because it does not contain a Path and will fail. regards Hajo output during "gmake install" ... if test -f libpython2.4.so; then \^M if test ".so" = .dll; then \^M /opt/freeware/bin/install -c -m 555 libpython2.4.so /usr/local/bin; \^M else \^M /opt/freeware/bin/install -c -m 555 libpython2.4.so /usr/local/lib/libpython2.4.a; \^M if test libpython2.4.so != libpython2.4.a; then \^M (cd /usr/local/lib; ln -sf libpython2.4.a libpython2.4.so); \^M fi \^M fi; \^M else true; \^M ... ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-08 21:34 Message: Logged In: YES user_id=33168 The problem seems to be in configure.in. Search for Py_ENABLE_SHARED. Try adding a line for LDLIBRARY (like for BeOS). You may also need a line for INSTSONAME and others variables too. After modifying configure.in, you will need to regenerate with autoconf. You can try modifying configure which is generated by autoconf. Then re-run configure. Search for libpython in the generated Makefile. That should have a .so ending. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-08 21:21 Message: Logged In: YES user_id=33168 The problem seems to be in configure.in. Search for Py_ENABLE_SHARED. Try adding a line for LDLIBRARY (like for BeOS). You may also need a line for INSTSONAME and others variables too. After modifying configure.in, you will need to regenerate with autoconf. You can try modifying configure which is generated by autoconf. Then re-run configure. Search for libpython in the generated Makefile. That should have a .so ending. ---------------------------------------------------------------------- Comment By: hajo (hajoehlers) Date: 2006-01-06 08:24 Message: Logged In: YES user_id=1420117 Its looked like that the libpython2.4.so will not be build. I took a lock at the Makefile but could not get a clear view what option is needed to let the system build a libpython2.4.so ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1397850&group_id=5470 From noreply at sourceforge.net Mon Jan 9 06:37:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 Jan 2006 21:37:16 -0800 Subject: [ python-Bugs-1066545 ] SegFault in interactive mode when cursor is over a non-ASCII Message-ID: Bugs item #1066545, was opened at 2004-11-15 01:31 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066545&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.3 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: theIgel (theigel) Assigned to: Neal Norwitz (nnorwitz) Summary: SegFault in interactive mode when cursor is over a non-ASCII Initial Comment: I'm running python2.3.3 as shipped with Mandrake 10.0 Official. Locale is ru_RU (KOI8-R). When running python in intercative mode (tested in KDE's Konsole and Xterm), I get SegFault each time I press almost any key while a cyrillic character is under cursor. Say, I type: >>> s = 'что за черт' Then I move the cursor using arrow keys somewhere to the middle of the string. Now if I press a letter (no matter english or russian keymap being active) or backspace, or maybe other keys, the interpreter crashes. The arrow keys themselves are working without problems. It doesn't happen if an ASCII character is under cursor. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-08 21:37 Message: Logged In: YES user_id=33168 Close enough to a month. Closing due to lack of information/repeatability. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-18 21:10 Message: Logged In: YES user_id=33168 Is this still a problem? Can anyone reproduce? If we don't hear back within a month, this should be closed. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-11-16 06:36 Message: Logged In: YES user_id=55188 It seems to work for me for same input on ru_RU.KOI8-R locale. My terminal app is gnome-terminal and tested platforms are: - FreeBSD 5.3 with readline 4.3 - Debian stable with readline 4.2a - Debian testing with readline 4.3 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-11-16 00:40 Message: Logged In: YES user_id=6656 Hrm. Maybe it's not a readline bug then. OTOH, I've not heard of a Python bug like this either. Do you know how to use gdb? (It's possible that bash uses its own version of readline). ---------------------------------------------------------------------- Comment By: theIgel (theigel) Date: 2004-11-15 06:39 Message: Logged In: YES user_id=1151790 libreadline4-4.3-7mdk So it's 4.3 But if it were a readline bug, wouldn't it mean it should appear in other console applications? It doesn't, at least in shell. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-11-15 06:18 Message: Logged In: YES user_id=6656 Ask Mandrake. Mandrake is rpm-based, right? So rpm -q readline should work. ---------------------------------------------------------------------- Comment By: theIgel (theigel) Date: 2004-11-15 04:37 Message: Logged In: YES user_id=1151790 How can I find out readline version? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-11-15 01:37 Message: Logged In: YES user_id=6656 What version of readline? I don't think this is going to be a Python bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066545&group_id=5470 From noreply at sourceforge.net Mon Jan 9 06:37:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 Jan 2006 21:37:42 -0800 Subject: [ python-Bugs-1400115 ] segfault in curses.panel with userptr() Message-ID: Bugs item #1400115, was opened at 2006-01-09 00:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1400115&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tom Quetchenbach (virtualphtn) Assigned to: Nobody/Anonymous (nobody) Summary: segfault in curses.panel with userptr() Initial Comment: If a curses.panel object is created with curses.panel.new_panel() and then its userptr() method is called before set_userptr(), the Python interpreter segfaults. Raising an exception or returning None would probably be better. Tested with Python 2.4.2 on Linux 2.6.14 (Debian, Intel Celeron). (Also crashes Python 2.3.5 on the same machine.) Simple testcase is attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1400115&group_id=5470 From noreply at sourceforge.net Mon Jan 9 06:47:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 Jan 2006 21:47:11 -0800 Subject: [ python-Bugs-874534 ] Errors testing python 2.3.3 Message-ID: Bugs item #874534, was opened at 2004-01-10 10:32 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=874534&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Pierre (pierre42) Assigned to: Neal Norwitz (nnorwitz) Summary: Errors testing python 2.3.3 Initial Comment: # gmake test case $MAKEFLAGS in \ *-s*) LD_LIBRARY_PATH=/tmp/Python-2.3.3:/usr/local/lib:/usr/local/qt/lib:/usr/local/kde/lib:/usr/local/pwlib/lib:/usr/local/openh323/lib CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; \ *) LD_LIBRARY_PATH=/tmp/Python-2.3.3:/usr/local/lib:/usr/local/qt/lib:/usr/local/kde/lib:/usr/local/pwlib/lib:/usr/local/openh323/lib CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py build;; \ esac running build running build_ext building 'dbm' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -fno-strict-aliasing -DHAVE_NDBM_H -I. -I/tmp/Python-2.3.3/./Include -I/usr/local/include -I/tmp/Python-2.3.3/Include -I/tmp/Python-2.3.3 -c /tmp/Python-2.3.3/Modules/dbmmodule.c -o build/temp.linux-i686-2.3/dbmmodule.o gcc -shared build/temp.linux-i686-2.3/dbmmodule.o -L/usr/local/lib -o build/lib.linux-i686-2.3/dbm.so *** WARNING: renaming "dbm" since importing it failed: build/lib.linux-i686-2.3/dbm.so: undefined symbol: dbm_firstkey running build_scripts find ./Lib -name '*.py[co]' -print | xargs rm -f LD_LIBRARY_PATH=/tmp/Python-2.3.3:/usr/local/lib:/usr/local/qt/lib:/usr/local/kde/lib:/usr/local/pwlib/lib:/usr/local/openh323/lib ./python -E -tt ./Lib/test/regrtest.py -l test_grammar [...] test_codecs test test_codecs failed -- Traceback (most recent call last): File "/tmp/Python-2.3.3/Lib/test/test_codecs.py", line 333, in test_nameprep raise test_support.TestFailed("Test 3.%d: %s" % (pos+1, str(e))) TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9' test_codeop [...] test_format /tmp/Python-2.3.3/Lib/test/test_format.py:19: FutureWarning: %u/%o/%x/%X of negative int will return a signed string in Python 2.4 and up result = formatstr % args test_fpformat [...] test_re test test_re produced unexpected output: ********************************************************************** *** lines 2-3 of actual output doesn't appear in expected output after line 1: + === Failed incorrectly ('(?u)\\b.\\b', u'\xc4', 0, 'found', u'\xc4') + === Failed incorrectly ('(?u)\\w', u'\xc4', 0, 'found', u'\xc4') ********************************************************************** test_regex [...] test_unicode test test_unicode failed -- errors occurred in test.test_unicode.UnicodeTest test_unicode_file test_unicode_file skipped -- No Unicode filesystem semantics on this platform. test_unicodedata test test_unicodedata failed -- Traceback (most recent call last): File "/tmp/Python-2.3.3/Lib/test/test_unicodedata.py", line 62, in test_method_checksum self.assertEqual(result, self.expectedchecksum) File "/tmp/Python-2.3.3/Lib/unittest.py", line 302, in failUnlessEqual raise self.failureException, \ AssertionError: 'c269de8355871e3210ae8710b45c2ddb0675b9d5' != 'a37276dc2c158bef6dfd908ad34525c97180fad9' test_univnewlines [...] test_zlib 222 tests OK. 4 tests failed: test_codecs test_re test_unicode test_unicodedata 29 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_cd test_cl test_curses test_dbm test_email_codecs test_gl test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound 2 skips unexpected on linux2: test_dbm test_locale gmake: *** [test] Error 1 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-08 21:47 Message: Logged In: YES user_id=33168 Confirmed these are still a current problem in SVN. The problem is: --with-wctype-functions. With this option all 4 tests fail on amd64 gentoo linux. ---------------------------------------------------------------------- Comment By: Matejcik (spektrum) Date: 2005-10-25 08:29 Message: Logged In: YES user_id=631694 i can confirm it happens in 2.3.3 and 2.3.5 compiler is gcc 3.3.3 or 4.0.2, happens with and without optimization i used the following configure options: --with-wctype-functions --with-fpectl --enable-shared --enable-unicode when using defaults, the tests pass ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 00:12 Message: Logged In: YES user_id=33168 Are you still having these problems? What compiler are you using? Have you tried building without optimization to see if the problems go away? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=874534&group_id=5470 From noreply at sourceforge.net Mon Jan 9 06:48:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 Jan 2006 21:48:49 -0800 Subject: [ python-Bugs-874534 ] 2.[345]: --with-wctype-functions 4 test failures Message-ID: Bugs item #874534, was opened at 2004-01-10 10:32 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=874534&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Pierre (pierre42) Assigned to: Neal Norwitz (nnorwitz) >Summary: 2.[345]: --with-wctype-functions 4 test failures Initial Comment: # gmake test case $MAKEFLAGS in \ *-s*) LD_LIBRARY_PATH=/tmp/Python-2.3.3:/usr/local/lib:/usr/local/qt/lib:/usr/local/kde/lib:/usr/local/pwlib/lib:/usr/local/openh323/lib CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; \ *) LD_LIBRARY_PATH=/tmp/Python-2.3.3:/usr/local/lib:/usr/local/qt/lib:/usr/local/kde/lib:/usr/local/pwlib/lib:/usr/local/openh323/lib CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py build;; \ esac running build running build_ext building 'dbm' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -fno-strict-aliasing -DHAVE_NDBM_H -I. -I/tmp/Python-2.3.3/./Include -I/usr/local/include -I/tmp/Python-2.3.3/Include -I/tmp/Python-2.3.3 -c /tmp/Python-2.3.3/Modules/dbmmodule.c -o build/temp.linux-i686-2.3/dbmmodule.o gcc -shared build/temp.linux-i686-2.3/dbmmodule.o -L/usr/local/lib -o build/lib.linux-i686-2.3/dbm.so *** WARNING: renaming "dbm" since importing it failed: build/lib.linux-i686-2.3/dbm.so: undefined symbol: dbm_firstkey running build_scripts find ./Lib -name '*.py[co]' -print | xargs rm -f LD_LIBRARY_PATH=/tmp/Python-2.3.3:/usr/local/lib:/usr/local/qt/lib:/usr/local/kde/lib:/usr/local/pwlib/lib:/usr/local/openh323/lib ./python -E -tt ./Lib/test/regrtest.py -l test_grammar [...] test_codecs test test_codecs failed -- Traceback (most recent call last): File "/tmp/Python-2.3.3/Lib/test/test_codecs.py", line 333, in test_nameprep raise test_support.TestFailed("Test 3.%d: %s" % (pos+1, str(e))) TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9' test_codeop [...] test_format /tmp/Python-2.3.3/Lib/test/test_format.py:19: FutureWarning: %u/%o/%x/%X of negative int will return a signed string in Python 2.4 and up result = formatstr % args test_fpformat [...] test_re test test_re produced unexpected output: ********************************************************************** *** lines 2-3 of actual output doesn't appear in expected output after line 1: + === Failed incorrectly ('(?u)\\b.\\b', u'\xc4', 0, 'found', u'\xc4') + === Failed incorrectly ('(?u)\\w', u'\xc4', 0, 'found', u'\xc4') ********************************************************************** test_regex [...] test_unicode test test_unicode failed -- errors occurred in test.test_unicode.UnicodeTest test_unicode_file test_unicode_file skipped -- No Unicode filesystem semantics on this platform. test_unicodedata test test_unicodedata failed -- Traceback (most recent call last): File "/tmp/Python-2.3.3/Lib/test/test_unicodedata.py", line 62, in test_method_checksum self.assertEqual(result, self.expectedchecksum) File "/tmp/Python-2.3.3/Lib/unittest.py", line 302, in failUnlessEqual raise self.failureException, \ AssertionError: 'c269de8355871e3210ae8710b45c2ddb0675b9d5' != 'a37276dc2c158bef6dfd908ad34525c97180fad9' test_univnewlines [...] test_zlib 222 tests OK. 4 tests failed: test_codecs test_re test_unicode test_unicodedata 29 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_cd test_cl test_curses test_dbm test_email_codecs test_gl test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound 2 skips unexpected on linux2: test_dbm test_locale gmake: *** [test] Error 1 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-08 21:47 Message: Logged In: YES user_id=33168 Confirmed these are still a current problem in SVN. The problem is: --with-wctype-functions. With this option all 4 tests fail on amd64 gentoo linux. ---------------------------------------------------------------------- Comment By: Matejcik (spektrum) Date: 2005-10-25 08:29 Message: Logged In: YES user_id=631694 i can confirm it happens in 2.3.3 and 2.3.5 compiler is gcc 3.3.3 or 4.0.2, happens with and without optimization i used the following configure options: --with-wctype-functions --with-fpectl --enable-shared --enable-unicode when using defaults, the tests pass ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 00:12 Message: Logged In: YES user_id=33168 Are you still having these problems? What compiler are you using? Have you tried building without optimization to see if the problems go away? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=874534&group_id=5470 From noreply at sourceforge.net Mon Jan 9 07:29:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 Jan 2006 22:29:32 -0800 Subject: [ python-Bugs-1400115 ] segfault in curses.panel with userptr() Message-ID: Bugs item #1400115, was opened at 2006-01-08 21:37 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1400115&group_id=5470 Please note that this message will contain 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 Submitted By: Tom Quetchenbach (virtualphtn) >Assigned to: Neal Norwitz (nnorwitz) Summary: segfault in curses.panel with userptr() Initial Comment: If a curses.panel object is created with curses.panel.new_panel() and then its userptr() method is called before set_userptr(), the Python interpreter segfaults. Raising an exception or returning None would probably be better. Tested with Python 2.4.2 on Linux 2.6.14 (Debian, Intel Celeron). (Also crashes Python 2.3.5 on the same machine.) Simple testcase is attached. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-08 22:29 Message: Logged In: YES user_id=33168 Thanks for the report! Committed revision 41982. Committed revision 41983. (2.4) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1400115&group_id=5470 From noreply at sourceforge.net Mon Jan 9 08:11:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 Jan 2006 23:11:19 -0800 Subject: [ python-Bugs-1244610 ] 2.4.1 build fails on OpenBSD 3.7 Message-ID: Bugs item #1244610, was opened at 2005-07-25 09:31 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244610&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: L. Peter Deutsch (lpd) >Assigned to: Neal Norwitz (nnorwitz) Summary: 2.4.1 build fails on OpenBSD 3.7 Initial Comment: Python 2.4.1, OpenBSD 3.7, gcc (GCC) 3.3.5 (propolice). I'm including the logs here because they are short. "./configure" printed the following: checking curses.h usability... no checking curses.h presence... yes configure: WARNING: curses.h: present but cannot be compiled configure: WARNING: curses.h: check for missing prerequisite headers? configure: WARNING: curses.h: see the Autoconf documentation configure: WARNING: curses.h: section "Present But Cannot Be Compiled" configure: WARNING: curses.h: proceeding with the preprocessor's result configure: WARNING: curses.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------------ ## configure: WARNING: ## Report this to http://www.python.org/python-bugs ## configure: WARNING: ## ------------------------------------------------ ## checking for curses.h... yes This warning was printed for curses.h, ncurses.h, sys/audioio.h, and sys/lock.h. (The reference to "Autoconf documentation" is useless, because autoconf is not used during the configure process, and is not even installed on the system where I was doing the build.) Then: % make gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o Modules/python.c In file included from /usr/include/sys/select.h:38, from Include/pyport.h:116, from Include/Python.h:55, from Modules/python.c:3: /usr/include/sys/event.h:53: error: syntax error before "u_int" /usr/include/sys/event.h:55: error: syntax error before "u_short" *** Error code 1 Stop in /usr/src/Python-2.4.1. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-08 23:11 Message: Logged In: YES user_id=33168 Committed revision 41984. Committed revision 41985. (2.4) ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-09-24 21:23 Message: Logged In: YES user_id=21627 The issue reported here results from a bug in OpenBSD: ncurses.h and stdlib.h have conflicting definitions of wchar_t. This means the system is simply broken, and should be fixed (or abandoned) eventually. Python has a work-around for the bug, for those versions in which the bug has been confirmed. So far, the bug had not been confirmed for 3.7. Now it is, so we should add 3.7 to the list of systems that still show the bug. Changing it to 3.* would be incorrect - we cannot know whether the bug will be present in 3.8, as that system has not been released yet. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2005-09-24 19:10 Message: Logged In: YES user_id=8861 OK, I've found out what goes wrong. (Debugging a 20,000+-line 'configure' script that omits all useful information from its output and throws away all its intermediate files *even if it detects errors* is not fun.) With the set of configuration options that the script decides is appropriate (too long to include here), compilation of a dummy .c file that #includes fails thusly: In file included from /usr/include/curses.h:14, from t.h:54, from t.c:1: /usr/include/ncurses.h:251: error: conflicting types for `wchar_t' /usr/include/stdlib.h:51: error: previous declaration of `wchar_t' This apparently happens because of line 1483 of the configure script, which reads: OpenBSD/2.* | OpenBSD/3.[0123456]) I can't fathom why OpenBSD 3.7 and later are excluded here, especially since (1) there are other places in the script that include all OpenBSD/3.* versions, and (2) the situation described by the comment just above this line is still true in OpenBSD 3.7. In any case, changing this line to read OpenBSD/2.* | OpenBSD/3.*) causes configure (and a subsequent make) to complete with no errors. So apparently other things are broken in the OpenBSD headerfiles if _XOPEN_SOURCE is defined, not just select(2). I hope someone authorized to do so will make this fix for Python 2.4.. TIA. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-08-28 01:10 Message: Logged In: YES user_id=55188 For curses.h problem, it doesn't harm the build much in fact. It's already reported to FreeBSD bugdb http://www.FreeBSD.org/cgi/query-pr.cgi?pr=84219 and I think it's identical problem on OpenBSD. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-08-09 11:40 Message: Logged In: YES user_id=21627 Can somebody attach a config.log, or reproduce the fragment that deals with the curses.h presence? Does your system require any headers to be included for curses.h to be usable? I.e. if you do #include int main(){} will that program compile, or do you need additional ('prerequisite') headers? ---------------------------------------------------------------------- Comment By: johnnie pittman (jp3g) Date: 2005-08-08 23:34 Message: Logged In: YES user_id=1203137 Hey folks, Also seeing this issue on 3.7. Same setup described above. Loewis, not sure about the first part of your comment. If your asking if those header files exist and are available, yes they are (atleast on my system). ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-08-06 05:43 Message: Logged In: YES user_id=21627 So can you tell us whether there are missing prerequisite headers? One would need to have access to your operating system to resolve this issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244610&group_id=5470 From noreply at sourceforge.net Mon Jan 9 08:13:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 08 Jan 2006 23:13:04 -0800 Subject: [ python-Bugs-1392915 ] build fails on BSD 3.8 Message-ID: Bugs item #1392915, was opened at 2005-12-29 07:32 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1392915&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: George Yoshida (quiver) >Assigned to: Neal Norwitz (nnorwitz) Summary: build fails on BSD 3.8 Initial Comment: There are several reports that python cannot be compiled in recent OpenBSD. The problem seems to be that configure script is not updated in sync with OpenBSD releases. Similar bug report can be found here:: www.python.org/sf/1026986 building on OpenBSD 3.5 Attached patch uses the same hack as this one. I didn't test it by myself, but the reporter said "it did the trick." ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-08 23:13 Message: Logged In: YES user_id=33168 Thanks for the report. It would be good to have the person double check 2.4 and head. Committed revision 41984. Committed revision 41985. (2.4) Also related to bug 1244610. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1392915&group_id=5470 From noreply at sourceforge.net Mon Jan 9 11:04:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jan 2006 02:04:20 -0800 Subject: [ python-Bugs-1400227 ] 'is' does not work on methods Message-ID: Bugs item #1400227, was opened at 2006-01-09 05: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=1400227&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: 'is' does not work on methods Initial Comment: As of Python 2.4.2 (gcc 3.3.6, linux 2.6.13), the 'is' comparison operator does not work on instancemethods or classmethods (though it does work on staticmethods). For example: """ >>> class A(object): ... def foo(self): pass ... >>> id(A.foo) == id(A.foo) True >>> A.foo is A.foo False >>> >>> a = A() >>> id(a.foo) == id(a.foo) True >>> a.foo is a.foo False """ This example is applicable to old-style classes and new-style classes, though things get more complicated in the case of built-in types: """ >>> d = dict() >>> id(d.update) == id(d.update) True >>> d.update is d.update False >>> >>> id(dict.update) == id(dict.update) True >>> dict.update is dict.update True """ However, using the classmethod 'fromkeys': """ >>> d = dict() >>> id(d.fromkeys) == id(d.fromkeys) True >>> d.fromkeys is d.fromkeys False >>> >>> id(dict.fromkeys) == id(dict.fromkeys) True >>> dict.fromkeys is dict.fromkeys False """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1400227&group_id=5470 From noreply at sourceforge.net Mon Jan 9 11:08:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jan 2006 02:08:55 -0800 Subject: [ python-Bugs-1400235 ] 'is' does not work for methods Message-ID: Bugs item #1400235, was opened at 2006-01-09 05:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1400235&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: 'is' does not work for methods Initial Comment: As of Python 2.4.2 (gcc 3.3.6, linux 2.6.13), the 'is' comparison operator does not work for instancemethods or classmethods (though it does work for staticmethods). For example: """ >>> class A(object): ... def foo(self): pass ... >>> id(A.foo) == id(A.foo) True >>> A.foo is A.foo False >>> >>> a = A() >>> id(a.foo) == id(a.foo) True >>> a.foo is a.foo False """ This example is applicable to old-style classes and new-style classes, though things get more complicated in the case of built-in types: """ >>> d = dict() >>> id(d.update) == id(d.update) True >>> d.update is d.update False >>> >>> id(dict.update) == id(dict.update) True >>> dict.update is dict.update True """ However, using the classmethod 'fromkeys': """ >>> d = dict() >>> id(d.fromkeys) == id(d.fromkeys) True >>> d.fromkeys is d.fromkeys False >>> >>> id(dict.fromkeys) == id(dict.fromkeys) True >>> dict.fromkeys is dict.fromkeys False """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1400235&group_id=5470 From noreply at sourceforge.net Mon Jan 9 11:10:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jan 2006 02:10:52 -0800 Subject: [ python-Bugs-1400235 ] 'is' does not work for methods Message-ID: Bugs item #1400235, was opened at 2006-01-09 05:08 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1400235&group_id=5470 Please note that this message 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: Deleted >Resolution: Duplicate Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: 'is' does not work for methods Initial Comment: As of Python 2.4.2 (gcc 3.3.6, linux 2.6.13), the 'is' comparison operator does not work for instancemethods or classmethods (though it does work for staticmethods). For example: """ >>> class A(object): ... def foo(self): pass ... >>> id(A.foo) == id(A.foo) True >>> A.foo is A.foo False >>> >>> a = A() >>> id(a.foo) == id(a.foo) True >>> a.foo is a.foo False """ This example is applicable to old-style classes and new-style classes, though things get more complicated in the case of built-in types: """ >>> d = dict() >>> id(d.update) == id(d.update) True >>> d.update is d.update False >>> >>> id(dict.update) == id(dict.update) True >>> dict.update is dict.update True """ However, using the classmethod 'fromkeys': """ >>> d = dict() >>> id(d.fromkeys) == id(d.fromkeys) True >>> d.fromkeys is d.fromkeys False >>> >>> id(dict.fromkeys) == id(dict.fromkeys) True >>> dict.fromkeys is dict.fromkeys False """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1400235&group_id=5470 From noreply at sourceforge.net Mon Jan 9 11:31:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jan 2006 02:31:43 -0800 Subject: [ python-Feature Requests-1400252 ] invoking an external Java program from Python script Message-ID: Feature Requests item #1400252, was opened at 2006-01-09 10: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=1400252&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Laure (elsa_petit) Assigned to: Nobody/Anonymous (nobody) Summary: invoking an external Java program from Python script Initial Comment: I would like to invoke a .jar Java file from a Python script (python24). I am new to Java and don't want to use JPype or Jython. -What is the code I should use as command line? -Where should I place my .jar file, should it be placed in the Python directory? - I am in windows but would like to know what are the differences according to each OS used? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1400252&group_id=5470 From noreply at sourceforge.net Mon Jan 9 12:39:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jan 2006 03:39:19 -0800 Subject: [ python-Bugs-1400227 ] 'is' does not work on methods Message-ID: Bugs item #1400227, was opened at 2006-01-09 10:04 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1400227&group_id=5470 Please note that this message 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 Submitted By: Collin Winter (collinwinter) >Assigned to: Michael Hudson (mwh) Summary: 'is' does not work on methods Initial Comment: As of Python 2.4.2 (gcc 3.3.6, linux 2.6.13), the 'is' comparison operator does not work on instancemethods or classmethods (though it does work on staticmethods). For example: """ >>> class A(object): ... def foo(self): pass ... >>> id(A.foo) == id(A.foo) True >>> A.foo is A.foo False >>> >>> a = A() >>> id(a.foo) == id(a.foo) True >>> a.foo is a.foo False """ This example is applicable to old-style classes and new-style classes, though things get more complicated in the case of built-in types: """ >>> d = dict() >>> id(d.update) == id(d.update) True >>> d.update is d.update False >>> >>> id(dict.update) == id(dict.update) True >>> dict.update is dict.update True """ However, using the classmethod 'fromkeys': """ >>> d = dict() >>> id(d.fromkeys) == id(d.fromkeys) True >>> d.fromkeys is d.fromkeys False >>> >>> id(dict.fromkeys) == id(dict.fromkeys) True >>> dict.fromkeys is dict.fromkeys False """ ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2006-01-09 11:39 Message: Logged In: YES user_id=6656 'is' is working just fine here. When you execute 'a.foo' a fresh bound method object is made, so two executions lead to two different objects. The thing that probably confused you was this: >>> id(a.foo) == id(a.foo) True What happens here is that you execute 'a.foo' which returns a bound method object, you call id() on it, the bound method gets deleted, you execute 'a.foo' again and call id() on the new bound method object -- which happens to be allocated at the same place in memory as the previous one, so the id()s are the same. Closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1400227&group_id=5470 From noreply at sourceforge.net Mon Jan 9 12:54:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jan 2006 03:54:43 -0800 Subject: [ python-Bugs-1377858 ] segfaults when using __del__ and weakrefs Message-ID: Bugs item #1377858, was opened at 2005-12-10 21:20 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377858&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Carl Friedrich Bolz (cfbolz) Assigned to: Nobody/Anonymous (nobody) Summary: segfaults when using __del__ and weakrefs Initial Comment: You can segfault Python by creating a weakref to an object in its __del__ method, storing it somewhere and then trying to dereference the weakref afterwards. the attached file shows the described behaviour. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2006-01-09 11:54 Message: Logged In: YES user_id=6656 Hmm, I was kind of hoping this report would get more attention. The problem is obvious if you read typeobject.c around line 660: the weakref list is cleared before __del__ is called, so any weakrefs added during the execution of __del__ are never informed of the object's death. One fix for this would be to clear the weakref list _after_ calling __del__ but that led to other mayhem in ways I haven't boethered to understand (see SF bug #742911). I guess we could just clear out any weakrefs created in __del__ without calling their callbacks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377858&group_id=5470 From noreply at sourceforge.net Mon Jan 9 12:58:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jan 2006 03:58:28 -0800 Subject: [ python-Bugs-1377858 ] segfaults when using __del__ and weakrefs Message-ID: Bugs item #1377858, was opened at 2005-12-10 21:20 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377858&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Carl Friedrich Bolz (cfbolz) Assigned to: Nobody/Anonymous (nobody) Summary: segfaults when using __del__ and weakrefs Initial Comment: You can segfault Python by creating a weakref to an object in its __del__ method, storing it somewhere and then trying to dereference the weakref afterwards. the attached file shows the described behaviour. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2006-01-09 11:58 Message: Logged In: YES user_id=6656 Hmm, maybe the referenced mayhem is more to do with clearing __dict__ than calling __del__. What breaks if we do things in this order: 1. call __del__ 2. clear weakrefs 3. clear __dict__ ? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-01-09 11:54 Message: Logged In: YES user_id=6656 Hmm, I was kind of hoping this report would get more attention. The problem is obvious if you read typeobject.c around line 660: the weakref list is cleared before __del__ is called, so any weakrefs added during the execution of __del__ are never informed of the object's death. One fix for this would be to clear the weakref list _after_ calling __del__ but that led to other mayhem in ways I haven't boethered to understand (see SF bug #742911). I guess we could just clear out any weakrefs created in __del__ without calling their callbacks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377858&group_id=5470 From noreply at sourceforge.net Mon Jan 9 13:11:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jan 2006 04:11:20 -0800 Subject: [ python-Bugs-874534 ] 2.[345]: --with-wctype-functions 4 test failures Message-ID: Bugs item #874534, was opened at 2004-01-10 19:32 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=874534&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Pierre (pierre42) Assigned to: Neal Norwitz (nnorwitz) Summary: 2.[345]: --with-wctype-functions 4 test failures Initial Comment: # gmake test case $MAKEFLAGS in \ *-s*) LD_LIBRARY_PATH=/tmp/Python-2.3.3:/usr/local/lib:/usr/local/qt/lib:/usr/local/kde/lib:/usr/local/pwlib/lib:/usr/local/openh323/lib CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; \ *) LD_LIBRARY_PATH=/tmp/Python-2.3.3:/usr/local/lib:/usr/local/qt/lib:/usr/local/kde/lib:/usr/local/pwlib/lib:/usr/local/openh323/lib CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py build;; \ esac running build running build_ext building 'dbm' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -fno-strict-aliasing -DHAVE_NDBM_H -I. -I/tmp/Python-2.3.3/./Include -I/usr/local/include -I/tmp/Python-2.3.3/Include -I/tmp/Python-2.3.3 -c /tmp/Python-2.3.3/Modules/dbmmodule.c -o build/temp.linux-i686-2.3/dbmmodule.o gcc -shared build/temp.linux-i686-2.3/dbmmodule.o -L/usr/local/lib -o build/lib.linux-i686-2.3/dbm.so *** WARNING: renaming "dbm" since importing it failed: build/lib.linux-i686-2.3/dbm.so: undefined symbol: dbm_firstkey running build_scripts find ./Lib -name '*.py[co]' -print | xargs rm -f LD_LIBRARY_PATH=/tmp/Python-2.3.3:/usr/local/lib:/usr/local/qt/lib:/usr/local/kde/lib:/usr/local/pwlib/lib:/usr/local/openh323/lib ./python -E -tt ./Lib/test/regrtest.py -l test_grammar [...] test_codecs test test_codecs failed -- Traceback (most recent call last): File "/tmp/Python-2.3.3/Lib/test/test_codecs.py", line 333, in test_nameprep raise test_support.TestFailed("Test 3.%d: %s" % (pos+1, str(e))) TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9' test_codeop [...] test_format /tmp/Python-2.3.3/Lib/test/test_format.py:19: FutureWarning: %u/%o/%x/%X of negative int will return a signed string in Python 2.4 and up result = formatstr % args test_fpformat [...] test_re test test_re produced unexpected output: ********************************************************************** *** lines 2-3 of actual output doesn't appear in expected output after line 1: + === Failed incorrectly ('(?u)\\b.\\b', u'\xc4', 0, 'found', u'\xc4') + === Failed incorrectly ('(?u)\\w', u'\xc4', 0, 'found', u'\xc4') ********************************************************************** test_regex [...] test_unicode test test_unicode failed -- errors occurred in test.test_unicode.UnicodeTest test_unicode_file test_unicode_file skipped -- No Unicode filesystem semantics on this platform. test_unicodedata test test_unicodedata failed -- Traceback (most recent call last): File "/tmp/Python-2.3.3/Lib/test/test_unicodedata.py", line 62, in test_method_checksum self.assertEqual(result, self.expectedchecksum) File "/tmp/Python-2.3.3/Lib/unittest.py", line 302, in failUnlessEqual raise self.failureException, \ AssertionError: 'c269de8355871e3210ae8710b45c2ddb0675b9d5' != 'a37276dc2c158bef6dfd908ad34525c97180fad9' test_univnewlines [...] test_zlib 222 tests OK. 4 tests failed: test_codecs test_re test_unicode test_unicodedata 29 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_cd test_cl test_curses test_dbm test_email_codecs test_gl test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound 2 skips unexpected on linux2: test_dbm test_locale gmake: *** [test] Error 1 ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-01-09 13:11 Message: Logged In: YES user_id=38388 This option should/will go away in Python 2.5, so I don't think there's a need to bother with trying to fix problems related to it. The reason for the removal is that the option causes semantical problems and makes Unicode work in non-standard ways on platforms that use locale-aware extensions to the wc-type functions. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-09 06:47 Message: Logged In: YES user_id=33168 Confirmed these are still a current problem in SVN. The problem is: --with-wctype-functions. With this option all 4 tests fail on amd64 gentoo linux. ---------------------------------------------------------------------- Comment By: Matejcik (spektrum) Date: 2005-10-25 17:29 Message: Logged In: YES user_id=631694 i can confirm it happens in 2.3.3 and 2.3.5 compiler is gcc 3.3.3 or 4.0.2, happens with and without optimization i used the following configure options: --with-wctype-functions --with-fpectl --enable-shared --enable-unicode when using defaults, the tests pass ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 09:12 Message: Logged In: YES user_id=33168 Are you still having these problems? What compiler are you using? Have you tried building without optimization to see if the problems go away? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=874534&group_id=5470 From noreply at sourceforge.net Mon Jan 9 18:52:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jan 2006 09:52:26 -0800 Subject: [ python-Feature Requests-1353344 ] python.desktop Message-ID: Feature Requests item #1353344, was opened at 2005-11-10 19:22 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1353344&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: python.desktop Initial Comment: I would very much like a /usr/share/applications/python.desktop file so that Python can be started from the Program-menu in Linux, just like you can from the Start-menu in Windows. I think it would be very neat and good for beginners. ---------------------------------------------------------------------- >Comment By: Bj?rn Lindqvist (sonderblade) Date: 2006-01-09 18:52 Message: Logged In: YES user_id=51702 In trunk there are PC/py.ico, PC/pyc.ico, PC/pycon.ico. I guess they would all work as icons, but I choose pycon.ico because that is the icon used on windows. I also wonder if the desktop file can be applied soon? It seems pretty trivial and uncontroversial to me. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-11-17 14:43 Message: Logged In: YES user_id=1188172 I added German translation. Regarding the icon: I do not like that very much. Isn't there another Python icon available in the standard sizes? ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2005-11-16 19:16 Message: Logged In: YES user_id=51702 I have attached a .desktop file and an icon. python.desktop goes into /usr/share/applications and pycon.png into /usr/share/pixmaps. It's only translated to Swedish because I don't know other languages to well. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-11-13 23:41 Message: Logged In: YES user_id=21627 Would you be willing to provide one? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1353344&group_id=5470 From noreply at sourceforge.net Mon Jan 9 19:58:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jan 2006 10:58:26 -0800 Subject: [ python-Feature Requests-1400252 ] invoking an external Java program from Python script Message-ID: Feature Requests item #1400252, was opened at 2006-01-09 11:31 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1400252&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Laure (elsa_petit) Assigned to: Nobody/Anonymous (nobody) Summary: invoking an external Java program from Python script Initial Comment: I would like to invoke a .jar Java file from a Python script (python24). I am new to Java and don't want to use JPype or Jython. -What is the code I should use as command line? -Where should I place my .jar file, should it be placed in the Python directory? - I am in windows but would like to know what are the differences according to each OS used? ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-09 19:58 Message: Logged In: YES user_id=1188172 Please ask such questions in the comp.lang.python newsgroup. This tracker is for feature requests. What you're asking is already possible with today's Python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1400252&group_id=5470 From noreply at sourceforge.net Tue Jan 10 00:07:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jan 2006 15:07:45 -0800 Subject: [ python-Bugs-1281383 ] array.arrays are not unpickleable Message-ID: Bugs item #1281383, was opened at 2005-09-03 13:16 Message generated for change (Comment added) made by mbrighton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281383&group_id=5470 Please note that this 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: Invalid Priority: 6 Submitted By: Georg Brandl (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: array.arrays are not unpickleable Initial Comment: Credits to John Machin for discovering this. """ Googling for "pickle array" in comp.lang.python yields old messages that show a PickleError -- plus one message where Alex Martelli writes "I am but an egg" :O) Looks like arrays are NOW (2.4.1) pickleable but not unpickleable -- see below. I appreciate that arrays are inherently not pickleable because of the type code. However: (1) Anyone know why/when the world changed? (2) If we had alternative constructors like array.iarray(contents) in parallel to array.array('i', contents), those objects could be pickled/unpickled -- yes/no? Cheers, John ==================== Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import pickle, array >>> class Foo(object): ... pass ... >>> foo = Foo() >>> foo.ia = array.array('i', [3,2,1]) >>> foo.ia array('i', [3, 2, 1]) >>> s = pickle.dumps(foo, -1) >>> bar = pickle.loads(s) Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\lib\pickle.py", line 1394, in loads return Unpickler(file).load() File "C:\Python24\lib\pickle.py", line 872, in load dispatch[key](self) File "C:\Python24\lib\pickle.py", line 1097, in load_newobj obj = cls.__new__(cls, *args) TypeError: array() takes at least 1 argument (0 given) =========== """ ---------------------------------------------------------------------- Comment By: Mark C. Brighton (mbrighton) Date: 2006-01-09 15:07 Message: Logged In: YES user_id=1423362 >From the comments, it appears that the developers didn't notice that the example used protocol '-1' (highest protocol, which is 2 in Py2.4). Using protocol 0 (default) or 1 will give the TypeError (which is appropriate). Using protocol 2, pickle.dumps() will accept a pickle object without an exception, but it doesn't seem to pickle it properly (see log below). Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import array >>> import pickle >>> a=array.array('B') >>> s= pickle.dumps(a,2);s '\x80\x02carray\narray\nq\x00)\x81q\x01.' >>> pickle.load(s) Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\lib\pickle.py", line 1390, in load return Unpickler(file).load() File "C:\Python24\lib\pickle.py", line 855, in __init__ self.readline = file.readline AttributeError: 'str' object has no attribute 'readline' >>> >>> a=array.array('B', [1,2,3,4,5]) >>> a array('B', [1, 2, 3, 4, 5]) >>> s2=pickle.dumps(a,2);s2 '\x80\x02carray\narray\nq\x00)\x81q\x01.' ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-08 12:39 Message: Logged In: YES user_id=593130 http://python.org/sf/1281556 appears to be a duplicate. You wish to close it too? (I won't, don't know enough here.) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-07 23:36 Message: Logged In: YES user_id=80475 I think you're misunderstanding. Direct pickling of arrays does raise a TypeError. It would be nice if it also did as an object attribute; however, I'm not bothered by it enough to spend development time tracing down the issue and then altering otherwise correct Py2.4 code just to generate a prettier message. It is enough for me that the docs do not promise pickling, that a message is generated by a direct attempt to pickle, that the OP's buggy code eventually errors out, and that everything works fine in Py2.5. I have no objections to someone finding a way to generate a better error message but think the time would better be spent elsewhere. >>> from array import array >>> from pickle import dumps, loads >>> ia = array('i', [3,2,1]) >>> ib = loads(dumps(ia)) Traceback (most recent call last): . . . TypeError: can't pickle array objects ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-09-07 23:04 Message: Logged In: YES user_id=341410 Raymond, they seem to be asking for Pickle and cPickle to raise an exception when someone attempts to pickle arrays in a future Python 2.4.2 release. I don't think that is a new feature. As for 2.5, real pickle support seems reasonable. ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2005-09-04 03:41 Message: Logged In: YES user_id=480138 Please fix the bug in Python 2.4: if array objects are not pickleable in 2.4, then pickle and cPickle should raise a PickleError [like they used to in earlier versions] -- instead of guessing wrongly and misleading callers into thinking that the objects can be pickled. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-03 16:20 Message: Logged In: YES user_id=80475 In Py2.4, array's became copyable, weak-referencable, and got support for iterator arguments. Real pickle support wasn't added until Py2.5. The above code fragment is a by-product of pickle making an incorrect guess at how to pickle arrays before real pickel support was added. It is not really a bug; rather, it begs for a feature that wasn't added to later. If it weren't a new feature, I would just backport the 2.5 pickle support. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281383&group_id=5470 From noreply at sourceforge.net Tue Jan 10 00:27:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jan 2006 15:27:45 -0800 Subject: [ python-Bugs-1400822 ] Extended version of _curses over{lay, write} does not work. Message-ID: Bugs item #1400822, was opened at 2006-01-09 18: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=1400822&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: J. Sipprell (jsipprell) Assigned to: Nobody/Anonymous (nobody) Summary: Extended version of _curses over{lay,write} does not work. Initial Comment: 2.3/2.4 library docs indicate the following for the curses window object methods 'overlay' and 'overwrite': "To get fine-grained control over the copied region, the second form of overwrite() can be used. sminrow and smincol are the upper-left coordinates of the source window, the other variables mark a rectangle in the destination window." [syntax: overlay(destwin[, sminrow, smincol, dminrow, dmincol, dmaxrow, dmaxcol])] However, attempting to use the 7 arg form of either overlay or overwrite results in a TypeError being raised. Inspection of the PyCursesWindow_Overlay and PyCursesWindow_Overwrite functions from _cursesmodule.c reveals an incorrect format for the 7-arg specific call to PyArg_ParseTuple, such that a single argument tuple is expected which would contain the method arguments. Obviously, this is incompatible with the general argument length conditional used to decide which PyArg_ParseTuple will be used. The bug has only been verified on python 2.3.5, not 2.4, however a cursory examination of 2.4 code reveals no differences in these functions. The attached patch alters the PyArg_ParseTuple format string for both functions such that seven arguments are parsed as expected and the related copywin() code is thus executed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1400822&group_id=5470 From noreply at sourceforge.net Tue Jan 10 02:03:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jan 2006 17:03:06 -0800 Subject: [ python-Bugs-1281383 ] array.arrays are not unpickleable Message-ID: Bugs item #1281383, was opened at 2005-09-03 13:16 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281383&group_id=5470 Please note that this 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: Invalid Priority: 6 Submitted By: Georg Brandl (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: array.arrays are not unpickleable Initial Comment: Credits to John Machin for discovering this. """ Googling for "pickle array" in comp.lang.python yields old messages that show a PickleError -- plus one message where Alex Martelli writes "I am but an egg" :O) Looks like arrays are NOW (2.4.1) pickleable but not unpickleable -- see below. I appreciate that arrays are inherently not pickleable because of the type code. However: (1) Anyone know why/when the world changed? (2) If we had alternative constructors like array.iarray(contents) in parallel to array.array('i', contents), those objects could be pickled/unpickled -- yes/no? Cheers, John ==================== Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import pickle, array >>> class Foo(object): ... pass ... >>> foo = Foo() >>> foo.ia = array.array('i', [3,2,1]) >>> foo.ia array('i', [3, 2, 1]) >>> s = pickle.dumps(foo, -1) >>> bar = pickle.loads(s) Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\lib\pickle.py", line 1394, in loads return Unpickler(file).load() File "C:\Python24\lib\pickle.py", line 872, in load dispatch[key](self) File "C:\Python24\lib\pickle.py", line 1097, in load_newobj obj = cls.__new__(cls, *args) TypeError: array() takes at least 1 argument (0 given) =========== """ ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-01-09 17:03 Message: Logged In: YES user_id=341410 mbrighton: You get a string from pickle.dumps(), and to load strings, you should use pickle.loads() . The AttributeError you are recieving is the result of using pickle.load() with a string, not a file object, as required, and as described by the documentation. ---------------------------------------------------------------------- Comment By: Mark C. Brighton (mbrighton) Date: 2006-01-09 15:07 Message: Logged In: YES user_id=1423362 >From the comments, it appears that the developers didn't notice that the example used protocol '-1' (highest protocol, which is 2 in Py2.4). Using protocol 0 (default) or 1 will give the TypeError (which is appropriate). Using protocol 2, pickle.dumps() will accept a pickle object without an exception, but it doesn't seem to pickle it properly (see log below). Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import array >>> import pickle >>> a=array.array('B') >>> s= pickle.dumps(a,2);s '\x80\x02carray\narray\nq\x00)\x81q\x01.' >>> pickle.load(s) Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\lib\pickle.py", line 1390, in load return Unpickler(file).load() File "C:\Python24\lib\pickle.py", line 855, in __init__ self.readline = file.readline AttributeError: 'str' object has no attribute 'readline' >>> >>> a=array.array('B', [1,2,3,4,5]) >>> a array('B', [1, 2, 3, 4, 5]) >>> s2=pickle.dumps(a,2);s2 '\x80\x02carray\narray\nq\x00)\x81q\x01.' ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-08 12:39 Message: Logged In: YES user_id=593130 http://python.org/sf/1281556 appears to be a duplicate. You wish to close it too? (I won't, don't know enough here.) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-07 23:36 Message: Logged In: YES user_id=80475 I think you're misunderstanding. Direct pickling of arrays does raise a TypeError. It would be nice if it also did as an object attribute; however, I'm not bothered by it enough to spend development time tracing down the issue and then altering otherwise correct Py2.4 code just to generate a prettier message. It is enough for me that the docs do not promise pickling, that a message is generated by a direct attempt to pickle, that the OP's buggy code eventually errors out, and that everything works fine in Py2.5. I have no objections to someone finding a way to generate a better error message but think the time would better be spent elsewhere. >>> from array import array >>> from pickle import dumps, loads >>> ia = array('i', [3,2,1]) >>> ib = loads(dumps(ia)) Traceback (most recent call last): . . . TypeError: can't pickle array objects ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-09-07 23:04 Message: Logged In: YES user_id=341410 Raymond, they seem to be asking for Pickle and cPickle to raise an exception when someone attempts to pickle arrays in a future Python 2.4.2 release. I don't think that is a new feature. As for 2.5, real pickle support seems reasonable. ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2005-09-04 03:41 Message: Logged In: YES user_id=480138 Please fix the bug in Python 2.4: if array objects are not pickleable in 2.4, then pickle and cPickle should raise a PickleError [like they used to in earlier versions] -- instead of guessing wrongly and misleading callers into thinking that the objects can be pickled. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-03 16:20 Message: Logged In: YES user_id=80475 In Py2.4, array's became copyable, weak-referencable, and got support for iterator arguments. Real pickle support wasn't added until Py2.5. The above code fragment is a by-product of pickle making an incorrect guess at how to pickle arrays before real pickel support was added. It is not really a bug; rather, it begs for a feature that wasn't added to later. If it weren't a new feature, I would just backport the 2.5 pickle support. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281383&group_id=5470 From noreply at sourceforge.net Tue Jan 10 02:11:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jan 2006 17:11:50 -0800 Subject: [ python-Bugs-1281383 ] array.arrays are not unpickleable Message-ID: Bugs item #1281383, was opened at 2005-09-03 13:16 Message generated for change (Comment added) made by mbrighton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281383&group_id=5470 Please note that this 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: Invalid Priority: 6 Submitted By: Georg Brandl (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: array.arrays are not unpickleable Initial Comment: Credits to John Machin for discovering this. """ Googling for "pickle array" in comp.lang.python yields old messages that show a PickleError -- plus one message where Alex Martelli writes "I am but an egg" :O) Looks like arrays are NOW (2.4.1) pickleable but not unpickleable -- see below. I appreciate that arrays are inherently not pickleable because of the type code. However: (1) Anyone know why/when the world changed? (2) If we had alternative constructors like array.iarray(contents) in parallel to array.array('i', contents), those objects could be pickled/unpickled -- yes/no? Cheers, John ==================== Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import pickle, array >>> class Foo(object): ... pass ... >>> foo = Foo() >>> foo.ia = array.array('i', [3,2,1]) >>> foo.ia array('i', [3, 2, 1]) >>> s = pickle.dumps(foo, -1) >>> bar = pickle.loads(s) Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\lib\pickle.py", line 1394, in loads return Unpickler(file).load() File "C:\Python24\lib\pickle.py", line 872, in load dispatch[key](self) File "C:\Python24\lib\pickle.py", line 1097, in load_newobj obj = cls.__new__(cls, *args) TypeError: array() takes at least 1 argument (0 given) =========== """ ---------------------------------------------------------------------- Comment By: Mark C. Brighton (mbrighton) Date: 2006-01-09 17:11 Message: Logged In: YES user_id=1423362 Thatks for catching that. Unfortunatly, that's just a function of me editing the example. I ment to edit that out and instead took out the exception I was trying to show. Here's what I ment to demonstrate: >>> import array >>> import pickle >>> a=array.array('B') >>> s= pickle.dumps(a,2);s '\x80\x02carray\narray\nq\x00)\x81q\x01.' >>> pickle.loads(s) Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\lib\pickle.py", line 1394, in loads return Unpickler(file).load() File "C:\Python24\lib\pickle.py", line 872, in load dispatch[key](self) File "C:\Python24\lib\pickle.py", line 1097, in load_newobj obj = cls.__new__(cls, *args) TypeError: array() takes at least 1 argument (0 given) The part of the problem appears to be with dumps(), as the same string is returned independent of the array provided: >>> pickle.dumps(array.array('B'),2) '\x80\x02carray\narray\nq\x00)\x81q\x01.' >>> pickle.dumps(array.array('B', [1,2,3,4,5]),2) '\x80\x02carray\narray\nq\x00)\x81q\x01.' >>> pickle.dumps(array.array('B', [230,]*100),2) '\x80\x02carray\narray\nq\x00)\x81q\x01.' >>> pickle.dumps(array.array('H', [1,2,3,4,5]),2) '\x80\x02carray\narray\nq\x00)\x81q\x01.' ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-01-09 17:03 Message: Logged In: YES user_id=341410 mbrighton: You get a string from pickle.dumps(), and to load strings, you should use pickle.loads() . The AttributeError you are recieving is the result of using pickle.load() with a string, not a file object, as required, and as described by the documentation. ---------------------------------------------------------------------- Comment By: Mark C. Brighton (mbrighton) Date: 2006-01-09 15:07 Message: Logged In: YES user_id=1423362 >From the comments, it appears that the developers didn't notice that the example used protocol '-1' (highest protocol, which is 2 in Py2.4). Using protocol 0 (default) or 1 will give the TypeError (which is appropriate). Using protocol 2, pickle.dumps() will accept a pickle object without an exception, but it doesn't seem to pickle it properly (see log below). Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import array >>> import pickle >>> a=array.array('B') >>> s= pickle.dumps(a,2);s '\x80\x02carray\narray\nq\x00)\x81q\x01.' >>> pickle.load(s) Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\lib\pickle.py", line 1390, in load return Unpickler(file).load() File "C:\Python24\lib\pickle.py", line 855, in __init__ self.readline = file.readline AttributeError: 'str' object has no attribute 'readline' >>> >>> a=array.array('B', [1,2,3,4,5]) >>> a array('B', [1, 2, 3, 4, 5]) >>> s2=pickle.dumps(a,2);s2 '\x80\x02carray\narray\nq\x00)\x81q\x01.' ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-08 12:39 Message: Logged In: YES user_id=593130 http://python.org/sf/1281556 appears to be a duplicate. You wish to close it too? (I won't, don't know enough here.) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-07 23:36 Message: Logged In: YES user_id=80475 I think you're misunderstanding. Direct pickling of arrays does raise a TypeError. It would be nice if it also did as an object attribute; however, I'm not bothered by it enough to spend development time tracing down the issue and then altering otherwise correct Py2.4 code just to generate a prettier message. It is enough for me that the docs do not promise pickling, that a message is generated by a direct attempt to pickle, that the OP's buggy code eventually errors out, and that everything works fine in Py2.5. I have no objections to someone finding a way to generate a better error message but think the time would better be spent elsewhere. >>> from array import array >>> from pickle import dumps, loads >>> ia = array('i', [3,2,1]) >>> ib = loads(dumps(ia)) Traceback (most recent call last): . . . TypeError: can't pickle array objects ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-09-07 23:04 Message: Logged In: YES user_id=341410 Raymond, they seem to be asking for Pickle and cPickle to raise an exception when someone attempts to pickle arrays in a future Python 2.4.2 release. I don't think that is a new feature. As for 2.5, real pickle support seems reasonable. ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2005-09-04 03:41 Message: Logged In: YES user_id=480138 Please fix the bug in Python 2.4: if array objects are not pickleable in 2.4, then pickle and cPickle should raise a PickleError [like they used to in earlier versions] -- instead of guessing wrongly and misleading callers into thinking that the objects can be pickled. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-03 16:20 Message: Logged In: YES user_id=80475 In Py2.4, array's became copyable, weak-referencable, and got support for iterator arguments. Real pickle support wasn't added until Py2.5. The above code fragment is a by-product of pickle making an incorrect guess at how to pickle arrays before real pickel support was added. It is not really a bug; rather, it begs for a feature that wasn't added to later. If it weren't a new feature, I would just backport the 2.5 pickle support. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281383&group_id=5470 From noreply at sourceforge.net Tue Jan 10 08:08:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jan 2006 23:08:17 -0800 Subject: [ python-Bugs-1400822 ] Extended version of _curses over{lay, write} does not work. Message-ID: Bugs item #1400822, was opened at 2006-01-09 15:27 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1400822&group_id=5470 Please note that this 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.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: J. Sipprell (jsipprell) >Assigned to: Neal Norwitz (nnorwitz) Summary: Extended version of _curses over{lay,write} does not work. Initial Comment: 2.3/2.4 library docs indicate the following for the curses window object methods 'overlay' and 'overwrite': "To get fine-grained control over the copied region, the second form of overwrite() can be used. sminrow and smincol are the upper-left coordinates of the source window, the other variables mark a rectangle in the destination window." [syntax: overlay(destwin[, sminrow, smincol, dminrow, dmincol, dmaxrow, dmaxcol])] However, attempting to use the 7 arg form of either overlay or overwrite results in a TypeError being raised. Inspection of the PyCursesWindow_Overlay and PyCursesWindow_Overwrite functions from _cursesmodule.c reveals an incorrect format for the 7-arg specific call to PyArg_ParseTuple, such that a single argument tuple is expected which would contain the method arguments. Obviously, this is incompatible with the general argument length conditional used to decide which PyArg_ParseTuple will be used. The bug has only been verified on python 2.3.5, not 2.4, however a cursory examination of 2.4 code reveals no differences in these functions. The attached patch alters the PyArg_ParseTuple format string for both functions such that seven arguments are parsed as expected and the related copywin() code is thus executed. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-09 23:08 Message: Logged In: YES user_id=33168 It was still a problem. Also UngetMouse(). All are fixed. Committed revision 41998. Committed revision 41999. (2.4) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1400822&group_id=5470 From noreply at sourceforge.net Tue Jan 10 08:20:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 09 Jan 2006 23:20:00 -0800 Subject: [ python-Bugs-1196154 ] Error: ... ossaudiodev.c, line 48: Missing type specifier Message-ID: Bugs item #1196154, was opened at 2005-05-05 12:53 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196154&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None >Priority: 5 Submitted By: Will L G (diskman) >Assigned to: Neal Norwitz (nnorwitz) Summary: Error: ... ossaudiodev.c, line 48: Missing type specifier Initial Comment: RedHat Linux 7.2 [alpha] Kernel 2.6.11.6 Compaq C 6.5.2 Binutils 2.15 Make 2.8 Was receiving the error below and then a few little changes to make the configure script think I was using gcc while still using ccc... [root at jericho Python-2.4.1]# make case $MAKEFLAGS in \ *-s*) LD_LIBRARY_PATH=/usr2/www/linux- related/programming/python/Python- 2.4.1:/usr/X11R6/lib:/usr/lib:/usr/local/lib CC='ccache ccc - pthread' LDSHARED='ccache ccc -pthread -shared' OPT='- DNDEBUG -O' ./python -E ./setup.py -q build;; \ *) LD_LIBRARY_PATH=/usr2/www/linux- related/programming/python/Python- 2.4.1:/usr/X11R6/lib:/usr/lib:/usr/local/lib CC='ccache ccc - pthread' LDSHARED='ccache ccc -pthread -shared' OPT='- DNDEBUG -O' ./python -E ./setup.py build;; \ esac Could not find platform independent libraries Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] 'import site' failed; use -v for traceback Traceback (most recent call last): File "./setup.py", line 6, in ? import sys, os, getopt, imp, re ImportError: No module named os make: *** [sharedmods] Error 1 [root at jericho Python-2.4.1]# Here is a copy of the little script I used to set the env to use ccc while configuring python to compile using gcc and thus build the appropriate extensions: ./configure \ --prefix=/usr \ --sysconfdir=/etc \ --build=alphapca56-alpha-linux-gnu \ --without-gcc \ --enable-shared \ --with-dec-threads \ --with-cxx="ccache cxx" \ --with-cc="ccache ccc" \ --without-threads make CC="ccache ccc" CXX="ccache cxx" \ CFLAGS="-O5 -fast -mtune=ev56 -w -pipe - lpthread -threads" \ CXXFLAGS="-O5 -fast -mtune=ev56 -w -pipe - lpthread -threads" EVERYTHING compiled fine but for one little thing, two extensions didn't compile: building 'ossaudiodev' extension ccache ccc -DNDEBUG -O -fPIC -OPT:Olimit=0 -I. - I/usr2/www/pub/alpha-RH7/programming/python/Python- 2.4.1/./Include -I/usr/local/include -I/usr2/www/pub/alpha- RH7/programming/python/Python-2.4.1/Include - I/usr2/www/pub/alpha-RH7/programming/python/Python- 2.4.1 -c /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/Modules/ossaudiodev.c -o build/temp.linux-alpha- 2.4/ossaudiodev.o cc: Error: /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/Modules/ossaudiodev.c, line 48: Missing type specifier or type qualifier. (missingtype) PyObject_HEAD; -----------------^ cc: Error: /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/Modules/ossaudiodev.c, line 57: Missing type specifier or type qualifier. (missingtype) PyObject_HEAD; -----------------^ ccache ccc -DNDEBUG -O -fPIC -OPT:Olimit=0 -I. - I/usr2/www/pub/alpha-RH7/programming/python/Python- 2.4.1/./Include -I/usr/local/include -I/usr2/www/pub/alpha- RH7/programming/python/Python-2.4.1/Include - I/usr2/www/pub/alpha-RH7/programming/python/Python- 2.4.1 -c /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/Modules/ossaudiodev.c -o build/temp.linux-alpha- 2.4/ossaudiodev.o cc: Error: /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/Modules/ossaudiodev.c, line 48: Missing type specifier or type qualifier. (missingtype) PyObject_HEAD; -----------------^ cc: Error: /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/Modules/ossaudiodev.c, line 57: Missing type specifier or type qualifier. (missingtype) PyObject_HEAD; -----------------^ cc: Info: /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/./Include/objimpl.h, line 255: In this declaration, type long double has the same representation as type double on this platform. (longdoublenyi) long double dummy; /* force worst-case alignment */ ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-09 23:20 Message: Logged In: YES user_id=33168 The problem could be an extra ; on the PyObject_HEAD line. (There shouldn't be any.) The semi-colon has been removed in SVN. Can you verify that is the problem? The fix wasn't ported to 2.4, but that's easy enough if removing the semi-colon fixes the problem. If you want faster resolution, perhaps you can volunteer to help out. ---------------------------------------------------------------------- Comment By: Will L G (diskman) Date: 2005-08-04 09:13 Message: Logged In: YES user_id=312992 I thought Python-2.4.1 was in 'bug fix' mode? Well this fucker is as OLD as dirt... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196154&group_id=5470 From noreply at sourceforge.net Tue Jan 10 15:34:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 06:34:42 -0800 Subject: [ python-Bugs-1401642 ] Win32COM policy.py unicode exceptions Message-ID: Bugs item #1401642, was opened at 2006-01-10 14: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=1401642&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: rbell01824 (rbell01824) Assigned to: Nobody/Anonymous (nobody) Summary: Win32COM policy.py unicode exceptions Initial Comment: Getting exceptions when catching events while interacting with InternetExplorer.Application. Class connects to IE via self.ie = DispatchWithEvents("InternetExplorer.Application", InternetExplorerEvents) Subsequent events on some (not all) URLs cause exceptions as follows: pythoncom error: Python error invoking COM method. Traceback (most recent call last): File "C:\Python24\Lib\site-packages\win32com\server\policy.py", line 285, in _Invoke_ return self._invoke_(dispid, lcid, wFlags, args) File "C:\Python24\Lib\site-packages\win32com\server\policy.py", line 290, in _invoke_ return S_OK, -1, self._invokeex_(dispid, lcid, wFlags, args, None, None) File "C:\Python24\Lib\site-packages\win32com\server\policy.py", line 653, in _invokeex_ args, kwArgs = self._transform_args_(args, kwArgs, dispid, lcid, wFlags, serviceProvider) File "C:\Python24\Lib\site-packages\win32com\server\policy.py", line 648, in _transform_args_ arg = str(arg) exceptions.UnicodeEncodeError: 'ascii' codec can't encode character u'\xae' in position 67: ordinal not in range(128) URL being accessed via self.ie.Navigate( url ) A number of URLs lead to the behavior including the following: http://www.cnb.com:80/ http://www.cnb1.com:80/ http://www.charterbankcc.com:80/ http://www.charterbankec.com:80/ I can provide test code if it is helpful. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1401642&group_id=5470 From noreply at sourceforge.net Tue Jan 10 16:11:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 07:11:56 -0800 Subject: [ python-Bugs-1401642 ] Win32COM policy.py unicode exceptions Message-ID: Bugs item #1401642, was opened at 2006-01-10 14:34 Message generated for change (Comment added) made by rbell01824 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1401642&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: rbell01824 (rbell01824) Assigned to: Nobody/Anonymous (nobody) Summary: Win32COM policy.py unicode exceptions Initial Comment: Getting exceptions when catching events while interacting with InternetExplorer.Application. Class connects to IE via self.ie = DispatchWithEvents("InternetExplorer.Application", InternetExplorerEvents) Subsequent events on some (not all) URLs cause exceptions as follows: pythoncom error: Python error invoking COM method. Traceback (most recent call last): File "C:\Python24\Lib\site-packages\win32com\server\policy.py", line 285, in _Invoke_ return self._invoke_(dispid, lcid, wFlags, args) File "C:\Python24\Lib\site-packages\win32com\server\policy.py", line 290, in _invoke_ return S_OK, -1, self._invokeex_(dispid, lcid, wFlags, args, None, None) File "C:\Python24\Lib\site-packages\win32com\server\policy.py", line 653, in _invokeex_ args, kwArgs = self._transform_args_(args, kwArgs, dispid, lcid, wFlags, serviceProvider) File "C:\Python24\Lib\site-packages\win32com\server\policy.py", line 648, in _transform_args_ arg = str(arg) exceptions.UnicodeEncodeError: 'ascii' codec can't encode character u'\xae' in position 67: ordinal not in range(128) URL being accessed via self.ie.Navigate( url ) A number of URLs lead to the behavior including the following: http://www.cnb.com:80/ http://www.cnb1.com:80/ http://www.charterbankcc.com:80/ http://www.charterbankec.com:80/ I can provide test code if it is helpful. ---------------------------------------------------------------------- >Comment By: rbell01824 (rbell01824) Date: 2006-01-10 15:11 Message: Logged In: YES user_id=1190195 The following url reproduces multiple instances of the behavior: http://www.clever.net/kerry/scuba/main.htm The browser should be configured to allow popups. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1401642&group_id=5470 From noreply at sourceforge.net Tue Jan 10 20:18:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 11:18:16 -0800 Subject: [ python-Feature Requests-1396946 ] %ehrntDRT support for time.strptime Message-ID: Feature Requests item #1396946, was opened at 2006-01-04 16:24 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1396946&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Python Library >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Johan Dahlin (zilche) Assigned to: Nobody/Anonymous (nobody) Summary: %ehrntDRT support for time.strptime Initial Comment: As defined in: http://www.opengroup.org/onlinepubs/009695399/functions/strptime.html %r -> locales representation of time + AM/PM %e -> %d %h -> %b %D -> %m/%d/%y %R -> %H:%M %T -> %H:%M:%S %n/%t -> whitespace ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 20:18 Message: Logged In: YES user_id=1188172 If these codes are supported in strptime, they must also be supported in strftime. But the platform strftime is not guaranteed to support these escapes on e.g. Windows. I don't know if rewriting strftime in Python makes sense. Anyhow, turning this into a feature request. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1396946&group_id=5470 From noreply at sourceforge.net Tue Jan 10 20:29:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 11:29:35 -0800 Subject: [ python-Bugs-1377858 ] segfaults when using __del__ and weakrefs Message-ID: Bugs item #1377858, was opened at 2005-12-10 22:20 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377858&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Carl Friedrich Bolz (cfbolz) Assigned to: Nobody/Anonymous (nobody) Summary: segfaults when using __del__ and weakrefs Initial Comment: You can segfault Python by creating a weakref to an object in its __del__ method, storing it somewhere and then trying to dereference the weakref afterwards. the attached file shows the described behaviour. ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 20:29 Message: Logged In: YES user_id=1188172 Added to outstanding_crashes.py. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-01-09 12:58 Message: Logged In: YES user_id=6656 Hmm, maybe the referenced mayhem is more to do with clearing __dict__ than calling __del__. What breaks if we do things in this order: 1. call __del__ 2. clear weakrefs 3. clear __dict__ ? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-01-09 12:54 Message: Logged In: YES user_id=6656 Hmm, I was kind of hoping this report would get more attention. The problem is obvious if you read typeobject.c around line 660: the weakref list is cleared before __del__ is called, so any weakrefs added during the execution of __del__ are never informed of the object's death. One fix for this would be to clear the weakref list _after_ calling __del__ but that led to other mayhem in ways I haven't boethered to understand (see SF bug #742911). I guess we could just clear out any weakrefs created in __del__ without calling their callbacks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377858&group_id=5470 From noreply at sourceforge.net Tue Jan 10 22:26:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 13:26:46 -0800 Subject: [ python-Bugs-1397850 ] libpython2.4.so get not installed Message-ID: Bugs item #1397850, was opened at 2006-01-05 16:01 Message generated for change (Comment added) made by hajoehlers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1397850&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: hajo (hajoehlers) Assigned to: Nobody/Anonymous (nobody) Summary: libpython2.4.so get not installed Initial Comment: Given: AIX 5.1 GCC 3.3.2 Python 2.4.2 ( Python-2.4.2.tar.gz ) ./configure \ --enable-unicode \ --enable-shared \ --with-gcc \ --mandir=/usr/local/man \ --infodir=/usr/local/info Problem: during " gmake install " the libpython2.4.a will not be installed in /usr/local/lib and the link for libpython2.4.so does not exist then. I did not dig further but below is the output from "gmake install" For me the ... if test -f libpython2.4.so; then ... look wrong because it does not contain a Path and will fail. regards Hajo output during "gmake install" ... if test -f libpython2.4.so; then \^M if test ".so" = .dll; then \^M /opt/freeware/bin/install -c -m 555 libpython2.4.so /usr/local/bin; \^M else \^M /opt/freeware/bin/install -c -m 555 libpython2.4.so /usr/local/lib/libpython2.4.a; \^M if test libpython2.4.so != libpython2.4.a; then \^M (cd /usr/local/lib; ln -sf libpython2.4.a libpython2.4.so); \^M fi \^M fi; \^M else true; \^M ... ---------------------------------------------------------------------- >Comment By: hajo (hajoehlers) Date: 2006-01-10 21:26 Message: Logged In: YES user_id=1420117 Hi Neal if give up to test/fix the configure.in With the help from Ulrich Berning i build a static version and convert these to a shared one. See notes down below. Tnx for supporting Hajo $ cat ./mkshared.python < Bugs item #1397205, was opened at 2006-01-04 21:34 Message generated for change (Comment added) made by pterk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1397205&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Alan G (abgrover) Assigned to: Nobody/Anonymous (nobody) Summary: no handler base classes in xml.sax Initial Comment: The 2.4.1 Documentation for xml.sax.handler states: Handler implementations should inherit from the base classes provided in the module xml.sax, so that all methods get default implementations. However, there are no handler base classes in xml.sax. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2006-01-10 22:33 Message: Logged In: YES user_id=174455 You need to look at xml.sax.handler. See (bottom of) http://www.python.org/doc/2.4.2/lib/module-xml.sax.html (See also xml.sax.handler) There's also a hint in xml.sax.__doc__ Python 2.4.1 (#2, May 5 2005, 11:32:06) [GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import xml.sax.handler >>> dir(xml.sax.handler) ['ContentHandler', 'DTDHandler', 'EntityResolver', 'ErrorHandler', '__builtins__', '__doc__', '__file__', '__name__', 'all_features', 'all_properties', 'feature_external_ges', 'feature_external_pes', 'feature_namespace_prefixes', 'feature_namespaces', 'feature_string_interning', 'feature_validation', 'property_declaration_handler', 'property_dom_node', 'property_encoding', 'property_interning_dict', 'property_lexical_handler', 'property_xml_string', 'version'] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1397205&group_id=5470 From noreply at sourceforge.net Tue Jan 10 22:38:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 13:38:08 -0800 Subject: [ python-Bugs-1397205 ] no handler base classes in xml.sax Message-ID: Bugs item #1397205, was opened at 2006-01-04 21:34 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1397205&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Alan G (abgrover) Assigned to: Nobody/Anonymous (nobody) Summary: no handler base classes in xml.sax Initial Comment: The 2.4.1 Documentation for xml.sax.handler states: Handler implementations should inherit from the base classes provided in the module xml.sax, so that all methods get default implementations. However, there are no handler base classes in xml.sax. ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 22:38 Message: Logged In: YES user_id=1188172 Thanks, corrected the reference in rev. 42007/42008. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2006-01-10 22:33 Message: Logged In: YES user_id=174455 You need to look at xml.sax.handler. See (bottom of) http://www.python.org/doc/2.4.2/lib/module-xml.sax.html (See also xml.sax.handler) There's also a hint in xml.sax.__doc__ Python 2.4.1 (#2, May 5 2005, 11:32:06) [GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import xml.sax.handler >>> dir(xml.sax.handler) ['ContentHandler', 'DTDHandler', 'EntityResolver', 'ErrorHandler', '__builtins__', '__doc__', '__file__', '__name__', 'all_features', 'all_properties', 'feature_external_ges', 'feature_external_pes', 'feature_namespace_prefixes', 'feature_namespaces', 'feature_string_interning', 'feature_validation', 'property_declaration_handler', 'property_dom_node', 'property_encoding', 'property_interning_dict', 'property_lexical_handler', 'property_xml_string', 'version'] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1397205&group_id=5470 From noreply at sourceforge.net Tue Jan 10 22:39:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 13:39:12 -0800 Subject: [ python-Bugs-1397474 ] timeit execution enviroment Message-ID: Bugs item #1397474, was opened at 2006-01-05 04:50 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1397474&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: rurpy (rurpy) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: timeit execution enviroment Initial Comment: library reference manual, section 10.10 The documentation for the timeit module does not make clear exactly what enviroment the timed code will be run in, particularly when a function in the current program is being timed (as opposed to an external program.) This information is available in the examples section but examples should illustrate already described behavior, not present new information. I think the following text should be appended below the third paragraph in the "class Timer" section which reads: To measure the execution time of the first statement, use the timeit() method. The repeat() method is a convenience to call timeit() multiple times and return a list of results. Proposed addition: The timed statement is executed in the namespace of the timeit module. If a function in the __main__ module is being timed, it can be made accessible to the timer module by using a setup statement like "from __main__ import xx" where xx is the function's name in __main__. Of course "__main__" can be a different module name if appropriate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1397474&group_id=5470 From noreply at sourceforge.net Tue Jan 10 22:54:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 13:54:28 -0800 Subject: [ python-Bugs-927248 ] Python segfaults when freeing " deep" objects Message-ID: Bugs item #927248, was opened at 2004-04-01 06:07 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=927248&group_id=5470 Please note that this message 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: 6 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: Python segfaults when freeing "deep" objects Initial Comment: An example to produce this behavior: >>> f = lambda: None >>> for i in range(1000000): ... f = f.__call__ ... >>> f = None Segmentation fault ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 22:54 Message: Logged In: YES user_id=1188172 CVS HEAD of 2006/01/10 still segfaults (here GCC 3.4.5). Segfault occurs at wrapper_dealloc in descrobject.c. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-06-02 21:25 Message: Logged In: YES user_id=89016 Python CVS from 2004-06-02 seems to work: Python 2.4a0 (#5, Jun 2 2004, 20:23:30) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-113)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> f = lambda: None >>> for x in xrange(1000000): ... f = f.__call__ ... >>> f >>> f = None >>> f >>> ---------------------------------------------------------------------- Comment By: Jacob Smullyan (smulloni) Date: 2004-04-08 05:20 Message: Logged In: YES user_id=108556 Python CVS as of April 7th consistently segfaults with the above example for me: smulloni at bracknell src $ ~/apps/python-cvs/bin/python Python 2.4a0 (#1, Apr 7 2004, 23:10:34) [GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> f=lambda: None >>> for x in xrange(1000000): ... f=f.__call__ ... >>> f=None Segmentation fault Of course, maybe that's a good thing :). ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-04-05 02:32 Message: Logged In: YES user_id=764593 CVS for 2.4 has comments for (and a fix for) problems similar to this. Does the bug still exist with that source code? ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-04-01 07:21 Message: Logged In: YES user_id=55188 Oh. my patch doesn't fix another scenario that using recursive by two or more types of slots. So I remove. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=927248&group_id=5470 From noreply at sourceforge.net Tue Jan 10 22:56:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 13:56:41 -0800 Subject: [ python-Bugs-942706 ] Python crash on __init__/__getattr__/__setattr__ interaction Message-ID: Bugs item #942706, was opened at 2004-04-27 01:39 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=942706&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: has (hhas) Assigned to: Nobody/Anonymous (nobody) Summary: Python crash on __init__/__getattr__/__setattr__ interaction Initial Comment: The following code causes [Mac]Python 2.3 process to crash (Bad!) rather than raise an error (good) when creating a new instance of Foo: class Foo: def __init__(self): self.x = 1 def __getattr__(self, name): if self.x: pass # etc... def __setattr__(self, name, val): if self.x: pass # etc... (See for a working example plus general solution to the referencing-instance-var-before-it's-created paradox that threw up this bug in the first place.) ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 22:56 Message: Logged In: YES user_id=1188172 To the OP: Is there still a crash with newest Python 2.4? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-06-02 21:17 Message: Logged In: YES user_id=89016 Assigning to self.x in __init__() calls __setattr__(), which checks self.x, which calls __getattr__() which checks self.x, which leads to endless recursion. This usually leads to a "RuntimeError: maximum recursion depth exceeded". In what way does Python 2.3 crash? To avoid the recursion access the instance dictionary directly: class Foo: def __init__(self): self.x = 1 def __getattr__(self, name): if "x" in self.__dict__ and self.__dict__["x"]: pass # etc... def __setattr__(self, name, val): if self.x: pass # etc... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=942706&group_id=5470 From noreply at sourceforge.net Tue Jan 10 22:58:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 13:58:42 -0800 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 birkenfeld 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: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Guido van Rossum (gvanrossum) 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: 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 Tue Jan 10 23:00:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 14:00:20 -0800 Subject: [ python-Bugs-983311 ] simple attribute access causing segfault in certain cases Message-ID: Bugs item #983311, was opened at 2004-07-01 11:42 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983311&group_id=5470 Please note that this message 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: Out of Date Priority: 5 Submitted By: Simon Michael (simon) Assigned to: Nobody/Anonymous (nobody) Summary: simple attribute access causing segfault in certain cases Initial Comment: Reproduce: zopectl debug (done in zope debugger to get necessary imports) >>> from AccessControl.tests.testSecurity import SecurityTests >>> SecurityTests.doc_class Python 2.3.4 crashes silently. Python 2.3.3 works normally on the same machine. This is some virtual server variant of debian gnu/linux on intel (aktiom.net. On another machine (standard debian i386) Python 2.3.3 shows the same crash. That attr in zope/lib/python/AccessControl/tests/testSecurity.py looks like: class SecurityTests (DTMLTests): doc_class = UnownedDTML # another class Cf http://zwiki.org/IssueNo0860 . ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 23:00 Message: Logged In: YES user_id=1188172 I think yes. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-07-14 10:56 Message: Logged In: YES user_id=6656 Uh, there seems little chance this is a Python core bug. Can we close this report? ---------------------------------------------------------------------- Comment By: Andy Dustman (adustman) Date: 2004-07-13 22:02 Message: Logged In: YES user_id=71372 This may or may not be related: I've had scattered reports of people having trouble with attribute access (maybe) with MySQLdb-1.0.0 on Python-2.3.4 (and maybe 2.3.3 but not 2.2) on *BSD and Mac OS X, but I can't reproduce it on Linux (x86) with 2.3.4. One person is getting a segfault upon import (this is not in the bug listed below); I am trying to get a gdb backtraces. https://sourceforge.net/tracker/index.php?func=detail&aid=970667&group_id=22307&atid=374932 ---------------------------------------------------------------------- Comment By: Simon Michael (simon) Date: 2004-07-13 21:33 Message: Logged In: YES user_id=572 See also discussion at http://collector.zope.org/Zope/1395 ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-07-01 22:21 Message: Logged In: YES user_id=4771 What I mean here is that you should report this bug to Zope, not to Python, unless there is a good reason to suspect that a bug in the Python core is causing it. But to me it really looks like a bug in the Zope extension module, which for some reason shows up only with some version of Python or on some platform. ---------------------------------------------------------------------- Comment By: Simon Michael (simon) Date: 2004-07-01 21:25 Message: Logged In: YES user_id=572 UnownedDTML is indeed a zope extension class. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-07-01 17:20 Message: Logged In: YES user_id=4771 If this bug involves C extension modules specific to Zope then I'd first consider it as a bug in one of these modules. I would be particularly suspicious that this is the case in a file called testSecurity: isn't its goal to check some C-implemented security feature of Zope? If I am wrong please try to provide a Python code sample. Reading a class attribute out of some class tends to work just fine. ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2004-07-01 12:34 Message: Logged In: YES user_id=11084 Works for me with Python 2.3.3/4 on three different Linux systems. ---------------------------------------------------------------------- Comment By: Simon Michael (simon) Date: 2004-07-01 11:52 Message: Logged In: YES user_id=572 > Python 2.3.3 works normally on the same machine. I meant: Python 2.3.3 works normally on another, similar machine (virtual linux host). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983311&group_id=5470 From noreply at sourceforge.net Tue Jan 10 23:02:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 14:02:15 -0800 Subject: [ python-Bugs-600007 ] Another dealloc stack killer Message-ID: Bugs item #600007, was opened at 2002-08-26 03:37 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=600007&group_id=5470 Please note that this message 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: Duplicate Priority: 3 Submitted By: Tim Peters (tim_one) Assigned to: Guido van Rossum (gvanrossum) Summary: Another dealloc stack killer Initial Comment: >From c.l.py: """ From: Pavel Pergamenshchik <pp64 at cornell.edu> Sent: Sunday, August 25, 2002 9:17 PM To: python-list at python.org Subject: Python 2.2.1 bug I found a way to break Python 2.2.1 (at least) both on Linux and Windows. ... eval("int" + ".__call__"*100000) at the prompt, then press ctrl-D or ctrl-Z to edit. This will result in a segfault on Linux and some weird "unknown software exception" thing on Windows. """ At shutdown, the C stack is blown by a very deep nest of _Py_Dealloc wrapper_dealloc calls. That was under current CVS head; I'm sure it's the same deal in 2.2. ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 23:02 Message: Logged In: YES user_id=1188172 Duplicate of #927248. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-29 01:30 Message: Logged In: YES user_id=33168 The threshold was 300000 for me on Linux. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-08-26 16:06 Message: Logged In: YES user_id=31435 I suppose you need to reduce your stack limit, or boost the multiplier, then. I would agree it's hard to get excited about this one <wink>. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-26 15:56 Message: Logged In: YES user_id=6380 Hm, I cannot reproduce this on Linux, with either the 2.2maintenance branch or 2.3. I trust that it's a problem though. Reducing priority. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=600007&group_id=5470 From noreply at sourceforge.net Tue Jan 10 23:05:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 14:05:25 -0800 Subject: [ python-Bugs-927248 ] Python segfaults when freeing " deep" objects Message-ID: Bugs item #927248, was opened at 2004-03-31 23:07 Message generated for change (Comment added) made by kuran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=927248&group_id=5470 Please note that this message 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: 6 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: Python segfaults when freeing "deep" objects Initial Comment: An example to produce this behavior: >>> f = lambda: None >>> for i in range(1000000): ... f = f.__call__ ... >>> f = None Segmentation fault ---------------------------------------------------------------------- >Comment By: Jp Calderone (kuran) Date: 2006-01-10 17:05 Message: Logged In: YES user_id=366566 Note that in doerwalter transcript, _ is still bound to the method wrapper, preventing Python from attempting to free it. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 16:54 Message: Logged In: YES user_id=1188172 CVS HEAD of 2006/01/10 still segfaults (here GCC 3.4.5). Segfault occurs at wrapper_dealloc in descrobject.c. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-06-02 15:25 Message: Logged In: YES user_id=89016 Python CVS from 2004-06-02 seems to work: Python 2.4a0 (#5, Jun 2 2004, 20:23:30) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-113)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> f = lambda: None >>> for x in xrange(1000000): ... f = f.__call__ ... >>> f >>> f = None >>> f >>> ---------------------------------------------------------------------- Comment By: Jacob Smullyan (smulloni) Date: 2004-04-07 23:20 Message: Logged In: YES user_id=108556 Python CVS as of April 7th consistently segfaults with the above example for me: smulloni at bracknell src $ ~/apps/python-cvs/bin/python Python 2.4a0 (#1, Apr 7 2004, 23:10:34) [GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> f=lambda: None >>> for x in xrange(1000000): ... f=f.__call__ ... >>> f=None Segmentation fault Of course, maybe that's a good thing :). ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-04-04 20:32 Message: Logged In: YES user_id=764593 CVS for 2.4 has comments for (and a fix for) problems similar to this. Does the bug still exist with that source code? ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-04-01 00:21 Message: Logged In: YES user_id=55188 Oh. my patch doesn't fix another scenario that using recursive by two or more types of slots. So I remove. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=927248&group_id=5470 From noreply at sourceforge.net Tue Jan 10 23:15:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 14:15:42 -0800 Subject: [ python-Bugs-1043446 ] Uninterruptable loop Message-ID: Bugs item #1043446, was opened at 2004-10-09 06:26 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&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: Python 2.4 Status: Open Resolution: None Priority: 3 Submitted By: Jp Calderone (kuran) >Assigned to: Raymond Hettinger (rhettinger) Summary: Uninterruptable loop Initial Comment: import itertools list(itertools.repeat('x')) ^C will not interrupt this. ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 23:15 Message: Logged In: YES user_id=1188172 What to do here? ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-10-16 00: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 10: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=105470&aid=1043446&group_id=5470 From noreply at sourceforge.net Tue Jan 10 23:20:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 14:20:08 -0800 Subject: [ python-Bugs-830261 ] __mul__ taken as __rmul__ for mul-by-int only Message-ID: Bugs item #830261, was opened at 2003-10-25 23:57 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=830261&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: __mul__ taken as __rmul__ for mul-by-int only Initial Comment: Tiniest way to reproduce: >>> class X(object): ... def __mul__(self, other): return '%r???' % other ... >>> x=X() >>> 23*x '23???' >>> 2.3*x Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: can't multiply sequence to non-int >>> weird error message hints at cause: Objects/typeobject.c sets sq_repeat slot indifferently for both __mul__ AND __rmul__, then Objects/abstract.c function PyNumber_Multiply checks both operands for sq_repeats, finds it in the RHO and thus calls sequence_repeat which erroneously succeeds when the LHO is 23 and fails w/weird error message when it's 2.3. I'm leaving this unassigned because it's anything but obvious to me what the fix should be! If anybody HAS obvious fixes to suggest I'll be glad to implement and commit them, though. ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 23:20 Message: Logged In: YES user_id=1188172 This appears to be fixed in 2.5 HEAD, but not in the 2.4 branch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=830261&group_id=5470 From noreply at sourceforge.net Tue Jan 10 23:20:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 14:20:55 -0800 Subject: [ python-Bugs-908441 ] default index for __getslice__ is not sys.maxint Message-ID: Bugs item #908441, was opened at 2004-03-02 18:41 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=908441&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Drochner (drochner) Assigned to: Nobody/Anonymous (nobody) Summary: default index for __getslice__ is not sys.maxint Initial Comment: (This applies also to __setslice__ and possibly more.) (This was already present in Python-2.2.) If the upper slice index is omitted, a default is passed to the __getslice__ method. Documentation claims this is sys.maxint. This is wrong if INT_MAX and LONG_MAX differ; what is passed is INT_MAX while sys.maxint is LONG_MAX. I'm not sure whether to call it a code bug or a documentation bug; at least there is code out there which compares to sys.maxint. The whole code path from ceval.c:_PyEval_SliceIndex() to operator.c:op_getslice() to abstract.c:PySequence_GetSlice() to classobject.c:instance_slice() has just room for an "int", so a code fix is pretty invasive... A small test program to check this: ========== import sys class sl(object): def __getslice__(self, a, b): return (a, b) print "sys.maxint = %ld" % sys.maxint bounds = sl()[:] print "default bounds = [%ld, %ld]" % bounds ========== gives on NetBSD/amd64: sys.maxint = 9223372036854775807 default bounds = [0, 2147483647] ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 23:20 Message: Logged In: YES user_id=1188172 Do we want to support long slice indices? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=908441&group_id=5470 From noreply at sourceforge.net Tue Jan 10 23:21:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 14:21:24 -0800 Subject: [ python-Bugs-837242 ] id() for large ptr should return a long Message-ID: Bugs item #837242, was opened at 2003-11-06 16:11 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837242&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: id() for large ptr should return a long Initial Comment: Under something like Redhat 10 the address space is messed about with to "prevent stack smash attacks" or some such. This means that you sometimes get addresses in the high half of a 32 bit int. Since Python ints are signed, this means we return a negative number from id(). For 2.4, we should probably return a long. ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 23:21 Message: Logged In: YES user_id=1188172 Perhaps, for 2.5? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2003-11-06 21:54 Message: Logged In: YES user_id=21627 Would there anything be wrong with making that change right away? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837242&group_id=5470 From noreply at sourceforge.net Tue Jan 10 23:28:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 14:28:32 -0800 Subject: [ python-Bugs-890010 ] Odd warning behaviors Message-ID: Bugs item #890010, was opened at 2004-02-03 23:25 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=890010&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Jeremy Hylton (jhylton) Summary: Odd warning behaviors Initial Comment: This is from Evan Simpson, on the zope-dev list. The bulk have to do with what happens if __name__ is set to None: Subject: Re: [Zope-dev] Re: Zope 2.7.0 rc2 + python 2.3.3 problem http://mail.zope.org/mailman/listinfo/zope-dev Python 2.3.3 (#2, Jan 13 2004, 00:47:05) [GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> range(1.0) __main__:1: DeprecationWarning: integer argument expected, got float [0] >>> So far, so good. However: Python 2.3.3 (#2, Jan 13 2004, 00:47:05) [GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> __name__=None >>> range(1.0) [] >>> 1+1 Traceback (most recent call last): File "/usr/lib/python2.3/warnings.py", line 57, in warn warn_explicit(message, category, filename, lineno, module, registry) File "/usr/lib/python2.3/warnings.py", line 63, in warn_explicit if module[-3:].lower() == ".py": TypeError: unsubscriptable object >>> ...and... Python 2.3.3 (#2, Jan 13 2004, 00:47:05) [GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import warnings >>> warnings.simplefilter("error", category=DeprecationWarning) >>> range(1.0) [] >>> 1+1 Traceback (most recent call last): File "/usr/lib/python2.3/warnings.py", line 57, in warn warn_explicit(message, category, filename, lineno, module, registry) File "/usr/lib/python2.3/warnings.py", line 92, in warn_explicit raise message DeprecationWarning: integer argument expected, got float >>> ...and... Python 2.3.3 (#2, Jan 13 2004, 00:47:05) [GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import pdb >>> __name__ = None >>> pdb.run('range(1.0)') > (1)?() (Pdb) s --Call-- > /usr/lib/python2.3/warnings.py(24)warn() -> def warn(message, category=None, stacklevel=1): (Pdb) r --Return-- /usr/lib/python2.3/bdb.py:302: RuntimeWarning: tp_compare didn't return -1 or -2 for exception i = max(0, len(stack) - 1) [traceback snipped] Looks like something isn't properly propagating exceptions. Cheers, Evan @ 4-am ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 23:28 Message: Logged In: YES user_id=1188172 In current SVN heads, range(1.0) gives DeprecationWarning and __name__=None; range(1.0) gives TypeError. Is this okay? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-02-17 01:51 Message: Logged In: YES user_id=31435 I'm listening, but with half of part of one ear. Have to agree convertsimple() was wrong in these cases, but can't make time for more than that. Reassigned to Jeremy, partly at random (his is one of the names that shows up as a recent getargs.c changer). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-02-12 15:09 Message: Logged In: YES user_id=6656 Is anyone listening? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-02-04 16:05 Message: Logged In: YES user_id=6656 Oops, wrong file. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-02-04 16:03 Message: Logged In: YES user_id=6656 How's this? It's horrible, but I'm not sure that can be avoided. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-02-04 14:22 Message: Logged In: YES user_id=6656 OK, the problem is that returning NULL from getargs.c:convertsimple indicates *success* (argh!). Fixing that provokes weird errors from handle_range_longs. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-02-04 13:10 Message: Logged In: YES user_id=6656 Might this be specific to range()? [mwh at pc150 build]$ ./python.exe -Werror Python 2.4a0 (#3, Feb 3 2004, 19:23:25) [GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> range(5.0) [] range()'s argument handling is somewhat odd ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=890010&group_id=5470 From noreply at sourceforge.net Tue Jan 10 23:42:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 14:42:55 -0800 Subject: [ python-Bugs-871026 ] PyOS_snprintf segfaults on missing native snprintf Message-ID: Bugs item #871026, was opened at 2004-01-05 17:37 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=871026&group_id=5470 Please note that this message 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 Submitted By: Federico Di Gregorio (fog) Assigned to: Nobody/Anonymous (nobody) Summary: PyOS_snprintf segfaults on missing native snprintf Initial Comment: On architectures missing a native snprintf (checked on win32 + Borland), PyOS_snprintf may cause a segfault when passed a string argument (%s) larger than 512 bytes. Btw, allocating an extra 512 bytes and hoping for the best while calling native vsprintf is also a security risk (due to buffer overruns.) ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 23:42 Message: Logged In: YES user_id=1188172 Another year passed (almost), so this can be closed? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-03-22 05:26 Message: Logged In: YES user_id=31435 Nick, Python already uses _snprintf and _vsnprintf under MSVC on Windows. The OP said he tried using Borland on Windows, which presumably lacks them (Borland has its own runtime libraries, and do note that these things are not part of the Win32 API, they're part of the compiler-specific C runtime library). Since snprintf and vsnprintf are required by both POSIX and the C99 standard, and are supplied (albeit with a goofy spelling, and non-standard endcase behavior) by MSVC, the number of platforms they're not available on is both small and shrinking. I doubt any current Python developer uses such a platform, so if the OP doesn't care enough to volunteer a patch either, we should acknowledge reality and close this as WontFix. (The OP could still ask Borland to modernize their C offering, of course -- if Borland is falling behind the times, it's not really Python's problem to write a modern C library for them.) ---------------------------------------------------------------------- Comment By: Nick Bastin (mondragon) Date: 2004-03-22 04:39 Message: Logged In: YES user_id=430343 Win32 actually *does* have snprintf, but like most functions added to the C standard later in life, it's implemented as _snprintf(). Really, it seems that the autoconf rule needs to be smarter than just checking for snprintf, but rather needs to redefine snprintf as _snprintf on platforms that have _snprintf. Of course, the implementation of PyOS_snprintf still needs fixing. ---------------------------------------------------------------------- Comment By: Federico Di Gregorio (fog) Date: 2004-01-05 22:12 Message: Logged In: YES user_id=10245 Yes, it causes a segfault when a module using PyOS_snprintf passes it a string that is bigger than the buffer length + 512. This happens because first vsprintf is called with a too small buffer and the stack is corrupted and then (too late!) there is the check and the fatal error. Py_FatalError is called (maybe) but the return address is gone from the stack and all you get is a segfault at the end of the function. I know PyOS_snprintf is internal but it can be used by extension modules and (anyway) growing a buffer 512 bytes statically is almost the same as using sprintf (without the 'n') directly. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-01-05 18:01 Message: Logged In: YES user_id=31435 Does it really cause a segfault? This code is trying to cause Py_FatalError instead in that case: else if ((size_t)len >= size + 512) Py_FatalError("Buffer overflow in PyOS_snprintf/PyOS_vsnprintf"); If that part isn't working, that is indeed a bug. WRT security, PyOS_snprintf is an internal API function -- programs written in Python can't invoke it directly. If a (necessarily) internal use of the function triggers this case, that's an error in the coding of the internals, but the *intent* is that Py_FatalError() get invoked then anyway, which immediately kills the Python process (via C abort()). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=871026&group_id=5470 From noreply at sourceforge.net Tue Jan 10 23:49:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 14:49:59 -0800 Subject: [ python-Bugs-1401642 ] Win32COM policy.py unicode exceptions Message-ID: Bugs item #1401642, was opened at 2006-01-10 15:34 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1401642&group_id=5470 Please note that this 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: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: rbell01824 (rbell01824) Assigned to: Nobody/Anonymous (nobody) Summary: Win32COM policy.py unicode exceptions Initial Comment: Getting exceptions when catching events while interacting with InternetExplorer.Application. Class connects to IE via self.ie = DispatchWithEvents("InternetExplorer.Application", InternetExplorerEvents) Subsequent events on some (not all) URLs cause exceptions as follows: pythoncom error: Python error invoking COM method. Traceback (most recent call last): File "C:\Python24\Lib\site-packages\win32com\server\policy.py", line 285, in _Invoke_ return self._invoke_(dispid, lcid, wFlags, args) File "C:\Python24\Lib\site-packages\win32com\server\policy.py", line 290, in _invoke_ return S_OK, -1, self._invokeex_(dispid, lcid, wFlags, args, None, None) File "C:\Python24\Lib\site-packages\win32com\server\policy.py", line 653, in _invokeex_ args, kwArgs = self._transform_args_(args, kwArgs, dispid, lcid, wFlags, serviceProvider) File "C:\Python24\Lib\site-packages\win32com\server\policy.py", line 648, in _transform_args_ arg = str(arg) exceptions.UnicodeEncodeError: 'ascii' codec can't encode character u'\xae' in position 67: ordinal not in range(128) URL being accessed via self.ie.Navigate( url ) A number of URLs lead to the behavior including the following: http://www.cnb.com:80/ http://www.cnb1.com:80/ http://www.charterbankcc.com:80/ http://www.charterbankec.com:80/ I can provide test code if it is helpful. ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 23:49 Message: Logged In: YES user_id=1188172 Since it's a problem with the win32 extensions which aren't part of the official Python distribution, please report this to ActiveState or the Pywin32 maintainer. ---------------------------------------------------------------------- Comment By: rbell01824 (rbell01824) Date: 2006-01-10 16:11 Message: Logged In: YES user_id=1190195 The following url reproduces multiple instances of the behavior: http://www.clever.net/kerry/scuba/main.htm The browser should be configured to allow popups. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1401642&group_id=5470 From noreply at sourceforge.net Tue Jan 10 23:50:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 14:50:42 -0800 Subject: [ python-Bugs-1394135 ] Deleting first item causes anydbm.first() to fail Message-ID: Bugs item #1394135, was opened at 2005-12-31 05:24 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dan Bisalputra (danbiz) Assigned to: Nobody/Anonymous (nobody) Summary: Deleting first item causes anydbm.first() to fail Initial Comment: If the first item in a database is deleted, the first call to anydbm.first() after the deletion causes a DBNotFoundError exception to be raised. The attached program causes the error on my system. I am currently working around the problem by calling first() after each deletion, enclosed by a try block. I am using Python 2.4.2 running under Windows ME. ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 23:50 Message: Logged In: YES user_id=1188172 Confirmed here (Linux, various Pythons). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394135&group_id=5470 From noreply at sourceforge.net Tue Jan 10 23:51:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 14:51:43 -0800 Subject: [ python-Bugs-687648 ] classic division in demos/ directory Message-ID: Bugs item #687648, was opened at 2003-02-16 23:27 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687648&group_id=5470 Please note that this 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: Not a Bug Status: Open Resolution: None >Priority: 4 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: classic division in demos/ directory Initial Comment: PEP 238 states: - The standard library will use the future division statement and the // operator when appropriate, so as to completely avoid classic division. While the demos/ directory is not technically part of the standard library, it does contain code that should work, and that newbies may examine in the course of learning Python. Python source there should follow the same rules as anyplace else. I'll volunteer to make the changes and submit a patch, if it is agreed that the changes should indeed be made. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 09:59 Message: Logged In: YES user_id=80475 Is this still open or is there a patch forthcoming? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-23 14:48 Message: Logged In: YES user_id=6380 Excellent. I hope you'll try to also make a judgement (at least in some cases) whether a particular piece of demo code is still relevant -- there is unfortunately a lot of stale demo code. Also see if there are other kinds of modernization that could be done (see PEP 290). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687648&group_id=5470 From noreply at sourceforge.net Tue Jan 10 23:54:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 14:54:02 -0800 Subject: [ python-Bugs-871026 ] PyOS_snprintf segfaults on missing native snprintf Message-ID: Bugs item #871026, was opened at 2004-01-05 11:37 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=871026&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core >Group: 3rd Party >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Federico Di Gregorio (fog) Assigned to: Nobody/Anonymous (nobody) Summary: PyOS_snprintf segfaults on missing native snprintf Initial Comment: On architectures missing a native snprintf (checked on win32 + Borland), PyOS_snprintf may cause a segfault when passed a string argument (%s) larger than 512 bytes. Btw, allocating an extra 512 bytes and hoping for the best while calling native vsprintf is also a security risk (due to buffer overruns.) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-01-10 17:54 Message: Logged In: YES user_id=31435 Indeed, nine months is long enough to make a baby, so closing this as 3rdParty + WontFix. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 17:42 Message: Logged In: YES user_id=1188172 Another year passed (almost), so this can be closed? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-03-21 23:26 Message: Logged In: YES user_id=31435 Nick, Python already uses _snprintf and _vsnprintf under MSVC on Windows. The OP said he tried using Borland on Windows, which presumably lacks them (Borland has its own runtime libraries, and do note that these things are not part of the Win32 API, they're part of the compiler-specific C runtime library). Since snprintf and vsnprintf are required by both POSIX and the C99 standard, and are supplied (albeit with a goofy spelling, and non-standard endcase behavior) by MSVC, the number of platforms they're not available on is both small and shrinking. I doubt any current Python developer uses such a platform, so if the OP doesn't care enough to volunteer a patch either, we should acknowledge reality and close this as WontFix. (The OP could still ask Borland to modernize their C offering, of course -- if Borland is falling behind the times, it's not really Python's problem to write a modern C library for them.) ---------------------------------------------------------------------- Comment By: Nick Bastin (mondragon) Date: 2004-03-21 22:39 Message: Logged In: YES user_id=430343 Win32 actually *does* have snprintf, but like most functions added to the C standard later in life, it's implemented as _snprintf(). Really, it seems that the autoconf rule needs to be smarter than just checking for snprintf, but rather needs to redefine snprintf as _snprintf on platforms that have _snprintf. Of course, the implementation of PyOS_snprintf still needs fixing. ---------------------------------------------------------------------- Comment By: Federico Di Gregorio (fog) Date: 2004-01-05 16:12 Message: Logged In: YES user_id=10245 Yes, it causes a segfault when a module using PyOS_snprintf passes it a string that is bigger than the buffer length + 512. This happens because first vsprintf is called with a too small buffer and the stack is corrupted and then (too late!) there is the check and the fatal error. Py_FatalError is called (maybe) but the return address is gone from the stack and all you get is a segfault at the end of the function. I know PyOS_snprintf is internal but it can be used by extension modules and (anyway) growing a buffer 512 bytes statically is almost the same as using sprintf (without the 'n') directly. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-01-05 12:01 Message: Logged In: YES user_id=31435 Does it really cause a segfault? This code is trying to cause Py_FatalError instead in that case: else if ((size_t)len >= size + 512) Py_FatalError("Buffer overflow in PyOS_snprintf/PyOS_vsnprintf"); If that part isn't working, that is indeed a bug. WRT security, PyOS_snprintf is an internal API function -- programs written in Python can't invoke it directly. If a (necessarily) internal use of the function triggers this case, that's an error in the coding of the internals, but the *intent* is that Py_FatalError() get invoked then anyway, which immediately kills the Python process (via C abort()). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=871026&group_id=5470 From noreply at sourceforge.net Tue Jan 10 23:57:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 14:57:09 -0800 Subject: [ python-Bugs-992207 ] exec statement balks at CR/LF Message-ID: Bugs item #992207, was opened at 2004-07-16 11:21 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992207&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: Konrad Hinsen (hinsen) Assigned to: Nobody/Anonymous (nobody) Summary: exec statement balks at CR/LF Initial Comment: Under Linux and MacOS (no others tested), if "foo.py" is a DOS/ Windows style Python file (CR/LF line endings), then python foo.py will work, as will execfile("foo.py") and exec file("foo.py") from inside Python. However, exec file("foo.py").read() will report a syntax error. In other words, the parser seems to accept CR/LF only if the source of the data is a file, not a string. When running under Linux and MacOS (no others tested), the exec statement reports a syntax error. I didn't find anything about this in the documentation, so I don't know if it's a bug or a feature. If it's a feature, it is not a useful one! ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 23:57 Message: Logged In: YES user_id=1188172 I'm not sure this is a bug. Is exec supposed to accept code in crlf-terminated strings? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992207&group_id=5470 From noreply at sourceforge.net Wed Jan 11 00:07:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 15:07:53 -0800 Subject: [ python-Bugs-1105770 ] null source chars handled oddly Message-ID: Bugs item #1105770, was opened at 2005-01-20 08:35 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105770&group_id=5470 Please note that this 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: None Priority: 5 Submitted By: Reginald B. Charney (rcharney) Assigned to: Nobody/Anonymous (nobody) Summary: null source chars handled oddly Initial Comment: When null characters appear in the source, outside literals, tokenize seems to either: skip the null character and the next two following characters; or ignore the remainder of the line, including the newline character. (To see the invalid characters, use vim, or an editor that displays control characters when needed.) ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-11 00:07 Message: Logged In: YES user_id=1188172 Confirmed with current SVN heads. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105770&group_id=5470 From noreply at sourceforge.net Wed Jan 11 00:08:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 15:08:37 -0800 Subject: [ python-Bugs-1105770 ] null source chars handled oddly Message-ID: Bugs item #1105770, was opened at 2005-01-20 08:35 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105770&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None >Status: Open Resolution: None Priority: 5 Submitted By: Reginald B. Charney (rcharney) Assigned to: Nobody/Anonymous (nobody) Summary: null source chars handled oddly Initial Comment: When null characters appear in the source, outside literals, tokenize seems to either: skip the null character and the next two following characters; or ignore the remainder of the line, including the newline character. (To see the invalid characters, use vim, or an editor that displays control characters when needed.) ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-11 00:07 Message: Logged In: YES user_id=1188172 Confirmed with current SVN heads. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105770&group_id=5470 From noreply at sourceforge.net Wed Jan 11 01:38:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 10 Jan 2006 16:38:59 -0800 Subject: [ python-Bugs-1402308 ] segfault when using mmap(-1,...) [+PATCH] Message-ID: Bugs item #1402308, was opened at 2006-01-11 00: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=1402308&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ralf Schmitt (titty) Assigned to: Nobody/Anonymous (nobody) Summary: segfault when using mmap(-1,...) [+PATCH] Initial Comment: This is happening on OSX, Python 2.4.2: ralf at mini:~/Python-2.4.2$ cat ~/t.py #! /usr/bin/env python import sys print sys.version import mmap mmap.mmap(-1, 4096) ralf at mini:~/Python-2.4.2$ ./python ~/t.py 2.4.2 (#1, Jan 11 2006, 00:58:35) [GCC 4.0.1 (Apple Computer, Inc. build 5247)] Segmentation fault The following one line diff solves that problem (mmap's data member is otherwise uninitialized...) ralf at mini:~/Python-2.4.2$ diff -u Modules/mmapmodule.c-orig Modules/mmapmodule.c--- Modules/mmapmodule.c-orig 2006-01-11 01:12:32.000000000 +0100 +++ Modules/mmapmodule.c 2006-01-11 01:13:06.000000000 +0100 @@ -910,6 +910,7 @@ #endif m_obj = PyObject_New (mmap_object, &mmap_object_type); if (m_obj == NULL) {return NULL;} + m_obj->data = NULL; m_obj->size = (size_t) map_size; m_obj->pos = (size_t) 0; m_obj->fd = dup(fd); However, the problem is that passing -1 as filedescriptor to mmap is perfectly ok when one wants to mmap anonymous memory (at least on FreeeBSD and OS X). The following patch also solves that problem. [mmap.mmap(-1, 4096, mmap.MAP_ANON) now works...] Any chance to get this included? Passing -1 to mmap should not hurt anybody, as systems which do not support it, should then return an error from mmap. ralf at mini:~/Python-2.4.2$ diff -u Modules/mmapmodule.c-orig Modules/mmapmodule.c--- Modules/mmapmodule.c-orig 2006-01-11 01:12:32.000000000 +0100 +++ Modules/mmapmodule.c 2006-01-11 01:23:52.000000000 +0100 @@ -910,10 +910,12 @@ #endif m_obj = PyObject_New (mmap_object, &mmap_object_type); if (m_obj == NULL) {return NULL;} + m_obj->data = NULL; m_obj->size = (size_t) map_size; m_obj->pos = (size_t) 0; - m_obj->fd = dup(fd); - if (m_obj->fd == -1) { + if (fd == -1) { + m_obj->fd = -1; + } else if ((m_obj->fd = dup(fd)) == -1) { Py_DECREF(m_obj); PyErr_SetFromErrno(mmap_module_error); return NULL; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1402308&group_id=5470 From noreply at sourceforge.net Wed Jan 11 09:43:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jan 2006 00:43:36 -0800 Subject: [ python-Bugs-1402308 ] segfault when using mmap(-1,...) [+PATCH] Message-ID: Bugs item #1402308, was opened at 2006-01-11 00:38 Message generated for change (Comment added) made by titty You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1402308&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ralf Schmitt (titty) Assigned to: Nobody/Anonymous (nobody) Summary: segfault when using mmap(-1,...) [+PATCH] Initial Comment: This is happening on OSX, Python 2.4.2: ralf at mini:~/Python-2.4.2$ cat ~/t.py #! /usr/bin/env python import sys print sys.version import mmap mmap.mmap(-1, 4096) ralf at mini:~/Python-2.4.2$ ./python ~/t.py 2.4.2 (#1, Jan 11 2006, 00:58:35) [GCC 4.0.1 (Apple Computer, Inc. build 5247)] Segmentation fault The following one line diff solves that problem (mmap's data member is otherwise uninitialized...) ralf at mini:~/Python-2.4.2$ diff -u Modules/mmapmodule.c-orig Modules/mmapmodule.c--- Modules/mmapmodule.c-orig 2006-01-11 01:12:32.000000000 +0100 +++ Modules/mmapmodule.c 2006-01-11 01:13:06.000000000 +0100 @@ -910,6 +910,7 @@ #endif m_obj = PyObject_New (mmap_object, &mmap_object_type); if (m_obj == NULL) {return NULL;} + m_obj->data = NULL; m_obj->size = (size_t) map_size; m_obj->pos = (size_t) 0; m_obj->fd = dup(fd); However, the problem is that passing -1 as filedescriptor to mmap is perfectly ok when one wants to mmap anonymous memory (at least on FreeeBSD and OS X). The following patch also solves that problem. [mmap.mmap(-1, 4096, mmap.MAP_ANON) now works...] Any chance to get this included? Passing -1 to mmap should not hurt anybody, as systems which do not support it, should then return an error from mmap. ralf at mini:~/Python-2.4.2$ diff -u Modules/mmapmodule.c-orig Modules/mmapmodule.c--- Modules/mmapmodule.c-orig 2006-01-11 01:12:32.000000000 +0100 +++ Modules/mmapmodule.c 2006-01-11 01:23:52.000000000 +0100 @@ -910,10 +910,12 @@ #endif m_obj = PyObject_New (mmap_object, &mmap_object_type); if (m_obj == NULL) {return NULL;} + m_obj->data = NULL; m_obj->size = (size_t) map_size; m_obj->pos = (size_t) 0; - m_obj->fd = dup(fd); - if (m_obj->fd == -1) { + if (fd == -1) { + m_obj->fd = -1; + } else if ((m_obj->fd = dup(fd)) == -1) { Py_DECREF(m_obj); PyErr_SetFromErrno(mmap_module_error); return NULL; ---------------------------------------------------------------------- >Comment By: Ralf Schmitt (titty) Date: 2006-01-11 08:43 Message: Logged In: YES user_id=17929 this is a regression from 2.4.1. On 2.4.1 mmap(-1, 4096, mmap.MAP_ANON) works without problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1402308&group_id=5470 From noreply at sourceforge.net Wed Jan 11 13:19:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jan 2006 04:19:48 -0800 Subject: [ python-Bugs-1394135 ] Deleting first item causes anydbm.first() to fail Message-ID: Bugs item #1394135, was opened at 2005-12-31 15:24 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dan Bisalputra (danbiz) Assigned to: Nobody/Anonymous (nobody) Summary: Deleting first item causes anydbm.first() to fail Initial Comment: If the first item in a database is deleted, the first call to anydbm.first() after the deletion causes a DBNotFoundError exception to be raised. The attached program causes the error on my system. I am currently working around the problem by calling first() after each deletion, enclosed by a try block. I am using Python 2.4.2 running under Windows ME. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-01-11 23:19 Message: Logged In: YES user_id=29957 Which backend is this using? anydbm is just a very very simple wrapper around a bunch of different backends - I have difficulty believing that they _all_ have the same problem. :) ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-11 09:50 Message: Logged In: YES user_id=1188172 Confirmed here (Linux, various Pythons). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394135&group_id=5470 From noreply at sourceforge.net Wed Jan 11 17:02:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jan 2006 08:02:27 -0800 Subject: [ python-Bugs-1403068 ] cannot import extension module with Purify Message-ID: Bugs item #1403068, was opened at 2006-01-11 17:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403068&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Amaury Forgeot d'Arc (amauryf) Assigned to: Nobody/Anonymous (nobody) Summary: cannot import extension module with Purify Initial Comment: When run with Purify, Python cannot load any extension module. Here is a typical output: Starting Purify'd application... Python 2.4.2 (#46, Jan 3 2006, 16:05:11) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import socket Traceback (most recent call last): File "", line 1, in ? File "c:\python\lib\socket.py", line 45, in ? import _socket ImportError: Module use of python24__d$Purify_c_python.dll conflicts with this version of Python. It reproduces with python 2.4.2 and 2.5a0. It works with python 2.3.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403068&group_id=5470 From noreply at sourceforge.net Wed Jan 11 17:22:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jan 2006 08:22:10 -0800 Subject: [ python-Bugs-1403068 ] cannot import extension module with Purify Message-ID: Bugs item #1403068, was opened at 2006-01-11 17:02 Message generated for change (Comment added) made by amauryf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403068&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Amaury Forgeot d'Arc (amauryf) Assigned to: Nobody/Anonymous (nobody) Summary: cannot import extension module with Purify Initial Comment: When run with Purify, Python cannot load any extension module. Here is a typical output: Starting Purify'd application... Python 2.4.2 (#46, Jan 3 2006, 16:05:11) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import socket Traceback (most recent call last): File "", line 1, in ? File "c:\python\lib\socket.py", line 45, in ? import _socket ImportError: Module use of python24__d$Purify_c_python.dll conflicts with this version of Python. It reproduces with python 2.4.2 and 2.5a0. It works with python 2.3.3. ---------------------------------------------------------------------- >Comment By: Amaury Forgeot d'Arc (amauryf) Date: 2006-01-11 17:22 Message: Logged In: YES user_id=389140 The pb seems to be in dynload_win.c, line 136: while (*pch && pch[0] != '_' && pch[1] != 'd' && pch[2] != '.') { This means that if a .pyd has "python_something.dll" in its import table, it will be taken as THE python DLL. I think the line should be: while (*pch && (pch[0] != '_' || pch[1] != 'd' || pch[2] != '.')) { ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403068&group_id=5470 From noreply at sourceforge.net Wed Jan 11 17:35:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jan 2006 08:35:40 -0800 Subject: [ python-Bugs-1403068 ] cannot import extension module with Purify Message-ID: Bugs item #1403068, was opened at 2006-01-11 17:02 Message generated for change (Comment added) made by amauryf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403068&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Amaury Forgeot d'Arc (amauryf) Assigned to: Nobody/Anonymous (nobody) Summary: cannot import extension module with Purify Initial Comment: When run with Purify, Python cannot load any extension module. Here is a typical output: Starting Purify'd application... Python 2.4.2 (#46, Jan 3 2006, 16:05:11) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import socket Traceback (most recent call last): File "", line 1, in ? File "c:\python\lib\socket.py", line 45, in ? import _socket ImportError: Module use of python24__d$Purify_c_python.dll conflicts with this version of Python. It reproduces with python 2.4.2 and 2.5a0. It works with python 2.3.3. ---------------------------------------------------------------------- >Comment By: Amaury Forgeot d'Arc (amauryf) Date: 2006-01-11 17:35 Message: Logged In: YES user_id=389140 The root cause it that Purify renames all DLLs with names like "python24__d$Purify_c_python.dll". With python 2.3, this name was not taken as the python DLL, and no check was performed. The broken logic in my previous comment changed this for 2.4. A more correct fix is to get the python DLL name from the current process, using GetModuleName(PyWin_DLLhModule). ---------------------------------------------------------------------- Comment By: Amaury Forgeot d'Arc (amauryf) Date: 2006-01-11 17:22 Message: Logged In: YES user_id=389140 The pb seems to be in dynload_win.c, line 136: while (*pch && pch[0] != '_' && pch[1] != 'd' && pch[2] != '.') { This means that if a .pyd has "python_something.dll" in its import table, it will be taken as THE python DLL. I think the line should be: while (*pch && (pch[0] != '_' || pch[1] != 'd' || pch[2] != '.')) { ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403068&group_id=5470 From noreply at sourceforge.net Wed Jan 11 18:51:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jan 2006 09:51:33 -0800 Subject: [ python-Bugs-1394135 ] Deleting first item causes anydbm.first() to fail Message-ID: Bugs item #1394135, was opened at 2005-12-30 20:24 Message generated for change (Comment added) made by danbiz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dan Bisalputra (danbiz) Assigned to: Nobody/Anonymous (nobody) Summary: Deleting first item causes anydbm.first() to fail Initial Comment: If the first item in a database is deleted, the first call to anydbm.first() after the deletion causes a DBNotFoundError exception to be raised. The attached program causes the error on my system. I am currently working around the problem by calling first() after each deletion, enclosed by a try block. I am using Python 2.4.2 running under Windows ME. ---------------------------------------------------------------------- >Comment By: Dan Bisalputra (danbiz) Date: 2006-01-11 09:51 Message: Logged In: YES user_id=534494 whichdb() tells me it is using dbhash. By the way, my workaround using the try/except block ended up deferring the problem until later. I eventually ended up closing and reopening the database after each deletion. Not a problem for the simple application I was building; the database worked great otherwise. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-01-11 04:19 Message: Logged In: YES user_id=29957 Which backend is this using? anydbm is just a very very simple wrapper around a bunch of different backends - I have difficulty believing that they _all_ have the same problem. :) ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 14:50 Message: Logged In: YES user_id=1188172 Confirmed here (Linux, various Pythons). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394135&group_id=5470 From noreply at sourceforge.net Wed Jan 11 20:24:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jan 2006 11:24:05 -0800 Subject: [ python-Bugs-1403221 ] 2.3.5 source RPM install fails w/o tk-devel Message-ID: Bugs item #1403221, was opened at 2006-01-11 13: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=1403221&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nathan Zook (nathan_zook_wk) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3.5 source RPM install fails w/o tk-devel Initial Comment: Install fails because _tkinter.so is not found. This library is not built if the tk header files are not found, but the installer treats this as a fatal error. This dependece upon tk-devel is not noted in the .spec file, so the install fails late (and unclearly) instead of early & clearly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403221&group_id=5470 From noreply at sourceforge.net Wed Jan 11 20:27:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jan 2006 11:27:59 -0800 Subject: [ python-Bugs-1403225 ] 2.3.5 RPM provides incompatibility Message-ID: Bugs item #1403225, was opened at 2006-01-11 13: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=1403225&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nathan Zook (nathan_zook_wk) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3.5 RPM provides incompatibility Initial Comment: The 2.3.5 rpm provides list is substantially out of sync with the 2.3.4-14 provides list for CEntOS, making it impossible (for me) to use this rpm to upgrade my installation. Help? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403225&group_id=5470 From noreply at sourceforge.net Wed Jan 11 22:47:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jan 2006 13:47:23 -0800 Subject: [ python-Bugs-1403349 ] in email can't get attachments' filenames using get_filename Message-ID: Bugs item #1403349, was opened at 2006-01-11 16: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=1403349&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal P. (mpasniew) Assigned to: Nobody/Anonymous (nobody) Summary: in email can't get attachments' filenames using get_filename Initial Comment: in the email package (2.4.1) the get_filename() method returns the MIME field "filename" but some messages have 'name' field instead, for example: USUALLY THE HEADER IS: Content-Type: application/octet-stream; name="XX.pdf" Content-Transfer-Encoding: base64 Content-Description: XX.pdf Content-Disposition: attachment; filename="XX.pdf" BUT SOMETIMES THE HEADER IS: Content-type: application/octet-stream; name="XX.xls" Content-transfer-encoding: base64 For this to work properly I had to code a hack along these lines: filename = part.get_filename() if not filename: ct = part.get("Content-type") m = re.compile('name=\"(\S+)\"').search(ct, 1) if m: filename=m.group(1) But it would be helpful to code this in the get_filename() Michal ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403349&group_id=5470 From noreply at sourceforge.net Wed Jan 11 23:39:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jan 2006 14:39:10 -0800 Subject: [ python-Bugs-837242 ] id() for large ptr should return a long Message-ID: Bugs item #837242, was opened at 2003-11-06 16:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837242&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: id() for large ptr should return a long Initial Comment: Under something like Redhat 10 the address space is messed about with to "prevent stack smash attacks" or some such. This means that you sometimes get addresses in the high half of a 32 bit int. Since Python ints are signed, this means we return a negative number from id(). For 2.4, we should probably return a long. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-01-11 23:39 Message: Logged In: YES user_id=21627 How about the attached patch? ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 23:21 Message: Logged In: YES user_id=1188172 Perhaps, for 2.5? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2003-11-06 21:54 Message: Logged In: YES user_id=21627 Would there anything be wrong with making that change right away? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837242&group_id=5470 From noreply at sourceforge.net Wed Jan 11 23:47:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jan 2006 14:47:08 -0800 Subject: [ python-Bugs-1393109 ] cannot build SVN trunk on old systems Message-ID: Bugs item #1393109, was opened at 2005-12-29 21:25 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1393109&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: cannot build SVN trunk on old systems Initial Comment: Parser/asdl_c.py uses "/usr/bin/env python" to find a proper python, but the script don't work on old Pythons (at least it fails on 2.1 and older). iirc, various solutions to this were discussed on python-dev, but nobody seems to have done anything about it. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-01-11 23:47 Message: Logged In: YES user_id=21627 Is this still a problem? Parser/asdl_c.py should not normally be invoked, unless you edit the grammar ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-02 05:31 Message: Logged In: YES user_id=33168 One issue I see in asdl.py is that new-style classes are used. I don't know if they are really necessary. You could try adding something like this to the top of asdl.py and see if that fixes things: try: object except NameError: class object: pass Or maybe we just shouldn't make them new-style if that does fix things. I don't have an old version of python around. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1393109&group_id=5470 From noreply at sourceforge.net Wed Jan 11 23:55:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jan 2006 14:55:38 -0800 Subject: [ python-Bugs-1397850 ] libpython2.4.so get not installed Message-ID: Bugs item #1397850, was opened at 2006-01-05 17:01 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1397850&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: hajo (hajoehlers) Assigned to: Nobody/Anonymous (nobody) Summary: libpython2.4.so get not installed Initial Comment: Given: AIX 5.1 GCC 3.3.2 Python 2.4.2 ( Python-2.4.2.tar.gz ) ./configure \ --enable-unicode \ --enable-shared \ --with-gcc \ --mandir=/usr/local/man \ --infodir=/usr/local/info Problem: during " gmake install " the libpython2.4.a will not be installed in /usr/local/lib and the link for libpython2.4.so does not exist then. I did not dig further but below is the output from "gmake install" For me the ... if test -f libpython2.4.so; then ... look wrong because it does not contain a Path and will fail. regards Hajo output during "gmake install" ... if test -f libpython2.4.so; then \^M if test ".so" = .dll; then \^M /opt/freeware/bin/install -c -m 555 libpython2.4.so /usr/local/bin; \^M else \^M /opt/freeware/bin/install -c -m 555 libpython2.4.so /usr/local/lib/libpython2.4.a; \^M if test libpython2.4.so != libpython2.4.a; then \^M (cd /usr/local/lib; ln -sf libpython2.4.a libpython2.4.so); \^M fi \^M fi; \^M else true; \^M ... ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-01-11 23:55 Message: Logged In: YES user_id=21627 --enable-shared simply isn't supported on AIX. I'm tempted to reject this as "won't fix". If anything should be fixed, we should add *) AC_MSG_ERROR(--enable-shared not supported on this system) ;; to the # Other platforms follow if test $enable_shared = "yes"; then block. ---------------------------------------------------------------------- Comment By: hajo (hajoehlers) Date: 2006-01-10 22:26 Message: Logged In: YES user_id=1420117 Hi Neal if give up to test/fix the configure.in With the help from Ulrich Berning i build a static version and convert these to a shared one. See notes down below. Tnx for supporting Hajo $ cat ./mkshared.python < Bugs item #1379984, was opened at 2005-12-14 01:20 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379984&group_id=5470 Please note that this 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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Blade (blade_doyle) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX: Can't shl_load() a library containing Thread Local Initial Comment: HP-UX runtime loader does not support dynamic load of shared libraries that contain (TLS) thread local storage. As a result, when attempting to import modules that contain TLS the following error is reported: "/usr/lib/dld.sl: Can't shl_load() a library containing Thread Local Storage" This problem was discussed previously on the python.org mail list: http://mail.python.org/pipermail/python-list/2003-May/164024.html There is another option: Use LD_PRELOAD environment variable to cuase the runtime loader to 'pre-load' the pthreads library (and dependancies of the pthread library). See the dld.sl(5) man page for more info on LD_PRELOAD. But, I think a 5th option is ideal. If libpthread.sl (and the dependancies of libpthread) are linked into the python executable at build time then all of these problems are avoided. I suggest that the HP-UX (includes hp-ux on ia64) build process be modified so that libpthead (and depends) are linked in. Or, at least, make a note of this problem/solution in the HP-UX section of the README file distributed with python source. Here is the process I use to work around the TLS problem: HP-UX: bash$ BASECFLAGS="-DTHREAD_STACK_SIZE=0x50000"; export BASECFLAGS bash$ ./configure --without-gcc --enable-shared --with-libs='-lpthread -lstd_v2 -lCsup_v2 -lcl' bash$ **Edit the Makefile and remove -O from the OPT line. bash$ make bash$ make test bash$ make install HP-UX on ia64: bash$ CC=cc; export CC bash$ CXX=aCC; export CXX bash$ BASECFLAGS="+DD64 -DTHREAD_STACK_SIZE=0x50000"; export BASECFLAGS bash$ LDFLAGS="+DD64"; export LDFLAGS bash$ ./configure --without-gcc --enable-shared --with-libs="-lpthread -lCsup -lstd_v2 -lunwind" bash$ unset CC bash$ unset CXX bash$ unset BASECFLAGS bash$ unset LDFLAGS bash$ **Edit the Makefile and remove -O from the OPT line. bash$ make bash$ make test bash$ make install ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-01-11 23:56 Message: Logged In: YES user_id=21627 Can you provide a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379984&group_id=5470 From noreply at sourceforge.net Wed Jan 11 23:57:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jan 2006 14:57:57 -0800 Subject: [ python-Bugs-1379804 ] HP-UX thread stack size needs to be increased Message-ID: Bugs item #1379804, was opened at 2005-12-13 21:22 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379804&group_id=5470 Please note that this 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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Blade (blade_doyle) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX thread stack size needs to be increased Initial Comment: On HP-UX the default thread stack size is "insufficient" and probably needs to be increased if threads are performing any heavy tasks. Obviously, the ideal size depends on you application but I find that THREAD_STACK_SIZE=0x50000 works well for me. Using the default thread stack size my multi-threading tests were failing with a corrupt stack sometimes and this stack trace other times: #0 0x79db8c0c in _isspace+0x2d8 () from /usr/lib/libnss_dns.1 #1 0x7aff62c4 in nss_search+0x28c () from /usr/lib/libc.2 #2 0x7af4d320 in __gethostbyname_r+0x140 () from /usr/lib/libc.2 #3 0x7af4d4bc in gethostbyname+0x94 () from /usr/lib/libc.2 #4 here, I am calling: gethostbyname("localhost") [cut] #23 0x7a8c49ac in OpSession::begin+0x1c0 () from /space/bdoyle/hprisc/lib/oopython.sl #24 0x7aa42660 in PyCFunction_Call+0xc8 () from /space/bdoyle/PythonBinding/Python-2.4.2/libpython2.4.sl [cut] #38 0x7aabbda0 in PyEval_CallObjectWithKeywords+0x1c4 () from /space/bdoyle/PythonBinding/Python-2.4.2/libpython2.4.sl #39 0x7ab17e8c in t_bootstrap+0xa0 () from /space/bdoyle/PythonBinding/Python-2.4.2/libpython2.4.sl #40 0x7ab6400c in __pthread_body+0x44 () from /usr/lib/libpthread.1 #41 0x7ab6e29c in __pthread_start+0x14 () from /usr/lib/libpthread.1 I tested both Python 2.3.4 and 2.4.2 and increased stack size solves the probem on both. I suggest that a note be added to the Python README under the HP-UX section. The note should suggest that the "BASECFLAGS" environment variable be set to include "-DTHREAD_STACK_SIZE=0x50000" prior to running configure. I dont know that 0x50000 is really the ideal stack size..... Blade. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-01-11 23:57 Message: Logged In: YES user_id=21627 Can you provide a patch to configure.in that adds this automatically? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379804&group_id=5470 From noreply at sourceforge.net Thu Jan 12 00:01:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jan 2006 15:01:49 -0800 Subject: [ python-Bugs-1403410 ] TypeError unsubscriptable object caused by warnings.py Message-ID: Bugs item #1403410, was opened at 2006-01-12 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=1403410&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: FreyP (freyp_haufe) Assigned to: Nobody/Anonymous (nobody) Summary: TypeError unsubscriptable object caused by warnings.py Initial Comment: We recently hit a problem with use of Python 2.4 under Zope. #The problem is that warnings.py expects that function warn_explicit is called with either module or filename beeing a string. This is not always true, especially when the warning is caused by a Python script, e.g. a non-ASCII character without encoding declaration causing a "Non-ASCII character ... in file ... on line ..., but no encoding declared; see ..." the slice operation 'if module[-3:].lower() == ".py":' in line 64 (Python 2.4.1) or 67 (Python 2.4.2) causes a TypeError: unsubscriptable object because both module and filename are None. The original warning message that would be very helpful gets lost and is replaced by a misterious TypeError that is hard to find unless debugging and stepping into the Python runtime. There would be a simple fix by modifing the assignment in the line above from module = filename to module = filename or "(unknown)" we found also bugtracker entry [ 890010 ] "Odd warning behaviors" that is similar but has a completely different focus. Could someone please fix this problem either with the fix above or something better? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403410&group_id=5470 From noreply at sourceforge.net Thu Jan 12 00:02:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jan 2006 15:02:17 -0800 Subject: [ python-Bugs-1397850 ] libpython2.4.so get not installed Message-ID: Bugs item #1397850, was opened at 2006-01-05 08:01 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1397850&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: hajo (hajoehlers) Assigned to: Nobody/Anonymous (nobody) Summary: libpython2.4.so get not installed Initial Comment: Given: AIX 5.1 GCC 3.3.2 Python 2.4.2 ( Python-2.4.2.tar.gz ) ./configure \ --enable-unicode \ --enable-shared \ --with-gcc \ --mandir=/usr/local/man \ --infodir=/usr/local/info Problem: during " gmake install " the libpython2.4.a will not be installed in /usr/local/lib and the link for libpython2.4.so does not exist then. I did not dig further but below is the output from "gmake install" For me the ... if test -f libpython2.4.so; then ... look wrong because it does not contain a Path and will fail. regards Hajo output during "gmake install" ... if test -f libpython2.4.so; then \^M if test ".so" = .dll; then \^M /opt/freeware/bin/install -c -m 555 libpython2.4.so /usr/local/bin; \^M else \^M /opt/freeware/bin/install -c -m 555 libpython2.4.so /usr/local/lib/libpython2.4.a; \^M if test libpython2.4.so != libpython2.4.a; then \^M (cd /usr/local/lib; ln -sf libpython2.4.a libpython2.4.so); \^M fi \^M fi; \^M else true; \^M ... ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-11 15:02 Message: Logged In: YES user_id=33168 If it's not supported, then I definitely agree we should add the error message you propose. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-01-11 14:55 Message: Logged In: YES user_id=21627 --enable-shared simply isn't supported on AIX. I'm tempted to reject this as "won't fix". If anything should be fixed, we should add *) AC_MSG_ERROR(--enable-shared not supported on this system) ;; to the # Other platforms follow if test $enable_shared = "yes"; then block. ---------------------------------------------------------------------- Comment By: hajo (hajoehlers) Date: 2006-01-10 13:26 Message: Logged In: YES user_id=1420117 Hi Neal if give up to test/fix the configure.in With the help from Ulrich Berning i build a static version and convert these to a shared one. See notes down below. Tnx for supporting Hajo $ cat ./mkshared.python < Bugs item #1379984, was opened at 2005-12-14 00:20 Message generated for change (Comment added) made by blade_doyle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379984&group_id=5470 Please note that this 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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Blade (blade_doyle) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX: Can't shl_load() a library containing Thread Local Initial Comment: HP-UX runtime loader does not support dynamic load of shared libraries that contain (TLS) thread local storage. As a result, when attempting to import modules that contain TLS the following error is reported: "/usr/lib/dld.sl: Can't shl_load() a library containing Thread Local Storage" This problem was discussed previously on the python.org mail list: http://mail.python.org/pipermail/python-list/2003-May/164024.html There is another option: Use LD_PRELOAD environment variable to cuase the runtime loader to 'pre-load' the pthreads library (and dependancies of the pthread library). See the dld.sl(5) man page for more info on LD_PRELOAD. But, I think a 5th option is ideal. If libpthread.sl (and the dependancies of libpthread) are linked into the python executable at build time then all of these problems are avoided. I suggest that the HP-UX (includes hp-ux on ia64) build process be modified so that libpthead (and depends) are linked in. Or, at least, make a note of this problem/solution in the HP-UX section of the README file distributed with python source. Here is the process I use to work around the TLS problem: HP-UX: bash$ BASECFLAGS="-DTHREAD_STACK_SIZE=0x50000"; export BASECFLAGS bash$ ./configure --without-gcc --enable-shared --with-libs='-lpthread -lstd_v2 -lCsup_v2 -lcl' bash$ **Edit the Makefile and remove -O from the OPT line. bash$ make bash$ make test bash$ make install HP-UX on ia64: bash$ CC=cc; export CC bash$ CXX=aCC; export CXX bash$ BASECFLAGS="+DD64 -DTHREAD_STACK_SIZE=0x50000"; export BASECFLAGS bash$ LDFLAGS="+DD64"; export LDFLAGS bash$ ./configure --without-gcc --enable-shared --with-libs="-lpthread -lCsup -lstd_v2 -lunwind" bash$ unset CC bash$ unset CXX bash$ unset BASECFLAGS bash$ unset LDFLAGS bash$ **Edit the Makefile and remove -O from the OPT line. bash$ make bash$ make test bash$ make install ---------------------------------------------------------------------- >Comment By: Blade (blade_doyle) Date: 2006-01-11 23:20 Message: Logged In: YES user_id=1404264 I think so. Please stay tuned. I'll post the patch when I have it ready. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-01-11 22:56 Message: Logged In: YES user_id=21627 Can you provide a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379984&group_id=5470 From noreply at sourceforge.net Thu Jan 12 00:42:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jan 2006 15:42:25 -0800 Subject: [ python-Bugs-1379804 ] HP-UX thread stack size needs to be increased Message-ID: Bugs item #1379804, was opened at 2005-12-13 20:22 Message generated for change (Comment added) made by blade_doyle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379804&group_id=5470 Please note that this 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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Blade (blade_doyle) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX thread stack size needs to be increased Initial Comment: On HP-UX the default thread stack size is "insufficient" and probably needs to be increased if threads are performing any heavy tasks. Obviously, the ideal size depends on you application but I find that THREAD_STACK_SIZE=0x50000 works well for me. Using the default thread stack size my multi-threading tests were failing with a corrupt stack sometimes and this stack trace other times: #0 0x79db8c0c in _isspace+0x2d8 () from /usr/lib/libnss_dns.1 #1 0x7aff62c4 in nss_search+0x28c () from /usr/lib/libc.2 #2 0x7af4d320 in __gethostbyname_r+0x140 () from /usr/lib/libc.2 #3 0x7af4d4bc in gethostbyname+0x94 () from /usr/lib/libc.2 #4 here, I am calling: gethostbyname("localhost") [cut] #23 0x7a8c49ac in OpSession::begin+0x1c0 () from /space/bdoyle/hprisc/lib/oopython.sl #24 0x7aa42660 in PyCFunction_Call+0xc8 () from /space/bdoyle/PythonBinding/Python-2.4.2/libpython2.4.sl [cut] #38 0x7aabbda0 in PyEval_CallObjectWithKeywords+0x1c4 () from /space/bdoyle/PythonBinding/Python-2.4.2/libpython2.4.sl #39 0x7ab17e8c in t_bootstrap+0xa0 () from /space/bdoyle/PythonBinding/Python-2.4.2/libpython2.4.sl #40 0x7ab6400c in __pthread_body+0x44 () from /usr/lib/libpthread.1 #41 0x7ab6e29c in __pthread_start+0x14 () from /usr/lib/libpthread.1 I tested both Python 2.3.4 and 2.4.2 and increased stack size solves the probem on both. I suggest that a note be added to the Python README under the HP-UX section. The note should suggest that the "BASECFLAGS" environment variable be set to include "-DTHREAD_STACK_SIZE=0x50000" prior to running configure. I dont know that 0x50000 is really the ideal stack size..... Blade. ---------------------------------------------------------------------- >Comment By: Blade (blade_doyle) Date: 2006-01-11 23:42 Message: Logged In: YES user_id=1404264 I think I can generate that patch. I'll give a try. I found the patch guidelines for the Python project at http://www.python.org/patches/ so that greatly increases my chances of success! One concern that I have is with the stack size value of "0x50000". I find that there is a wide range of default stack sizes for the various operating systems. There does not seem to be any consensus on a good default value. This quote exemplifies the situation: "On Tru64 UNIX, the default thread stack size increased from 24 KB to 5 MB in Version 5.0. On HP-UX, it is only 64 KB on PA systems and 256 KB on Itanium??-based systems." Quote From: http://devrsrc1.external.hp.com/STKT/impacts/i375.html How can I settle on a stacksize for this patch? Unless there are other suggestions I'll stick with "0x50000" because I have tested that and know it works for what I consider an 'average' application. Thanks, Blade. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-01-11 22:57 Message: Logged In: YES user_id=21627 Can you provide a patch to configure.in that adds this automatically? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379804&group_id=5470 From noreply at sourceforge.net Thu Jan 12 06:40:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 11 Jan 2006 21:40:26 -0800 Subject: [ python-Bugs-1379804 ] HP-UX thread stack size needs to be increased Message-ID: Bugs item #1379804, was opened at 2005-12-13 21:22 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379804&group_id=5470 Please note that this 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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Blade (blade_doyle) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX thread stack size needs to be increased Initial Comment: On HP-UX the default thread stack size is "insufficient" and probably needs to be increased if threads are performing any heavy tasks. Obviously, the ideal size depends on you application but I find that THREAD_STACK_SIZE=0x50000 works well for me. Using the default thread stack size my multi-threading tests were failing with a corrupt stack sometimes and this stack trace other times: #0 0x79db8c0c in _isspace+0x2d8 () from /usr/lib/libnss_dns.1 #1 0x7aff62c4 in nss_search+0x28c () from /usr/lib/libc.2 #2 0x7af4d320 in __gethostbyname_r+0x140 () from /usr/lib/libc.2 #3 0x7af4d4bc in gethostbyname+0x94 () from /usr/lib/libc.2 #4 here, I am calling: gethostbyname("localhost") [cut] #23 0x7a8c49ac in OpSession::begin+0x1c0 () from /space/bdoyle/hprisc/lib/oopython.sl #24 0x7aa42660 in PyCFunction_Call+0xc8 () from /space/bdoyle/PythonBinding/Python-2.4.2/libpython2.4.sl [cut] #38 0x7aabbda0 in PyEval_CallObjectWithKeywords+0x1c4 () from /space/bdoyle/PythonBinding/Python-2.4.2/libpython2.4.sl #39 0x7ab17e8c in t_bootstrap+0xa0 () from /space/bdoyle/PythonBinding/Python-2.4.2/libpython2.4.sl #40 0x7ab6400c in __pthread_body+0x44 () from /usr/lib/libpthread.1 #41 0x7ab6e29c in __pthread_start+0x14 () from /usr/lib/libpthread.1 I tested both Python 2.3.4 and 2.4.2 and increased stack size solves the probem on both. I suggest that a note be added to the Python README under the HP-UX section. The note should suggest that the "BASECFLAGS" environment variable be set to include "-DTHREAD_STACK_SIZE=0x50000" prior to running configure. I dont know that 0x50000 is really the ideal stack size..... Blade. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-01-12 06:40 Message: Logged In: YES user_id=21627 Python has a standard, cross-platform initial recursion limit (sys.getrecursionlimit()). The stacksize should be large enough to accommodate this recursion limit, or else the initial recursionlimit should be decreased on the platform to fit into the default stacksize. If you increase sys.setrecursionlimit, you should be able to overrun the processor stack with a recursive program, so you can find out what recursion depth the standard stack supports. ---------------------------------------------------------------------- Comment By: Blade (blade_doyle) Date: 2006-01-12 00:42 Message: Logged In: YES user_id=1404264 I think I can generate that patch. I'll give a try. I found the patch guidelines for the Python project at http://www.python.org/patches/ so that greatly increases my chances of success! One concern that I have is with the stack size value of "0x50000". I find that there is a wide range of default stack sizes for the various operating systems. There does not seem to be any consensus on a good default value. This quote exemplifies the situation: "On Tru64 UNIX, the default thread stack size increased from 24 KB to 5 MB in Version 5.0. On HP-UX, it is only 64 KB on PA systems and 256 KB on Itanium??-based systems." Quote From: http://devrsrc1.external.hp.com/STKT/impacts/i375.html How can I settle on a stacksize for this patch? Unless there are other suggestions I'll stick with "0x50000" because I have tested that and know it works for what I consider an 'average' application. Thanks, Blade. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-01-11 23:57 Message: Logged In: YES user_id=21627 Can you provide a patch to configure.in that adds this automatically? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379804&group_id=5470 From noreply at sourceforge.net Thu Jan 12 14:24:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jan 2006 05:24:27 -0800 Subject: [ python-Bugs-1403349 ] in email can't get attachments' filenames using get_filename Message-ID: Bugs item #1403349, was opened at 2006-01-11 22:47 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403349&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal P. (mpasniew) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: in email can't get attachments' filenames using get_filename Initial Comment: in the email package (2.4.1) the get_filename() method returns the MIME field "filename" but some messages have 'name' field instead, for example: USUALLY THE HEADER IS: Content-Type: application/octet-stream; name="XX.pdf" Content-Transfer-Encoding: base64 Content-Description: XX.pdf Content-Disposition: attachment; filename="XX.pdf" BUT SOMETIMES THE HEADER IS: Content-type: application/octet-stream; name="XX.xls" Content-transfer-encoding: base64 For this to work properly I had to code a hack along these lines: filename = part.get_filename() if not filename: ct = part.get("Content-type") m = re.compile('name=\"(\S+)\"').search(ct, 1) if m: filename=m.group(1) But it would be helpful to code this in the get_filename() Michal ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403349&group_id=5470 From noreply at sourceforge.net Thu Jan 12 21:59:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jan 2006 12:59:53 -0800 Subject: [ python-Bugs-1404213 ] os.getlogin() goes **poof** Message-ID: Bugs item #1404213, was opened at 2006-01-12 20:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1404213&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jim Wilson (wilson1442) Assigned to: Nobody/Anonymous (nobody) Summary: os.getlogin() goes **poof** Initial Comment: "python -c "import os; getlogin()" rears its ugly head again. It complains it can't open "" (Python 2.4.1, FC4). Strace confirms it: open("", ...) = -1 ENOENT (No such file or ... open("", ...) = -1 ENOENT ... open("/usr/lib/python24.zip/", ...) = -1 ... open("/usr/lib/python2.4/", ...) = -1 ... open("/usr/lib/python2.4/plat-linux2/", ... open("/usr/lib/python2.4/lib-tk/", ... open("/usr/lib/python2.4/lib-dynload/", ... open("/usr/lib/python2.4/site-packages/", ... [/ snipped.] I don't know what's in that "" file, but it surely must be important. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1404213&group_id=5470 From noreply at sourceforge.net Thu Jan 12 22:17:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jan 2006 13:17:03 -0800 Subject: [ python-Bugs-1404213 ] os.getlogin() goes **poof** Message-ID: Bugs item #1404213, was opened at 2006-01-12 20:59 Message generated for change (Comment added) made by wilson1442 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1404213&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jim Wilson (wilson1442) Assigned to: Nobody/Anonymous (nobody) Summary: os.getlogin() goes **poof** Initial Comment: "python -c "import os; getlogin()" rears its ugly head again. It complains it can't open "" (Python 2.4.1, FC4). Strace confirms it: open("", ...) = -1 ENOENT (No such file or ... open("", ...) = -1 ENOENT ... open("/usr/lib/python24.zip/", ...) = -1 ... open("/usr/lib/python2.4/", ...) = -1 ... open("/usr/lib/python2.4/plat-linux2/", ... open("/usr/lib/python2.4/lib-tk/", ... open("/usr/lib/python2.4/lib-dynload/", ... open("/usr/lib/python2.4/site-packages/", ... [/ snipped.] I don't know what's in that "" file, but it surely must be important. ---------------------------------------------------------------------- >Comment By: Jim Wilson (wilson1442) Date: 2006-01-12 21:17 Message: Logged In: YES user_id=1191155 Er... Of course, I intended: python -c "import os; os.getlogin()" diagnostic output was from: strace -e trace=open python -c "import os; os.getlogin()" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1404213&group_id=5470 From noreply at sourceforge.net Thu Jan 12 22:34:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jan 2006 13:34:17 -0800 Subject: [ python-Bugs-1404213 ] os.getlogin() goes **poof** Message-ID: Bugs item #1404213, was opened at 2006-01-12 21:59 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1404213&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jim Wilson (wilson1442) Assigned to: Nobody/Anonymous (nobody) Summary: os.getlogin() goes **poof** Initial Comment: "python -c "import os; getlogin()" rears its ugly head again. It complains it can't open "" (Python 2.4.1, FC4). Strace confirms it: open("", ...) = -1 ENOENT (No such file or ... open("", ...) = -1 ENOENT ... open("/usr/lib/python24.zip/", ...) = -1 ... open("/usr/lib/python2.4/", ...) = -1 ... open("/usr/lib/python2.4/plat-linux2/", ... open("/usr/lib/python2.4/lib-tk/", ... open("/usr/lib/python2.4/lib-dynload/", ... open("/usr/lib/python2.4/site-packages/", ... [/ snipped.] I don't know what's in that "" file, but it surely must be important. ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-12 22:34 Message: Logged In: YES user_id=1188172 Your diagnosis is incorrect. The system's getlogin() sets errno 2, that is "No such file or directory". Thus os.getlogin() raises an OSError with this description. Python's "file name" for -c scripts is "", and because Python wants to give you a traceback with lines and code context, it looks for the file "". This has nothing to do with getlogin. ---------------------------------------------------------------------- Comment By: Jim Wilson (wilson1442) Date: 2006-01-12 22:17 Message: Logged In: YES user_id=1191155 Er... Of course, I intended: python -c "import os; os.getlogin()" diagnostic output was from: strace -e trace=open python -c "import os; os.getlogin()" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1404213&group_id=5470 From noreply at sourceforge.net Thu Jan 12 22:58:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jan 2006 13:58:39 -0800 Subject: [ python-Bugs-1404213 ] os.getlogin() goes **poof** Message-ID: Bugs item #1404213, was opened at 2006-01-12 20:59 Message generated for change (Comment added) made by wilson1442 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1404213&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Jim Wilson (wilson1442) Assigned to: Nobody/Anonymous (nobody) Summary: os.getlogin() goes **poof** Initial Comment: "python -c "import os; getlogin()" rears its ugly head again. It complains it can't open "" (Python 2.4.1, FC4). Strace confirms it: open("", ...) = -1 ENOENT (No such file or ... open("", ...) = -1 ENOENT ... open("/usr/lib/python24.zip/", ...) = -1 ... open("/usr/lib/python2.4/", ...) = -1 ... open("/usr/lib/python2.4/plat-linux2/", ... open("/usr/lib/python2.4/lib-tk/", ... open("/usr/lib/python2.4/lib-dynload/", ... open("/usr/lib/python2.4/site-packages/", ... [/ snipped.] I don't know what's in that "" file, but it surely must be important. ---------------------------------------------------------------------- >Comment By: Jim Wilson (wilson1442) Date: 2006-01-12 21:58 Message: Logged In: YES user_id=1191155 Actually, my diagnosis was meant to be jocular. I don't have a clue what's happening. Someone else suggested using strace when this problem was reported earlier. Your explanation makes perfect sense. But ... that certainly narrows it down. If it ain't "os.getlogin()", that leaves only "import os;", right? ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-12 21:34 Message: Logged In: YES user_id=1188172 Your diagnosis is incorrect. The system's getlogin() sets errno 2, that is "No such file or directory". Thus os.getlogin() raises an OSError with this description. Python's "file name" for -c scripts is "", and because Python wants to give you a traceback with lines and code context, it looks for the file "". This has nothing to do with getlogin. ---------------------------------------------------------------------- Comment By: Jim Wilson (wilson1442) Date: 2006-01-12 21:17 Message: Logged In: YES user_id=1191155 Er... Of course, I intended: python -c "import os; os.getlogin()" diagnostic output was from: strace -e trace=open python -c "import os; os.getlogin()" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1404213&group_id=5470 From noreply at sourceforge.net Thu Jan 12 23:10:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jan 2006 14:10:00 -0800 Subject: [ python-Bugs-1404213 ] os.getlogin() goes **poof** Message-ID: Bugs item #1404213, was opened at 2006-01-12 21:59 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1404213&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Jim Wilson (wilson1442) Assigned to: Nobody/Anonymous (nobody) Summary: os.getlogin() goes **poof** Initial Comment: "python -c "import os; getlogin()" rears its ugly head again. It complains it can't open "" (Python 2.4.1, FC4). Strace confirms it: open("", ...) = -1 ENOENT (No such file or ... open("", ...) = -1 ENOENT ... open("/usr/lib/python24.zip/", ...) = -1 ... open("/usr/lib/python2.4/", ...) = -1 ... open("/usr/lib/python2.4/plat-linux2/", ... open("/usr/lib/python2.4/lib-tk/", ... open("/usr/lib/python2.4/lib-dynload/", ... open("/usr/lib/python2.4/site-packages/", ... [/ snipped.] I don't know what's in that "" file, but it surely must be important. ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-12 23:10 Message: Logged In: YES user_id=1188172 It is os.getlogin(), but the search for doesn't have to do anything with it. As for why getlogin() is failing, consult your local manpage for details what getlogin() is doing (wrong). ---------------------------------------------------------------------- Comment By: Jim Wilson (wilson1442) Date: 2006-01-12 22:58 Message: Logged In: YES user_id=1191155 Actually, my diagnosis was meant to be jocular. I don't have a clue what's happening. Someone else suggested using strace when this problem was reported earlier. Your explanation makes perfect sense. But ... that certainly narrows it down. If it ain't "os.getlogin()", that leaves only "import os;", right? ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-12 22:34 Message: Logged In: YES user_id=1188172 Your diagnosis is incorrect. The system's getlogin() sets errno 2, that is "No such file or directory". Thus os.getlogin() raises an OSError with this description. Python's "file name" for -c scripts is "", and because Python wants to give you a traceback with lines and code context, it looks for the file "". This has nothing to do with getlogin. ---------------------------------------------------------------------- Comment By: Jim Wilson (wilson1442) Date: 2006-01-12 22:17 Message: Logged In: YES user_id=1191155 Er... Of course, I intended: python -c "import os; os.getlogin()" diagnostic output was from: strace -e trace=open python -c "import os; os.getlogin()" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1404213&group_id=5470 From noreply at sourceforge.net Thu Jan 12 23:11:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jan 2006 14:11:51 -0800 Subject: [ python-Bugs-1404213 ] os.getlogin() goes **poof** Message-ID: Bugs item #1404213, was opened at 2006-01-12 20:59 Message generated for change (Comment added) made by wilson1442 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1404213&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Jim Wilson (wilson1442) Assigned to: Nobody/Anonymous (nobody) Summary: os.getlogin() goes **poof** Initial Comment: "python -c "import os; getlogin()" rears its ugly head again. It complains it can't open "" (Python 2.4.1, FC4). Strace confirms it: open("", ...) = -1 ENOENT (No such file or ... open("", ...) = -1 ENOENT ... open("/usr/lib/python24.zip/", ...) = -1 ... open("/usr/lib/python2.4/", ...) = -1 ... open("/usr/lib/python2.4/plat-linux2/", ... open("/usr/lib/python2.4/lib-tk/", ... open("/usr/lib/python2.4/lib-dynload/", ... open("/usr/lib/python2.4/site-packages/", ... [/ snipped.] I don't know what's in that "" file, but it surely must be important. ---------------------------------------------------------------------- >Comment By: Jim Wilson (wilson1442) Date: 2006-01-12 22:11 Message: Logged In: YES user_id=1191155 OK. Skip it. I "man getlogin()", and sure enough, it can ENOENT "when there's no entry in the utmp-file" (whatever the hell that is). It looks like getlogin() is sufficiently broken that it should never be used. Thanks for the guidance. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-12 22:10 Message: Logged In: YES user_id=1188172 It is os.getlogin(), but the search for doesn't have to do anything with it. As for why getlogin() is failing, consult your local manpage for details what getlogin() is doing (wrong). ---------------------------------------------------------------------- Comment By: Jim Wilson (wilson1442) Date: 2006-01-12 21:58 Message: Logged In: YES user_id=1191155 Actually, my diagnosis was meant to be jocular. I don't have a clue what's happening. Someone else suggested using strace when this problem was reported earlier. Your explanation makes perfect sense. But ... that certainly narrows it down. If it ain't "os.getlogin()", that leaves only "import os;", right? ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-12 21:34 Message: Logged In: YES user_id=1188172 Your diagnosis is incorrect. The system's getlogin() sets errno 2, that is "No such file or directory". Thus os.getlogin() raises an OSError with this description. Python's "file name" for -c scripts is "", and because Python wants to give you a traceback with lines and code context, it looks for the file "". This has nothing to do with getlogin. ---------------------------------------------------------------------- Comment By: Jim Wilson (wilson1442) Date: 2006-01-12 21:17 Message: Logged In: YES user_id=1191155 Er... Of course, I intended: python -c "import os; os.getlogin()" diagnostic output was from: strace -e trace=open python -c "import os; os.getlogin()" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1404213&group_id=5470 From noreply at sourceforge.net Fri Jan 13 01:25:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jan 2006 16:25:58 -0800 Subject: [ python-Bugs-1396543 ] urlparse is confused by / Message-ID: Bugs item #1396543, was opened at 2006-01-04 05:57 Message generated for change (Comment added) made by pterk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396543&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John Hansen (johnhansen) Assigned to: Nobody/Anonymous (nobody) Summary: urlparse is confused by / Initial Comment: If the parameter field of a URL contains a '/', urlparse does not enter date in the parameter field, but leaves it attached to the path. The simplified example is: >>> urlparse.urlparse("http://f/adi;s=a;c=b/") ('http', 'f', '/adi;s=a;c=b/', '', '', '') >>> urlparse.urlparse("http://f/adi;s=a;c=b") ('http', 'f', '/adi', 's=a;c=b', '', '') The realworld case was: >>> urlparse.urlparse("http://ad.doubleclick.net/adi/ N3691.VibrantMedia/B1733031.2;sz=160x600;click=http%3A/ adforce.adtech.de/adlink%7C82%7C59111%7C1%7C168%7CAdId% 3D1023327%3BBnId%3D4%3Bitime%3D335264036%3Bku%3D12900% 3Bkey%3Dcomputing%2Bbetanews%5Fgeneral%3Blink%3D") (''http'', 'ad.doubleclick.net/adi/N3691.VibrantMedia/ B1733031.2;sz=160x600;click=http%3A/adforce.adtech.de/adlink% 7C82%7C59111%7C1%7C168%7CAdId%3D1023327%3BBnId%3D4%3Bitime %3D335264036%3Bku%3D12900%3Bkey%3Dcomputing%2Bbetanews% 5Fgeneral%3Blink%3D', '', '', '') What's odd is that the code specifically says to do this: def _splitparams(url): if '/' in url: i = url.find(';', url.rfind('/')) if i < 0: return url, '' Is there a reason for the rfind? ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2006-01-13 01:25 Message: Logged In: YES user_id=174455 Looking at the testcases it appears the answers must be in rfc's 1808 or 2396. http://www.ietf.org/rfc/rfc1808.txt and http://www.ietf.org/rfc/rfc2396.txt See for example section 5.3 of 1808. I don't see why _splitparams does what is does but I didn't exactly close-read the text either. Also be sure to look at Lib/test/test_urlparse.py. ---------------------------------------------------------------------- Comment By: John Hansen (johnhansen) Date: 2006-01-04 17:31 Message: Logged In: YES user_id=1418831 The first line should have read: If the parameter field of a URL contains a '/', urlparse does not enter it into the parameter field, but leaves it attached to the path. ---------------------------------------------------------------------- Comment By: John Hansen (johnhansen) Date: 2006-01-04 06:00 Message: Logged In: YES user_id=1418831 The first line should have read: If the parameter field of a URL contains a '/', urlparse does not enter it into the parameter field, but leaves it attached to the path. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396543&group_id=5470 From noreply at sourceforge.net Fri Jan 13 01:39:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jan 2006 16:39:13 -0800 Subject: [ python-Bugs-1403410 ] TypeError unsubscriptable object caused by warnings.py Message-ID: Bugs item #1403410, was opened at 2006-01-12 00:01 Message generated for change (Comment added) made by pterk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403410&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: FreyP (freyp_haufe) Assigned to: Nobody/Anonymous (nobody) Summary: TypeError unsubscriptable object caused by warnings.py Initial Comment: We recently hit a problem with use of Python 2.4 under Zope. #The problem is that warnings.py expects that function warn_explicit is called with either module or filename beeing a string. This is not always true, especially when the warning is caused by a Python script, e.g. a non-ASCII character without encoding declaration causing a "Non-ASCII character ... in file ... on line ..., but no encoding declared; see ..." the slice operation 'if module[-3:].lower() == ".py":' in line 64 (Python 2.4.1) or 67 (Python 2.4.2) causes a TypeError: unsubscriptable object because both module and filename are None. The original warning message that would be very helpful gets lost and is replaced by a misterious TypeError that is hard to find unless debugging and stepping into the Python runtime. There would be a simple fix by modifing the assignment in the line above from module = filename to module = filename or "(unknown)" we found also bugtracker entry [ 890010 ] "Odd warning behaviors" that is similar but has a completely different focus. Could someone please fix this problem either with the fix above or something better? ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2006-01-13 01:39 Message: Logged In: YES user_id=174455 See patch: 1404357 http://sourceforge.net/tracker/index.php?func=detail&aid=1404357&group_id=5470&atid=305470 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403410&group_id=5470 From noreply at sourceforge.net Fri Jan 13 02:01:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 12 Jan 2006 17:01:31 -0800 Subject: [ python-Bugs-1394565 ] SimpleHTTPServer doesn't understand query arguments Message-ID: Bugs item #1394565, was opened at 2005-12-31 22:46 Message generated for change (Comment added) made by pterk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394565&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Aaron Swartz (aaronsw) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleHTTPServer doesn't understand query arguments Initial Comment: If you set the SimpleHTTPServer to serve files and visit /filename it works but if you visit /filename?f=1 it returns a 404. It should strip off the query argument and visit /filename ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2006-01-13 02:01 Message: Logged In: YES user_id=174455 See patch 1404374 http://sourceforge.net/tracker/index.php?func=detail&aid=1404374&group_id=5470&atid=305470 (uses urlparse to cover (i.e. ignore) params as well) ---------------------------------------------------------------------- Comment By: Aaron Swartz (aaronsw) Date: 2006-01-05 16:45 Message: Logged In: YES user_id=122141 The patch is to add this line to the top of SimpleHTTPServer.py's translate_path function: path = path.split('?')[0] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394565&group_id=5470 From noreply at sourceforge.net Fri Jan 13 16:25:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jan 2006 07:25:18 -0800 Subject: [ python-Feature Requests-1404859 ] friendly quit object Message-ID: Feature Requests item #1404859, was opened at 2006-01-13 10:25 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=1404859&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: friendly quit object Initial Comment: Today, there is no cross-platform way to quit. Today, typing quit returns a message that suggests the interpreter is willfully disobeying you. Instead, change the quit object to one whose __call__ will exit, and whose __str__ says something like """ quit() exits the interpreter, by calling this quit object. """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1404859&group_id=5470 From noreply at sourceforge.net Fri Jan 13 16:26:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jan 2006 07:26:26 -0800 Subject: [ python-Feature Requests-1404859 ] friendly quit object Message-ID: Feature Requests item #1404859, was opened at 2006-01-13 10:25 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1404859&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: friendly quit object Initial Comment: Today, there is no cross-platform way to quit. Today, typing quit returns a message that suggests the interpreter is willfully disobeying you. Instead, change the quit object to one whose __call__ will exit, and whose __str__ says something like """ quit() exits the interpreter, by calling this quit object. """ ---------------------------------------------------------------------- >Comment By: Jim Jewett (jimjjewett) Date: 2006-01-13 10:26 Message: Logged In: YES user_id=764593 Rewording welcome; the point is that it should explain *why* it can't just exit immediately, unless it is explicitly called. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1404859&group_id=5470 From noreply at sourceforge.net Fri Jan 13 17:05:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jan 2006 08:05:32 -0800 Subject: [ python-Bugs-1404925 ] subprocess.Popen inside thread locks the thread in some case Message-ID: Bugs item #1404925, was opened at 2006-01-13 17: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=1404925&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Toon Verstraelen (tovrstra) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.Popen inside thread locks the thread in some case Initial Comment: The bug can be verified with the example program attached to this bugs. Two files are attached: my_thread.py and main.py When main.py is executed the thread hangs on subprocess.Popen, while my_thread.py, which is imported by main.py runs without problems. In fact both should do exactly the same since main.py doesn nothing but importing my_thread. My python version: Python 2.4.2 (#1, Oct 17 2005, 09:05:20) [GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on linux2 If any more info is required, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1404925&group_id=5470 From noreply at sourceforge.net Fri Jan 13 17:14:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jan 2006 08:14:28 -0800 Subject: [ python-Bugs-1390086 ] ScrolledText hungs up in some conditions Message-ID: Bugs item #1390086, was opened at 2005-12-25 16:06 Message generated for change (Comment added) made by tovrstra You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390086&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: dani_filth (dani_filth) Assigned to: Nobody/Anonymous (nobody) Summary: ScrolledText hungs up in some conditions Initial Comment: The next code causes Python to hung in some conditions : #------------------------------------------------------ from ScrolledText import * root=Tk() ScrolledText(root, bg='white').pack(fill=BOTH, expand=YES) root.mainloop() #------------------------------------------------------ Run the script. Pass focus to the text field. Then enter one Tab and type several letters. After that with having pushed Ctrl-key press several times UP button. Script hungs with 100% CPU-usage. P.S. My config : WinXP sp2, python 2.4.2 ---------------------------------------------------------------------- Comment By: Toon Verstraelen (tovrstra) Date: 2006-01-13 17:14 Message: Logged In: YES user_id=970944 I could verify this bug. My configuration is quite different: Python 2.4.2 (#1, Oct 17 2005, 09:05:20) [GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on linux2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390086&group_id=5470 From noreply at sourceforge.net Fri Jan 13 17:30:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jan 2006 08:30:52 -0800 Subject: [ python-Bugs-1404925 ] subprocess.Popen inside thread locks the thread in some case Message-ID: Bugs item #1404925, was opened at 2006-01-13 17:05 Message generated for change (Comment added) made by titty You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1404925&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Toon Verstraelen (tovrstra) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.Popen inside thread locks the thread in some case Initial Comment: The bug can be verified with the example program attached to this bugs. Two files are attached: my_thread.py and main.py When main.py is executed the thread hangs on subprocess.Popen, while my_thread.py, which is imported by main.py runs without problems. In fact both should do exactly the same since main.py doesn nothing but importing my_thread. My python version: Python 2.4.2 (#1, Oct 17 2005, 09:05:20) [GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on linux2 If any more info is required, ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2006-01-13 17:30 Message: Logged In: YES user_id=17929 I cannot reproduce this error on ubuntu linux using python 2.4.2. However, I am able to reproduce it using python 2.4.2 running on FreeBSD 4.11. Stopping the program with ctrl-c results in the following output: ralf at stronzo:~/tmp$ python main.py before Popen ^CException in thread Thread-1: Traceback (most recent call last): File "/usr/local/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "/home/ralf/tmp/my_thread.py", line 7, in run sp = Popen(["ls", "-al"], stdout=PIPE, stderr=STDOUT) File "/usr/local/lib/python2.4/subprocess.py", line 542, in __init__ errread, errwrite) File "/usr/local/lib/python2.4/subprocess.py", line 970, in _execute_child data = os.read(errpipe_read, 1048576) # Exceptions limited to 1 MB OSError: [Errno 4] Interrupted system call Error in atexit._run_exitfuncs: Traceback (most recent call last): File "/usr/local/lib/python2.4/atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "/usr/local/lib/python2.4/threading.py", line 632, in __exitfunc t.join() File "/usr/local/lib/python2.4/threading.py", line 539, in join self.__block.wait() File "/usr/local/lib/python2.4/threading.py", line 203, in wait waiter.acquire() KeyboardInterrupt Error in sys.exitfunc: Traceback (most recent call last): File "/usr/local/lib/python2.4/atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "/usr/local/lib/python2.4/threading.py", line 632, in __exitfunc t.join() File "/usr/local/lib/python2.4/threading.py", line 539, in join self.__block.wait() File "/usr/local/lib/python2.4/threading.py", line 203, in wait waiter.acquire() KeyboardInterrupt ralf at stronzo:~/tmp$ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1404925&group_id=5470 From noreply at sourceforge.net Fri Jan 13 17:48:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jan 2006 08:48:29 -0800 Subject: [ python-Bugs-1404925 ] subprocess.Popen inside thread locks the thread in some case Message-ID: Bugs item #1404925, was opened at 2006-01-13 17:05 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1404925&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Toon Verstraelen (tovrstra) >Assigned to: Peter ?strand (astrand) Summary: subprocess.Popen inside thread locks the thread in some case Initial Comment: The bug can be verified with the example program attached to this bugs. Two files are attached: my_thread.py and main.py When main.py is executed the thread hangs on subprocess.Popen, while my_thread.py, which is imported by main.py runs without problems. In fact both should do exactly the same since main.py doesn nothing but importing my_thread. My python version: Python 2.4.2 (#1, Oct 17 2005, 09:05:20) [GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on linux2 If any more info is required, ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2006-01-13 17:30 Message: Logged In: YES user_id=17929 I cannot reproduce this error on ubuntu linux using python 2.4.2. However, I am able to reproduce it using python 2.4.2 running on FreeBSD 4.11. Stopping the program with ctrl-c results in the following output: ralf at stronzo:~/tmp$ python main.py before Popen ^CException in thread Thread-1: Traceback (most recent call last): File "/usr/local/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "/home/ralf/tmp/my_thread.py", line 7, in run sp = Popen(["ls", "-al"], stdout=PIPE, stderr=STDOUT) File "/usr/local/lib/python2.4/subprocess.py", line 542, in __init__ errread, errwrite) File "/usr/local/lib/python2.4/subprocess.py", line 970, in _execute_child data = os.read(errpipe_read, 1048576) # Exceptions limited to 1 MB OSError: [Errno 4] Interrupted system call Error in atexit._run_exitfuncs: Traceback (most recent call last): File "/usr/local/lib/python2.4/atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "/usr/local/lib/python2.4/threading.py", line 632, in __exitfunc t.join() File "/usr/local/lib/python2.4/threading.py", line 539, in join self.__block.wait() File "/usr/local/lib/python2.4/threading.py", line 203, in wait waiter.acquire() KeyboardInterrupt Error in sys.exitfunc: Traceback (most recent call last): File "/usr/local/lib/python2.4/atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "/usr/local/lib/python2.4/threading.py", line 632, in __exitfunc t.join() File "/usr/local/lib/python2.4/threading.py", line 539, in join self.__block.wait() File "/usr/local/lib/python2.4/threading.py", line 203, in wait waiter.acquire() KeyboardInterrupt ralf at stronzo:~/tmp$ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1404925&group_id=5470 From noreply at sourceforge.net Fri Jan 13 17:54:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jan 2006 08:54:41 -0800 Subject: [ python-Bugs-1390086 ] ScrolledText hungs up in some conditions Message-ID: Bugs item #1390086, was opened at 2005-12-25 16:06 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390086&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: dani_filth (dani_filth) >Assigned to: Martin v. L??wis (loewis) Summary: ScrolledText hungs up in some conditions Initial Comment: The next code causes Python to hung in some conditions : #------------------------------------------------------ from ScrolledText import * root=Tk() ScrolledText(root, bg='white').pack(fill=BOTH, expand=YES) root.mainloop() #------------------------------------------------------ Run the script. Pass focus to the text field. Then enter one Tab and type several letters. After that with having pushed Ctrl-key press several times UP button. Script hungs with 100% CPU-usage. P.S. My config : WinXP sp2, python 2.4.2 ---------------------------------------------------------------------- Comment By: Toon Verstraelen (tovrstra) Date: 2006-01-13 17:14 Message: Logged In: YES user_id=970944 I could verify this bug. My configuration is quite different: Python 2.4.2 (#1, Oct 17 2005, 09:05:20) [GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on linux2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390086&group_id=5470 From noreply at sourceforge.net Fri Jan 13 17:58:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jan 2006 08:58:08 -0800 Subject: [ python-Bugs-1404925 ] subprocess.Popen inside thread locks the thread in some case Message-ID: Bugs item #1404925, was opened at 2006-01-13 17:05 Message generated for change (Comment added) made by tovrstra You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1404925&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Toon Verstraelen (tovrstra) Assigned to: Peter ?strand (astrand) Summary: subprocess.Popen inside thread locks the thread in some case Initial Comment: The bug can be verified with the example program attached to this bugs. Two files are attached: my_thread.py and main.py When main.py is executed the thread hangs on subprocess.Popen, while my_thread.py, which is imported by main.py runs without problems. In fact both should do exactly the same since main.py doesn nothing but importing my_thread. My python version: Python 2.4.2 (#1, Oct 17 2005, 09:05:20) [GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on linux2 If any more info is required, ---------------------------------------------------------------------- >Comment By: Toon Verstraelen (tovrstra) Date: 2006-01-13 17:58 Message: Logged In: YES user_id=970944 What version of glibc do you have on your ubuntu system? I have glibc-2.3.5-r2, where r2 stands for second patch revision from the gentoo distribution. In my case I can not interrupt 'python main.py'. I have to use ctrl-z and then 'kill %1'. ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2006-01-13 17:30 Message: Logged In: YES user_id=17929 I cannot reproduce this error on ubuntu linux using python 2.4.2. However, I am able to reproduce it using python 2.4.2 running on FreeBSD 4.11. Stopping the program with ctrl-c results in the following output: ralf at stronzo:~/tmp$ python main.py before Popen ^CException in thread Thread-1: Traceback (most recent call last): File "/usr/local/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "/home/ralf/tmp/my_thread.py", line 7, in run sp = Popen(["ls", "-al"], stdout=PIPE, stderr=STDOUT) File "/usr/local/lib/python2.4/subprocess.py", line 542, in __init__ errread, errwrite) File "/usr/local/lib/python2.4/subprocess.py", line 970, in _execute_child data = os.read(errpipe_read, 1048576) # Exceptions limited to 1 MB OSError: [Errno 4] Interrupted system call Error in atexit._run_exitfuncs: Traceback (most recent call last): File "/usr/local/lib/python2.4/atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "/usr/local/lib/python2.4/threading.py", line 632, in __exitfunc t.join() File "/usr/local/lib/python2.4/threading.py", line 539, in join self.__block.wait() File "/usr/local/lib/python2.4/threading.py", line 203, in wait waiter.acquire() KeyboardInterrupt Error in sys.exitfunc: Traceback (most recent call last): File "/usr/local/lib/python2.4/atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "/usr/local/lib/python2.4/threading.py", line 632, in __exitfunc t.join() File "/usr/local/lib/python2.4/threading.py", line 539, in join self.__block.wait() File "/usr/local/lib/python2.4/threading.py", line 203, in wait waiter.acquire() KeyboardInterrupt ralf at stronzo:~/tmp$ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1404925&group_id=5470 From noreply at sourceforge.net Fri Jan 13 18:01:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jan 2006 09:01:22 -0800 Subject: [ python-Bugs-1403410 ] TypeError unsubscriptable object caused by warnings.py Message-ID: Bugs item #1403410, was opened at 2006-01-12 00:01 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403410&group_id=5470 Please note that this message will contain 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 Submitted By: FreyP (freyp_haufe) Assigned to: Nobody/Anonymous (nobody) Summary: TypeError unsubscriptable object caused by warnings.py Initial Comment: We recently hit a problem with use of Python 2.4 under Zope. #The problem is that warnings.py expects that function warn_explicit is called with either module or filename beeing a string. This is not always true, especially when the warning is caused by a Python script, e.g. a non-ASCII character without encoding declaration causing a "Non-ASCII character ... in file ... on line ..., but no encoding declared; see ..." the slice operation 'if module[-3:].lower() == ".py":' in line 64 (Python 2.4.1) or 67 (Python 2.4.2) causes a TypeError: unsubscriptable object because both module and filename are None. The original warning message that would be very helpful gets lost and is replaced by a misterious TypeError that is hard to find unless debugging and stepping into the Python runtime. There would be a simple fix by modifing the assignment in the line above from module = filename to module = filename or "(unknown)" we found also bugtracker entry [ 890010 ] "Odd warning behaviors" that is similar but has a completely different focus. Could someone please fix this problem either with the fix above or something better? ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-13 18:01 Message: Logged In: YES user_id=1188172 Committed patch as revisions 42028,42029. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2006-01-13 01:39 Message: Logged In: YES user_id=174455 See patch: 1404357 http://sourceforge.net/tracker/index.php?func=detail&aid=1404357&group_id=5470&atid=305470 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403410&group_id=5470 From noreply at sourceforge.net Fri Jan 13 18:08:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jan 2006 09:08:55 -0800 Subject: [ python-Bugs-1394565 ] SimpleHTTPServer doesn't understand query arguments Message-ID: Bugs item #1394565, was opened at 2005-12-31 22:46 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394565&group_id=5470 Please note that this message will contain 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 Submitted By: Aaron Swartz (aaronsw) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleHTTPServer doesn't understand query arguments Initial Comment: If you set the SimpleHTTPServer to serve files and visit /filename it works but if you visit /filename?f=1 it returns a 404. It should strip off the query argument and visit /filename ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-13 18:08 Message: Logged In: YES user_id=1188172 Committed patch in revisions 42030,42031. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2006-01-13 02:01 Message: Logged In: YES user_id=174455 See patch 1404374 http://sourceforge.net/tracker/index.php?func=detail&aid=1404374&group_id=5470&atid=305470 (uses urlparse to cover (i.e. ignore) params as well) ---------------------------------------------------------------------- Comment By: Aaron Swartz (aaronsw) Date: 2006-01-05 16:45 Message: Logged In: YES user_id=122141 The patch is to add this line to the top of SimpleHTTPServer.py's translate_path function: path = path.split('?')[0] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394565&group_id=5470 From noreply at sourceforge.net Fri Jan 13 18:19:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jan 2006 09:19:06 -0800 Subject: [ python-Bugs-1403068 ] cannot import extension module with Purify Message-ID: Bugs item #1403068, was opened at 2006-01-11 17:02 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403068&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Amaury Forgeot d'Arc (amauryf) >Assigned to: Martin v. L??wis (loewis) Summary: cannot import extension module with Purify Initial Comment: When run with Purify, Python cannot load any extension module. Here is a typical output: Starting Purify'd application... Python 2.4.2 (#46, Jan 3 2006, 16:05:11) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import socket Traceback (most recent call last): File "", line 1, in ? File "c:\python\lib\socket.py", line 45, in ? import _socket ImportError: Module use of python24__d$Purify_c_python.dll conflicts with this version of Python. It reproduces with python 2.4.2 and 2.5a0. It works with python 2.3.3. ---------------------------------------------------------------------- Comment By: Amaury Forgeot d'Arc (amauryf) Date: 2006-01-11 17:35 Message: Logged In: YES user_id=389140 The root cause it that Purify renames all DLLs with names like "python24__d$Purify_c_python.dll". With python 2.3, this name was not taken as the python DLL, and no check was performed. The broken logic in my previous comment changed this for 2.4. A more correct fix is to get the python DLL name from the current process, using GetModuleName(PyWin_DLLhModule). ---------------------------------------------------------------------- Comment By: Amaury Forgeot d'Arc (amauryf) Date: 2006-01-11 17:22 Message: Logged In: YES user_id=389140 The pb seems to be in dynload_win.c, line 136: while (*pch && pch[0] != '_' && pch[1] != 'd' && pch[2] != '.') { This means that if a .pyd has "python_something.dll" in its import table, it will be taken as THE python DLL. I think the line should be: while (*pch && (pch[0] != '_' || pch[1] != 'd' || pch[2] != '.')) { ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403068&group_id=5470 From noreply at sourceforge.net Fri Jan 13 18:24:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jan 2006 09:24:02 -0800 Subject: [ python-Bugs-837242 ] id() for large ptr should return a long Message-ID: Bugs item #837242, was opened at 2003-11-06 16:11 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837242&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: id() for large ptr should return a long Initial Comment: Under something like Redhat 10 the address space is messed about with to "prevent stack smash attacks" or some such. This means that you sometimes get addresses in the high half of a 32 bit int. Since Python ints are signed, this means we return a negative number from id(). For 2.4, we should probably return a long. ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-13 18:24 Message: Logged In: YES user_id=1188172 You're making changes to PyLong_FromVoidPtr, doesn't PyLong_AsVoidPtr have to be changed too? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-01-11 23:39 Message: Logged In: YES user_id=21627 How about the attached patch? ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 23:21 Message: Logged In: YES user_id=1188172 Perhaps, for 2.5? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2003-11-06 21:54 Message: Logged In: YES user_id=21627 Would there anything be wrong with making that change right away? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837242&group_id=5470 From noreply at sourceforge.net Fri Jan 13 18:41:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jan 2006 09:41:14 -0800 Subject: [ python-Bugs-1404925 ] subprocess.Popen inside thread locks the thread in some case Message-ID: Bugs item #1404925, was opened at 2006-01-13 17:05 Message generated for change (Comment added) made by titty You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1404925&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Toon Verstraelen (tovrstra) Assigned to: Peter ?strand (astrand) Summary: subprocess.Popen inside thread locks the thread in some case Initial Comment: The bug can be verified with the example program attached to this bugs. Two files are attached: my_thread.py and main.py When main.py is executed the thread hangs on subprocess.Popen, while my_thread.py, which is imported by main.py runs without problems. In fact both should do exactly the same since main.py doesn nothing but importing my_thread. My python version: Python 2.4.2 (#1, Oct 17 2005, 09:05:20) [GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on linux2 If any more info is required, ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2006-01-13 18:41 Message: Logged In: YES user_id=17929 glibc version 2.3.5. If I add a time.sleep(1) at the end of my_thread.py I can also reproduce this error reliably on ubuntu. ---------------------------------------------------------------------- Comment By: Toon Verstraelen (tovrstra) Date: 2006-01-13 17:58 Message: Logged In: YES user_id=970944 What version of glibc do you have on your ubuntu system? I have glibc-2.3.5-r2, where r2 stands for second patch revision from the gentoo distribution. In my case I can not interrupt 'python main.py'. I have to use ctrl-z and then 'kill %1'. ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2006-01-13 17:30 Message: Logged In: YES user_id=17929 I cannot reproduce this error on ubuntu linux using python 2.4.2. However, I am able to reproduce it using python 2.4.2 running on FreeBSD 4.11. Stopping the program with ctrl-c results in the following output: ralf at stronzo:~/tmp$ python main.py before Popen ^CException in thread Thread-1: Traceback (most recent call last): File "/usr/local/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "/home/ralf/tmp/my_thread.py", line 7, in run sp = Popen(["ls", "-al"], stdout=PIPE, stderr=STDOUT) File "/usr/local/lib/python2.4/subprocess.py", line 542, in __init__ errread, errwrite) File "/usr/local/lib/python2.4/subprocess.py", line 970, in _execute_child data = os.read(errpipe_read, 1048576) # Exceptions limited to 1 MB OSError: [Errno 4] Interrupted system call Error in atexit._run_exitfuncs: Traceback (most recent call last): File "/usr/local/lib/python2.4/atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "/usr/local/lib/python2.4/threading.py", line 632, in __exitfunc t.join() File "/usr/local/lib/python2.4/threading.py", line 539, in join self.__block.wait() File "/usr/local/lib/python2.4/threading.py", line 203, in wait waiter.acquire() KeyboardInterrupt Error in sys.exitfunc: Traceback (most recent call last): File "/usr/local/lib/python2.4/atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "/usr/local/lib/python2.4/threading.py", line 632, in __exitfunc t.join() File "/usr/local/lib/python2.4/threading.py", line 539, in join self.__block.wait() File "/usr/local/lib/python2.4/threading.py", line 203, in wait waiter.acquire() KeyboardInterrupt ralf at stronzo:~/tmp$ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1404925&group_id=5470 From noreply at sourceforge.net Fri Jan 13 19:19:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jan 2006 10:19:28 -0800 Subject: [ python-Bugs-1396543 ] urlparse is confused by / Message-ID: Bugs item #1396543, was opened at 2006-01-04 04:57 Message generated for change (Comment added) made by johnhansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396543&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John Hansen (johnhansen) Assigned to: Nobody/Anonymous (nobody) Summary: urlparse is confused by / Initial Comment: If the parameter field of a URL contains a '/', urlparse does not enter date in the parameter field, but leaves it attached to the path. The simplified example is: >>> urlparse.urlparse("http://f/adi;s=a;c=b/") ('http', 'f', '/adi;s=a;c=b/', '', '', '') >>> urlparse.urlparse("http://f/adi;s=a;c=b") ('http', 'f', '/adi', 's=a;c=b', '', '') The realworld case was: >>> urlparse.urlparse("http://ad.doubleclick.net/adi/ N3691.VibrantMedia/B1733031.2;sz=160x600;click=http%3A/ adforce.adtech.de/adlink%7C82%7C59111%7C1%7C168%7CAdId% 3D1023327%3BBnId%3D4%3Bitime%3D335264036%3Bku%3D12900% 3Bkey%3Dcomputing%2Bbetanews%5Fgeneral%3Blink%3D") (''http'', 'ad.doubleclick.net/adi/N3691.VibrantMedia/ B1733031.2;sz=160x600;click=http%3A/adforce.adtech.de/adlink% 7C82%7C59111%7C1%7C168%7CAdId%3D1023327%3BBnId%3D4%3Bitime %3D335264036%3Bku%3D12900%3Bkey%3Dcomputing%2Bbetanews% 5Fgeneral%3Blink%3D', '', '', '') What's odd is that the code specifically says to do this: def _splitparams(url): if '/' in url: i = url.find(';', url.rfind('/')) if i < 0: return url, '' Is there a reason for the rfind? ---------------------------------------------------------------------- >Comment By: John Hansen (johnhansen) Date: 2006-01-13 18:19 Message: Logged In: YES user_id=1418831 Well RFC2396, section 3.4 says "/" is reserved within a query. However, the real world doesn't seem to follow RFC2396... so I still think it's a bug: the class should be useful, rather than try to enforce an RFC. A warning would be fine. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2006-01-13 00:25 Message: Logged In: YES user_id=174455 Looking at the testcases it appears the answers must be in rfc's 1808 or 2396. http://www.ietf.org/rfc/rfc1808.txt and http://www.ietf.org/rfc/rfc2396.txt See for example section 5.3 of 1808. I don't see why _splitparams does what is does but I didn't exactly close-read the text either. Also be sure to look at Lib/test/test_urlparse.py. ---------------------------------------------------------------------- Comment By: John Hansen (johnhansen) Date: 2006-01-04 16:31 Message: Logged In: YES user_id=1418831 The first line should have read: If the parameter field of a URL contains a '/', urlparse does not enter it into the parameter field, but leaves it attached to the path. ---------------------------------------------------------------------- Comment By: John Hansen (johnhansen) Date: 2006-01-04 05:00 Message: Logged In: YES user_id=1418831 The first line should have read: If the parameter field of a URL contains a '/', urlparse does not enter it into the parameter field, but leaves it attached to the path. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396543&group_id=5470 From noreply at sourceforge.net Fri Jan 13 22:19:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jan 2006 13:19:32 -0800 Subject: [ python-Bugs-969718 ] BASECFLAGS are not passed to module build line Message-ID: Bugs item #969718, was opened at 2004-06-09 10:56 Message generated for change (Comment added) made by nyogtha You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=969718&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: Jason Beardsley (vaxhacker) Assigned to: Nobody/Anonymous (nobody) Summary: BASECFLAGS are not passed to module build line Initial Comment: The value of BASECFLAGS from /prefix/lib/pythonver/config/Makefile is not present on the compile command for modules being built by distutils ("python setup.py build"). It seems that only the value of OPT is passed along. This is insufficient when BASECFLAGS contains "-fno-static-aliasing", since recent versions of gcc will emit incorrect (crashing) code if this flag is not provided, when compiling certain modules (the mx products from egenix, for example). I did try to set CFLAGS in my environment, as directed by documentation, but this also had zero effect on the final build command. ---------------------------------------------------------------------- Comment By: nyogtha (nyogtha) Date: 2006-01-13 15:19 Message: Logged In: YES user_id=1426882 This is still a bug in Python 2.4.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=969718&group_id=5470 From noreply at sourceforge.net Sat Jan 14 04:46:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jan 2006 19:46:15 -0800 Subject: [ python-Bugs-1396622 ] TimedRotatingFileHandler midnight rollover time increases Message-ID: Bugs item #1396622, was opened at 2006-01-04 00:25 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396622&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Waters (awaters) Assigned to: Vinay Sajip (vsajip) Summary: TimedRotatingFileHandler midnight rollover time increases Initial Comment: When calculating the next rollover time the calculation uses the current time plus the interval. Unless the log file is written exactly at midnight the rollover time becomes the current time + 1 day. So for example, if the log is written at 2:00am then the next rollover time will be 2:00am the following day rather than midnight. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-01-13 19:46 Message: Logged In: YES user_id=341410 For this handler, one should also be aware of the fact that when DST changes, the time.timezone doesn't change, so calculation of when midnight actually is (if one does that), may be off by an hour until the daemon restarts. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-04 21:46 Message: Logged In: YES user_id=33168 Vinay, any comments? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396622&group_id=5470 From noreply at sourceforge.net Sat Jan 14 06:24:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jan 2006 21:24:40 -0800 Subject: [ python-Feature Requests-1397806 ] python.org - add RFE tracker Message-ID: Feature Requests item #1397806, was opened at 2006-01-05 10:08 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1397806&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jim Jewett (jimjjewett) >Assigned to: Kurt B. Kaiser (kbk) Summary: python.org - add RFE tracker Initial Comment: On http://www.python.org/, the left hand column includes a "Community" section with a "Python Project:" subsection. This links to the bugs and patches tracker, (and to svn). It should also link to the Request For Enhancement tracker http://sourceforge.net/tracker/? group_id=5470&atid=355470 to make it a bit more likely that such requests will not be filed as bugs. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-01-14 00:24 Message: Logged In: YES user_id=149084 Committed revision 8795. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1397806&group_id=5470 From noreply at sourceforge.net Sat Jan 14 08:40:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jan 2006 23:40:22 -0800 Subject: [ python-Bugs-1402308 ] segfault when using mmap(-1,...) [+PATCH] Message-ID: Bugs item #1402308, was opened at 2006-01-10 16:38 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1402308&group_id=5470 Please note that this message will contain 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 Submitted By: Ralf Schmitt (titty) >Assigned to: Neal Norwitz (nnorwitz) Summary: segfault when using mmap(-1,...) [+PATCH] Initial Comment: This is happening on OSX, Python 2.4.2: ralf at mini:~/Python-2.4.2$ cat ~/t.py #! /usr/bin/env python import sys print sys.version import mmap mmap.mmap(-1, 4096) ralf at mini:~/Python-2.4.2$ ./python ~/t.py 2.4.2 (#1, Jan 11 2006, 00:58:35) [GCC 4.0.1 (Apple Computer, Inc. build 5247)] Segmentation fault The following one line diff solves that problem (mmap's data member is otherwise uninitialized...) ralf at mini:~/Python-2.4.2$ diff -u Modules/mmapmodule.c-orig Modules/mmapmodule.c--- Modules/mmapmodule.c-orig 2006-01-11 01:12:32.000000000 +0100 +++ Modules/mmapmodule.c 2006-01-11 01:13:06.000000000 +0100 @@ -910,6 +910,7 @@ #endif m_obj = PyObject_New (mmap_object, &mmap_object_type); if (m_obj == NULL) {return NULL;} + m_obj->data = NULL; m_obj->size = (size_t) map_size; m_obj->pos = (size_t) 0; m_obj->fd = dup(fd); However, the problem is that passing -1 as filedescriptor to mmap is perfectly ok when one wants to mmap anonymous memory (at least on FreeeBSD and OS X). The following patch also solves that problem. [mmap.mmap(-1, 4096, mmap.MAP_ANON) now works...] Any chance to get this included? Passing -1 to mmap should not hurt anybody, as systems which do not support it, should then return an error from mmap. ralf at mini:~/Python-2.4.2$ diff -u Modules/mmapmodule.c-orig Modules/mmapmodule.c--- Modules/mmapmodule.c-orig 2006-01-11 01:12:32.000000000 +0100 +++ Modules/mmapmodule.c 2006-01-11 01:23:52.000000000 +0100 @@ -910,10 +910,12 @@ #endif m_obj = PyObject_New (mmap_object, &mmap_object_type); if (m_obj == NULL) {return NULL;} + m_obj->data = NULL; m_obj->size = (size_t) map_size; m_obj->pos = (size_t) 0; - m_obj->fd = dup(fd); - if (m_obj->fd == -1) { + if (fd == -1) { + m_obj->fd = -1; + } else if ((m_obj->fd = dup(fd)) == -1) { Py_DECREF(m_obj); PyErr_SetFromErrno(mmap_module_error); return NULL; ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-13 23:40 Message: Logged In: YES user_id=33168 Thanks. I only fixed the bug as the second part is a feature request. Committed revision 42012. Committed revision 42041. (2.4) I'm not opposed to adding the feature, but would like to keep the unix and windows versions as similar as possible. I don't know what windows does in this case. I'm going to close this bug report. If you are interested in making a patch that handles windows, unix, and the doc feel free to submit a patch for it. Also, when you submit a patch please attach a file since SF screws up the formatting. For the one-liner it's not a big deal to inline, but it could be a problem for python code still. ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2006-01-11 00:43 Message: Logged In: YES user_id=17929 this is a regression from 2.4.1. On 2.4.1 mmap(-1, 4096, mmap.MAP_ANON) works without problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1402308&group_id=5470 From noreply at sourceforge.net Sat Jan 14 08:41:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jan 2006 23:41:37 -0800 Subject: [ python-Bugs-1403221 ] 2.3.5 source RPM install fails w/o tk-devel Message-ID: Bugs item #1403221, was opened at 2006-01-11 11:24 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403221&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nathan Zook (nathan_zook_wk) >Assigned to: Sean Reifschneider (jafo) Summary: 2.3.5 source RPM install fails w/o tk-devel Initial Comment: Install fails because _tkinter.so is not found. This library is not built if the tk header files are not found, but the installer treats this as a fatal error. This dependece upon tk-devel is not noted in the .spec file, so the install fails late (and unclearly) instead of early & clearly. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-13 23:41 Message: Logged In: YES user_id=33168 Note: we don't maintain 2.3 any longer. Sean any comments? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403221&group_id=5470 From noreply at sourceforge.net Sat Jan 14 08:42:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 13 Jan 2006 23:42:13 -0800 Subject: [ python-Bugs-1403225 ] 2.3.5 RPM provides incompatibility Message-ID: Bugs item #1403225, was opened at 2006-01-11 11:27 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403225&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nathan Zook (nathan_zook_wk) >Assigned to: Sean Reifschneider (jafo) Summary: 2.3.5 RPM provides incompatibility Initial Comment: The 2.3.5 rpm provides list is substantially out of sync with the 2.3.4-14 provides list for CEntOS, making it impossible (for me) to use this rpm to upgrade my installation. Help? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-13 23:42 Message: Logged In: YES user_id=33168 Note: we do not maintain 2.3 any longer. Sean? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403225&group_id=5470 From noreply at sourceforge.net Sat Jan 14 13:45:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Jan 2006 04:45:43 -0800 Subject: [ python-Bugs-1402308 ] segfault when using mmap(-1,...) [+PATCH] Message-ID: Bugs item #1402308, was opened at 2006-01-11 01:38 Message generated for change (Comment added) made by titty You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1402308&group_id=5470 Please note that this message will contain 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 Submitted By: Ralf Schmitt (titty) Assigned to: Neal Norwitz (nnorwitz) Summary: segfault when using mmap(-1,...) [+PATCH] Initial Comment: This is happening on OSX, Python 2.4.2: ralf at mini:~/Python-2.4.2$ cat ~/t.py #! /usr/bin/env python import sys print sys.version import mmap mmap.mmap(-1, 4096) ralf at mini:~/Python-2.4.2$ ./python ~/t.py 2.4.2 (#1, Jan 11 2006, 00:58:35) [GCC 4.0.1 (Apple Computer, Inc. build 5247)] Segmentation fault The following one line diff solves that problem (mmap's data member is otherwise uninitialized...) ralf at mini:~/Python-2.4.2$ diff -u Modules/mmapmodule.c-orig Modules/mmapmodule.c--- Modules/mmapmodule.c-orig 2006-01-11 01:12:32.000000000 +0100 +++ Modules/mmapmodule.c 2006-01-11 01:13:06.000000000 +0100 @@ -910,6 +910,7 @@ #endif m_obj = PyObject_New (mmap_object, &mmap_object_type); if (m_obj == NULL) {return NULL;} + m_obj->data = NULL; m_obj->size = (size_t) map_size; m_obj->pos = (size_t) 0; m_obj->fd = dup(fd); However, the problem is that passing -1 as filedescriptor to mmap is perfectly ok when one wants to mmap anonymous memory (at least on FreeeBSD and OS X). The following patch also solves that problem. [mmap.mmap(-1, 4096, mmap.MAP_ANON) now works...] Any chance to get this included? Passing -1 to mmap should not hurt anybody, as systems which do not support it, should then return an error from mmap. ralf at mini:~/Python-2.4.2$ diff -u Modules/mmapmodule.c-orig Modules/mmapmodule.c--- Modules/mmapmodule.c-orig 2006-01-11 01:12:32.000000000 +0100 +++ Modules/mmapmodule.c 2006-01-11 01:23:52.000000000 +0100 @@ -910,10 +910,12 @@ #endif m_obj = PyObject_New (mmap_object, &mmap_object_type); if (m_obj == NULL) {return NULL;} + m_obj->data = NULL; m_obj->size = (size_t) map_size; m_obj->pos = (size_t) 0; - m_obj->fd = dup(fd); - if (m_obj->fd == -1) { + if (fd == -1) { + m_obj->fd = -1; + } else if ((m_obj->fd = dup(fd)) == -1) { Py_DECREF(m_obj); PyErr_SetFromErrno(mmap_module_error); return NULL; ---------------------------------------------------------------------- >Comment By: Ralf Schmitt (titty) Date: 2006-01-14 13:45 Message: Logged In: YES user_id=17929 1.The mmap module exports MAP_ANON/MAP_ANONYMOUS on unix like systems, so someone who has been using mmap in C most probably would expect that passing -1 as fileno is possible in order to do anonymous mmap's. (Those who have been using prior versions of python and anonymous mmap would also expect the same). 2. The workaround (if -1 is artificially forbidden as fileno) is to open /dev/ zero and using that as a fileno to mmap (this doesn't work on OS X). However, since filedescriptors passed to mmap are now dup'ed (starting from version 2.4.2) this leads to excessive abuse of filedescriptors up to the point that one might not be able to use anonymous mmap's because of filedescriptor limitations. 3. On Windows one can currently pass 0 as fileno in order to allocate anonymous memory (which seems wrong, even on windows 0 might be a valid filedescriptor? -1 would be a better value here). This is handled as a special case in the windows code. So, in Python 2.4.2 it's now harder, maybe even impossible, to use anonymous mmap's on unix, whereas in windows it's a no brainer. And this module got it's name from a unix system call :). 4. I don't consider this a feature request. 2.4.2 broke existing code. Guess, I'll have to send a patch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-14 08:40 Message: Logged In: YES user_id=33168 Thanks. I only fixed the bug as the second part is a feature request. Committed revision 42012. Committed revision 42041. (2.4) I'm not opposed to adding the feature, but would like to keep the unix and windows versions as similar as possible. I don't know what windows does in this case. I'm going to close this bug report. If you are interested in making a patch that handles windows, unix, and the doc feel free to submit a patch for it. Also, when you submit a patch please attach a file since SF screws up the formatting. For the one-liner it's not a big deal to inline, but it could be a problem for python code still. ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2006-01-11 09:43 Message: Logged In: YES user_id=17929 this is a regression from 2.4.1. On 2.4.1 mmap(-1, 4096, mmap.MAP_ANON) works without problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1402308&group_id=5470 From noreply at sourceforge.net Sat Jan 14 19:34:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Jan 2006 10:34:33 -0800 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: Open Resolution: None Priority: 5 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: 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 Sat Jan 14 22:12:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Jan 2006 13:12:02 -0800 Subject: [ python-Bugs-1402308 ] segfault when using mmap(-1,...) [+PATCH] Message-ID: Bugs item #1402308, was opened at 2006-01-11 01:38 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1402308&group_id=5470 Please note that this message will contain 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 Submitted By: Ralf Schmitt (titty) Assigned to: Neal Norwitz (nnorwitz) Summary: segfault when using mmap(-1,...) [+PATCH] Initial Comment: This is happening on OSX, Python 2.4.2: ralf at mini:~/Python-2.4.2$ cat ~/t.py #! /usr/bin/env python import sys print sys.version import mmap mmap.mmap(-1, 4096) ralf at mini:~/Python-2.4.2$ ./python ~/t.py 2.4.2 (#1, Jan 11 2006, 00:58:35) [GCC 4.0.1 (Apple Computer, Inc. build 5247)] Segmentation fault The following one line diff solves that problem (mmap's data member is otherwise uninitialized...) ralf at mini:~/Python-2.4.2$ diff -u Modules/mmapmodule.c-orig Modules/mmapmodule.c--- Modules/mmapmodule.c-orig 2006-01-11 01:12:32.000000000 +0100 +++ Modules/mmapmodule.c 2006-01-11 01:13:06.000000000 +0100 @@ -910,6 +910,7 @@ #endif m_obj = PyObject_New (mmap_object, &mmap_object_type); if (m_obj == NULL) {return NULL;} + m_obj->data = NULL; m_obj->size = (size_t) map_size; m_obj->pos = (size_t) 0; m_obj->fd = dup(fd); However, the problem is that passing -1 as filedescriptor to mmap is perfectly ok when one wants to mmap anonymous memory (at least on FreeeBSD and OS X). The following patch also solves that problem. [mmap.mmap(-1, 4096, mmap.MAP_ANON) now works...] Any chance to get this included? Passing -1 to mmap should not hurt anybody, as systems which do not support it, should then return an error from mmap. ralf at mini:~/Python-2.4.2$ diff -u Modules/mmapmodule.c-orig Modules/mmapmodule.c--- Modules/mmapmodule.c-orig 2006-01-11 01:12:32.000000000 +0100 +++ Modules/mmapmodule.c 2006-01-11 01:23:52.000000000 +0100 @@ -910,10 +910,12 @@ #endif m_obj = PyObject_New (mmap_object, &mmap_object_type); if (m_obj == NULL) {return NULL;} + m_obj->data = NULL; m_obj->size = (size_t) map_size; m_obj->pos = (size_t) 0; - m_obj->fd = dup(fd); - if (m_obj->fd == -1) { + if (fd == -1) { + m_obj->fd = -1; + } else if ((m_obj->fd = dup(fd)) == -1) { Py_DECREF(m_obj); PyErr_SetFromErrno(mmap_module_error); return NULL; ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-14 22:12 Message: Logged In: YES user_id=1188172 Note that MAP_ANON isn't mentioned in the docs, so it's not official. Otherwise, I agree with Ralf. -1 should be excluded from dup()ing and this should be documented. ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2006-01-14 13:45 Message: Logged In: YES user_id=17929 1.The mmap module exports MAP_ANON/MAP_ANONYMOUS on unix like systems, so someone who has been using mmap in C most probably would expect that passing -1 as fileno is possible in order to do anonymous mmap's. (Those who have been using prior versions of python and anonymous mmap would also expect the same). 2. The workaround (if -1 is artificially forbidden as fileno) is to open /dev/ zero and using that as a fileno to mmap (this doesn't work on OS X). However, since filedescriptors passed to mmap are now dup'ed (starting from version 2.4.2) this leads to excessive abuse of filedescriptors up to the point that one might not be able to use anonymous mmap's because of filedescriptor limitations. 3. On Windows one can currently pass 0 as fileno in order to allocate anonymous memory (which seems wrong, even on windows 0 might be a valid filedescriptor? -1 would be a better value here). This is handled as a special case in the windows code. So, in Python 2.4.2 it's now harder, maybe even impossible, to use anonymous mmap's on unix, whereas in windows it's a no brainer. And this module got it's name from a unix system call :). 4. I don't consider this a feature request. 2.4.2 broke existing code. Guess, I'll have to send a patch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-14 08:40 Message: Logged In: YES user_id=33168 Thanks. I only fixed the bug as the second part is a feature request. Committed revision 42012. Committed revision 42041. (2.4) I'm not opposed to adding the feature, but would like to keep the unix and windows versions as similar as possible. I don't know what windows does in this case. I'm going to close this bug report. If you are interested in making a patch that handles windows, unix, and the doc feel free to submit a patch for it. Also, when you submit a patch please attach a file since SF screws up the formatting. For the one-liner it's not a big deal to inline, but it could be a problem for python code still. ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2006-01-11 09:43 Message: Logged In: YES user_id=17929 this is a regression from 2.4.1. On 2.4.1 mmap(-1, 4096, mmap.MAP_ANON) works without problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1402308&group_id=5470 From noreply at sourceforge.net Sat Jan 14 22:19:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Jan 2006 13:19:07 -0800 Subject: [ python-Bugs-1396543 ] urlparse is confused by / Message-ID: Bugs item #1396543, was opened at 2006-01-04 05:57 Message generated for change (Comment added) made by pterk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396543&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John Hansen (johnhansen) Assigned to: Nobody/Anonymous (nobody) Summary: urlparse is confused by / Initial Comment: If the parameter field of a URL contains a '/', urlparse does not enter date in the parameter field, but leaves it attached to the path. The simplified example is: >>> urlparse.urlparse("http://f/adi;s=a;c=b/") ('http', 'f', '/adi;s=a;c=b/', '', '', '') >>> urlparse.urlparse("http://f/adi;s=a;c=b") ('http', 'f', '/adi', 's=a;c=b', '', '') The realworld case was: >>> urlparse.urlparse("http://ad.doubleclick.net/adi/ N3691.VibrantMedia/B1733031.2;sz=160x600;click=http%3A/ adforce.adtech.de/adlink%7C82%7C59111%7C1%7C168%7CAdId% 3D1023327%3BBnId%3D4%3Bitime%3D335264036%3Bku%3D12900% 3Bkey%3Dcomputing%2Bbetanews%5Fgeneral%3Blink%3D") (''http'', 'ad.doubleclick.net/adi/N3691.VibrantMedia/ B1733031.2;sz=160x600;click=http%3A/adforce.adtech.de/adlink% 7C82%7C59111%7C1%7C168%7CAdId%3D1023327%3BBnId%3D4%3Bitime %3D335264036%3Bku%3D12900%3Bkey%3Dcomputing%2Bbetanews% 5Fgeneral%3Blink%3D', '', '', '') What's odd is that the code specifically says to do this: def _splitparams(url): if '/' in url: i = url.find(';', url.rfind('/')) if i < 0: return url, '' Is there a reason for the rfind? ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2006-01-14 22:19 Message: Logged In: YES user_id=174455 Actually section 3.3 of RFC2396 is relevant here and it seems that it is indeed correctly implemented as is. I'm not sure what the 'python policy' is on RFC vs The Real World. My guess would be that RFC's carry some weight. Following the 'real world' is too vague a reference. Your world might be different than mine and tomorrow's world a different world than today's. You can always monkey-patch: >>> def my_splitparams(url): ... i = url.find(';') ... return url[:i], url[i+1:] ... >>> import urlparse >>> urlparse._splitparams = my_splitparams >>> urlparse.urlparse("http://f/adi;s=a;c=b/") ('http', 'f', '/adi', 's=a;c=b/', '', '') ---------------------------------------------------------------------- Comment By: John Hansen (johnhansen) Date: 2006-01-13 19:19 Message: Logged In: YES user_id=1418831 Well RFC2396, section 3.4 says "/" is reserved within a query. However, the real world doesn't seem to follow RFC2396... so I still think it's a bug: the class should be useful, rather than try to enforce an RFC. A warning would be fine. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2006-01-13 01:25 Message: Logged In: YES user_id=174455 Looking at the testcases it appears the answers must be in rfc's 1808 or 2396. http://www.ietf.org/rfc/rfc1808.txt and http://www.ietf.org/rfc/rfc2396.txt See for example section 5.3 of 1808. I don't see why _splitparams does what is does but I didn't exactly close-read the text either. Also be sure to look at Lib/test/test_urlparse.py. ---------------------------------------------------------------------- Comment By: John Hansen (johnhansen) Date: 2006-01-04 17:31 Message: Logged In: YES user_id=1418831 The first line should have read: If the parameter field of a URL contains a '/', urlparse does not enter it into the parameter field, but leaves it attached to the path. ---------------------------------------------------------------------- Comment By: John Hansen (johnhansen) Date: 2006-01-04 06:00 Message: Logged In: YES user_id=1418831 The first line should have read: If the parameter field of a URL contains a '/', urlparse does not enter it into the parameter field, but leaves it attached to the path. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396543&group_id=5470 From noreply at sourceforge.net Sat Jan 14 23:40:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 14 Jan 2006 14:40:23 -0800 Subject: [ python-Bugs-1371247 ] locale.windows_locale Message-ID: Bugs item #1371247, was opened at 2005-12-01 22:50 Message generated for change (Comment added) made by pterk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1371247&group_id=5470 Please note that this 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 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: locale.windows_locale Initial Comment: from locale.py: # # this maps windows language identifiers (as used on Windows 95 and # earlier) to locale strings. # # NOTE: this mapping is incomplete. If your language is missing, please # submit a bug report to Python bug manager, which you can find via: # http://www.python.org/dev/ # Make sure you include the missing language identifier and the suggested # locale code. # The complete mapping table can be found here: http://www.dx21.com/SCRIPTING/VBSCRIPT/LCID.ASP ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2006-01-14 23:40 Message: Logged In: YES user_id=174455 See patch 1406159: http://sourceforge.net/tracker/index.php?func=detail&aid=1406159&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2005-12-01 23:30 Message: Logged In: YES user_id=731668 I believe there's a small typo in that page. Spanish 1034 says hex 0x0C0A when hex(1034) is 0x040A The rest seems correct (hex and int values match). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1371247&group_id=5470 From noreply at sourceforge.net Sun Jan 15 13:03:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 15 Jan 2006 04:03:03 -0800 Subject: [ python-Bugs-1180470 ] BaseHTTPServer uses deprecated mimetools.Message Message-ID: Bugs item #1180470, was opened at 2005-04-11 00:26 Message generated for change (Comment added) made by kousu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180470&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Jimenez (paulj) Assigned to: Nobody/Anonymous (nobody) Summary: BaseHTTPServer uses deprecated mimetools.Message Initial Comment: BaseHTTPServer used a deprecated (as of 2.3) class: mimetools.Message. cgi.py also uses it, but that's getting fixed. If only there was just a single API for writing webapps. ---------------------------------------------------------------------- Comment By: Nick Guenther (kousu) Date: 2006-01-15 07:03 Message: Logged In: YES user_id=705725 There's a DoS attack possible here because of it, actually. mimetools.Message locks up if it never sees '\r\n\r\n'. Thus to crash a BaseHTTPServer all one must do is: echo "GET / HTTP/1.1" > nc host port. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180470&group_id=5470 From noreply at sourceforge.net Mon Jan 16 04:24:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 15 Jan 2006 19:24:05 -0800 Subject: [ python-Bugs-1396471 ] file.tell() returns illegal value on Windows Message-ID: Bugs item #1396471, was opened at 2006-01-04 02:53 Message generated for change (Comment added) made by pterk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396471&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Tom Goddard (tom_goddard) Assigned to: Nobody/Anonymous (nobody) Summary: file.tell() returns illegal value on Windows Initial Comment: The file tell() method returns an illegal value that causes an exception when passed to seek(). This happens on Windows when a file that contains unix-style newlines '\n' is opened and read in text mode 'r'. Below is code that produces the problem on Windows 2.4.2 in an IDLE shell. The bug does not occur when using mode 'rU' or 'rb'. But I expect correct behaviour with mode 'r'. My understanding is that 'rU' translates line endings to '\n' in the returned string while mode 'r' still correctly reads the lines using readline(), recognizing all 3 common endline conventions, but does not translate (ie includes \n\r or \r or \n in returned string). The error in the tell() return value depends on how long the file is. Changing the 'more\n'*10 line in the example code will cause different incorrect return values. Previous bug reports have mentioned problems with tell/seek when using file iterators, the file.next() method and the "for line in file:" construct. This bug is different and just involves readline() and tell() with mode 'r'. Example code tellbug.py follows: wf = open('testdata', 'wb') wf.write('01234\n56789\n'+ 'more\n'*10) wf.close() f = open('testdata', 'r') f.readline() t = f.tell() print t f.seek(t) ------- Running gives: >>> execfile('tellbug.py') -5 Traceback (most recent call last): File "", line 1, in -toplevel- execfile('tellbug.py') File "tellbug.py", line 9, in -toplevel- f.seek(t) IOError: [Errno 22] Invalid argument ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2006-01-16 04:24 Message: Logged In: YES user_id=174455 I have done some additional research on this. It appears the bug is in ftell of the windows c-library and it seems to be a 'known problem'. See: http://www.mathworks.com/access/helpdesk/help/techdoc/ref/ftell.html More here: http://www.cygwin.com/faq/faq.api.html http://gnuwin32.sourceforge.net/compile.html (search for ftell in both cases) Also see: http://sourceforge.net/tracker/index.php?func=detail&aid=1381717&group_id=5470&atid=105470 So even though the file isn't opened with 'rt' I gather from Tim Peter's remark about 't' on windows that the default is 't' anyway unless you really try. So this example is *exactly* what the matlab-people found. That is nice to know I guess but it doesn't really help to solve the problem. It seems to me there are three solutions. 1. ftell could be fixed for unix-files on windows.* Not very likely to happen soon. 2. Python could special-case this for this specific scenario. Way beyond my capabilities and probably too much hassle in any case especially since the 'fix' is so easy (just open with 'rb'). 3. Leave it as is but document it. I have submitted a (doc-)patch 1407021 (http://sourceforge.net/tracker/index.php?func=detail&aid=1407021&group_id=5470&atid=305470) for the library reference (libstdtypes.tex) that reads: Please note that tell() can return illegal values (after an fgets()) on Windows when reading files with UNIX-style line-endings. Use 'rb'-mode to circumvent this problem. * MS provides this note in the compatibility section of the c-runtime libraries: "Note: In this version of Visual C++, UNIX compatibility information has been removed from the function descriptions." In case your wondering what 'this version' is: VS.NET and VS 6.0. Apperantly there were no other 'previous versions'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396471&group_id=5470 From noreply at sourceforge.net Mon Jan 16 07:33:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 15 Jan 2006 22:33:01 -0800 Subject: [ python-Bugs-1407069 ] bz2module with no long long type support Message-ID: Bugs item #1407069, was opened at 2006-01-16 13: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=1407069&group_id=5470 Please note that this 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 Submitted By: kbob_ru (kbob_ru) Assigned to: Nobody/Anonymous (nobody) Summary: bz2module with no long long type support Initial Comment: in Modules/bz2module.c #if SIZEOF_LONG >= 8 #define BZS_TOTAL_OUT(bzs) \ (((long)bzs->total_out_hi32 << 32) + bzs- >total_out_lo32) #elif SIZEOF_LONG_LONG >= 8 #define BZS_TOTAL_OUT(bzs) \ (((PY_LONG_LONG)bzs->total_out_hi32 << 32) + bzs->total_out_lo32) #else #define BZS_TOTAL_OUT(bzs) \ bzs->total_out_lo32; #endif when #else statmen execute it leads to error, because no semicolon needed in the end of definition: #define BZS_TOTAL_OUT(bzs) \ bzs->total_out_lo32; This error found in version 2.3.5 and 2.4.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1407069&group_id=5470 From noreply at sourceforge.net Mon Jan 16 09:46:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 Jan 2006 00:46:13 -0800 Subject: [ python-Bugs-1402308 ] segfault when using mmap(-1,...) [+PATCH] Message-ID: Bugs item #1402308, was opened at 2006-01-11 01:38 Message generated for change (Comment added) made by titty You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1402308&group_id=5470 Please note that this message will contain 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 Submitted By: Ralf Schmitt (titty) Assigned to: Neal Norwitz (nnorwitz) Summary: segfault when using mmap(-1,...) [+PATCH] Initial Comment: This is happening on OSX, Python 2.4.2: ralf at mini:~/Python-2.4.2$ cat ~/t.py #! /usr/bin/env python import sys print sys.version import mmap mmap.mmap(-1, 4096) ralf at mini:~/Python-2.4.2$ ./python ~/t.py 2.4.2 (#1, Jan 11 2006, 00:58:35) [GCC 4.0.1 (Apple Computer, Inc. build 5247)] Segmentation fault The following one line diff solves that problem (mmap's data member is otherwise uninitialized...) ralf at mini:~/Python-2.4.2$ diff -u Modules/mmapmodule.c-orig Modules/mmapmodule.c--- Modules/mmapmodule.c-orig 2006-01-11 01:12:32.000000000 +0100 +++ Modules/mmapmodule.c 2006-01-11 01:13:06.000000000 +0100 @@ -910,6 +910,7 @@ #endif m_obj = PyObject_New (mmap_object, &mmap_object_type); if (m_obj == NULL) {return NULL;} + m_obj->data = NULL; m_obj->size = (size_t) map_size; m_obj->pos = (size_t) 0; m_obj->fd = dup(fd); However, the problem is that passing -1 as filedescriptor to mmap is perfectly ok when one wants to mmap anonymous memory (at least on FreeeBSD and OS X). The following patch also solves that problem. [mmap.mmap(-1, 4096, mmap.MAP_ANON) now works...] Any chance to get this included? Passing -1 to mmap should not hurt anybody, as systems which do not support it, should then return an error from mmap. ralf at mini:~/Python-2.4.2$ diff -u Modules/mmapmodule.c-orig Modules/mmapmodule.c--- Modules/mmapmodule.c-orig 2006-01-11 01:12:32.000000000 +0100 +++ Modules/mmapmodule.c 2006-01-11 01:23:52.000000000 +0100 @@ -910,10 +910,12 @@ #endif m_obj = PyObject_New (mmap_object, &mmap_object_type); if (m_obj == NULL) {return NULL;} + m_obj->data = NULL; m_obj->size = (size_t) map_size; m_obj->pos = (size_t) 0; - m_obj->fd = dup(fd); - if (m_obj->fd == -1) { + if (fd == -1) { + m_obj->fd = -1; + } else if ((m_obj->fd = dup(fd)) == -1) { Py_DECREF(m_obj); PyErr_SetFromErrno(mmap_module_error); return NULL; ---------------------------------------------------------------------- >Comment By: Ralf Schmitt (titty) Date: 2006-01-16 09:46 Message: Logged In: YES user_id=17929 patch submitted: https://sourceforge.net/tracker/? func=detail&atid=105470&aid=1402308&group_id=5470 ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-14 22:12 Message: Logged In: YES user_id=1188172 Note that MAP_ANON isn't mentioned in the docs, so it's not official. Otherwise, I agree with Ralf. -1 should be excluded from dup()ing and this should be documented. ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2006-01-14 13:45 Message: Logged In: YES user_id=17929 1.The mmap module exports MAP_ANON/MAP_ANONYMOUS on unix like systems, so someone who has been using mmap in C most probably would expect that passing -1 as fileno is possible in order to do anonymous mmap's. (Those who have been using prior versions of python and anonymous mmap would also expect the same). 2. The workaround (if -1 is artificially forbidden as fileno) is to open /dev/ zero and using that as a fileno to mmap (this doesn't work on OS X). However, since filedescriptors passed to mmap are now dup'ed (starting from version 2.4.2) this leads to excessive abuse of filedescriptors up to the point that one might not be able to use anonymous mmap's because of filedescriptor limitations. 3. On Windows one can currently pass 0 as fileno in order to allocate anonymous memory (which seems wrong, even on windows 0 might be a valid filedescriptor? -1 would be a better value here). This is handled as a special case in the windows code. So, in Python 2.4.2 it's now harder, maybe even impossible, to use anonymous mmap's on unix, whereas in windows it's a no brainer. And this module got it's name from a unix system call :). 4. I don't consider this a feature request. 2.4.2 broke existing code. Guess, I'll have to send a patch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-14 08:40 Message: Logged In: YES user_id=33168 Thanks. I only fixed the bug as the second part is a feature request. Committed revision 42012. Committed revision 42041. (2.4) I'm not opposed to adding the feature, but would like to keep the unix and windows versions as similar as possible. I don't know what windows does in this case. I'm going to close this bug report. If you are interested in making a patch that handles windows, unix, and the doc feel free to submit a patch for it. Also, when you submit a patch please attach a file since SF screws up the formatting. For the one-liner it's not a big deal to inline, but it could be a problem for python code still. ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2006-01-11 09:43 Message: Logged In: YES user_id=17929 this is a regression from 2.4.1. On 2.4.1 mmap(-1, 4096, mmap.MAP_ANON) works without problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1402308&group_id=5470 From noreply at sourceforge.net Mon Jan 16 10:11:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 Jan 2006 01:11:16 -0800 Subject: [ python-Bugs-1396030 ] TimedRotatingFileHandler at midnight rolls over at 01:00 Message-ID: Bugs item #1396030, was opened at 2006-01-03 14:26 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396030&group_id=5470 Please note that this message will contain 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 Submitted By: Andrew Waters (awaters) Assigned to: Vinay Sajip (vsajip) Summary: TimedRotatingFileHandler at midnight rolls over at 01:00 Initial Comment: Using TimedRotatingFileHandler with interval set to midnight rolls the log over at 1:00am rather than midnight. (LocalTime = GMT). This is because the calculation of seconds until midnight is incorrect (it behaves as if there are 24 hours, 59 minutes and 59 seconds in the day). It also means that should a program stop between midnight and 1:00am and restart it fails to roll over the log as the log over time is set to 1:00am the next day. Occurs on Linux (FC3), Windows XP (SP2). Bug occurs (2.4.2 and currently exists in most recent 2.5 SVN code). ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2006-01-16 09:11 Message: Logged In: YES user_id=308438 Checked into SVN trunk and release24-maint branch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396030&group_id=5470 From noreply at sourceforge.net Mon Jan 16 10:18:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 Jan 2006 01:18:05 -0800 Subject: [ python-Bugs-1396622 ] TimedRotatingFileHandler midnight rollover time increases Message-ID: Bugs item #1396622, was opened at 2006-01-04 08:25 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396622&group_id=5470 Please note that this message will contain 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: Accepted Priority: 5 Submitted By: Andrew Waters (awaters) Assigned to: Vinay Sajip (vsajip) Summary: TimedRotatingFileHandler midnight rollover time increases Initial Comment: When calculating the next rollover time the calculation uses the current time plus the interval. Unless the log file is written exactly at midnight the rollover time becomes the current time + 1 day. So for example, if the log is written at 2:00am then the next rollover time will be 2:00am the following day rather than midnight. ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2006-01-16 09:18 Message: Logged In: YES user_id=308438 Fixed the rollover time increase problem (checked into SVN trunk and release24-maint branch). However, DST adjustment has not been done yet. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-01-14 03:46 Message: Logged In: YES user_id=341410 For this handler, one should also be aware of the fact that when DST changes, the time.timezone doesn't change, so calculation of when midnight actually is (if one does that), may be off by an hour until the daemon restarts. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-05 05:46 Message: Logged In: YES user_id=33168 Vinay, any comments? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396622&group_id=5470 From noreply at sourceforge.net Mon Jan 16 10:30:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 Jan 2006 01:30:51 -0800 Subject: [ python-Bugs-1396040 ] TimedRotatingFileHandler does not recover from open error Message-ID: Bugs item #1396040, was opened at 2006-01-03 14:38 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396040&group_id=5470 Please note that this message will contain 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 Submitted By: Andrew Waters (awaters) Assigned to: Vinay Sajip (vsajip) Summary: TimedRotatingFileHandler does not recover from open error Initial Comment: When doing a rollover TimedRotatingFileHandler doRollover does not recover if there is an open error. This is because when the rollover function fails at the open (e.g. too many files open) and is called again at the next attempt to write to the log doRollover attempts to rename (the now no longer existing) original file which raises an exception. ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2006-01-16 09:30 Message: Logged In: YES user_id=308438 Change checked into SVN trunk and release24-maint branch which passes exceptions raised during renaming to handleError (except for SystemExit and KeyboardInterrupt, which are re-raised). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396040&group_id=5470 From noreply at sourceforge.net Mon Jan 16 11:59:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 Jan 2006 02:59:19 -0800 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 cconrad 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 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: 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 Mon Jan 16 22:29:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 Jan 2006 13:29:05 -0800 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: Open Resolution: None Priority: 5 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: 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 Mon Jan 16 22:59:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 Jan 2006 13:59:51 -0800 Subject: [ python-Bugs-1403221 ] 2.3.5 source RPM install fails w/o tk-devel Message-ID: Bugs item #1403221, was opened at 2006-01-11 19:24 Message generated for change (Comment added) made by jafo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403221&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nathan Zook (nathan_zook_wk) Assigned to: Sean Reifschneider (jafo) Summary: 2.3.5 source RPM install fails w/o tk-devel Initial Comment: Install fails because _tkinter.so is not found. This library is not built if the tk header files are not found, but the installer treats this as a fatal error. This dependece upon tk-devel is not noted in the .spec file, so the install fails late (and unclearly) instead of early & clearly. ---------------------------------------------------------------------- >Comment By: Sean Reifschneider (jafo) Date: 2006-01-16 21:59 Message: Logged In: YES user_id=81797 The build doesn't really have a way of adaptively adjusting to whether Tk is available or not. Some people in the past have wanted to build without tk, but perhaps we should just always build with tk? Also, newer RPM versions have a nicer way of doing conditional builds which will probably help this. Any ideas? I'll try to get a new release of the spec file out in the next week and build some SRPMs from them so that people can try them. Currently, this is only addressed by being a FAQ on the RPM pages. Sean ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-14 07:41 Message: Logged In: YES user_id=33168 Note: we don't maintain 2.3 any longer. Sean any comments? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403221&group_id=5470 From noreply at sourceforge.net Mon Jan 16 23:13:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 Jan 2006 14:13:53 -0800 Subject: [ python-Bugs-1403225 ] 2.3.5 RPM provides incompatibility Message-ID: Bugs item #1403225, was opened at 2006-01-11 19:27 Message generated for change (Settings changed) made by jafo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403225&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Nathan Zook (nathan_zook_wk) Assigned to: Sean Reifschneider (jafo) Summary: 2.3.5 RPM provides incompatibility Initial Comment: The 2.3.5 rpm provides list is substantially out of sync with the 2.3.4-14 provides list for CEntOS, making it impossible (for me) to use this rpm to upgrade my installation. Help? ---------------------------------------------------------------------- >Comment By: Sean Reifschneider (jafo) Date: 2006-01-16 22:13 Message: Logged In: YES user_id=81797 The python.org RPM can't really be that specific -- it wouldn't work on other platforms or even likely older or newer versions of CentOS... python.org's RPM needs to be a bit more generic than that I think. I'd recommend either trying to get Red Hat to push up an update to 3.4.5 (which they arguably should have done as errata), or CentOS if they just haven't kept up with the RHES release. However, Red Hat hasn't been very good about updating to new minor versions of Python historicly, even though by their criteria they would seem to be eligible. Alternatively, you could take things into your own hands and get the CentOS RPM and the 2.3.5 Python source, and udpate the CentOS RPM to 2.3.5. That is probably your best option. Sean ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-14 07:42 Message: Logged In: YES user_id=33168 Note: we do not maintain 2.3 any longer. Sean? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403225&group_id=5470 From noreply at sourceforge.net Tue Jan 17 04:04:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 Jan 2006 19:04:07 -0800 Subject: [ python-Bugs-902075 ] urllib2 should be more robust for sloppy proxy URLs Message-ID: Bugs item #902075, was opened at 2004-02-22 21:05 Message generated for change (Comment added) made by spiv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902075&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 should be more robust for sloppy proxy URLs Initial Comment: passing an URL like "foo.bar.baz" instead of "http://foo.bar.baz" results in a stacktrace: 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 This could be fixed by calling urlparse.urlparse on the proxy url, either in the calling code or in the library code, which I would prefer to make it more robust about sloppy URLs passed in the http_proxy environment variable. ---------------------------------------------------------------------- Comment By: Andrew Bennetts (spiv) Date: 2006-01-17 14:04 Message: Logged In: YES user_id=50945 I think test cases would help the patch at http://bugs.debian.org/233305 get applied. ---------------------------------------------------------------------- Comment By: Chris Lawrence (lordsutch) Date: 2004-03-25 08:51 Message: Logged In: YES user_id=6757 I've put together a patch, which can be found at http://bugs.debian.org/233305; it isn't perfect (ideally the entire routine should be rewritten, as it's processing environment data that could be from the "wild"), but it avoids the traceback. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2004-02-22 21:19 Message: Logged In: YES user_id=60903 Ok, I see, PEP42 ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902075&group_id=5470 From noreply at sourceforge.net Tue Jan 17 04:47:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 Jan 2006 19:47:30 -0800 Subject: [ python-Bugs-1407902 ] urlparse does not know about sftp: urls Message-ID: Bugs item #1407902, was opened at 2006-01-17 14:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1407902&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: urlparse does not know about sftp: urls Initial Comment: >>> from urlparse import urlparse >>> urlparse('sftp://example.com//absolute/path') ('sftp', '', '//example.com//absolute/path', '', '', '') >>> urlparse('sftp://example.com/relative/path') ('sftp', '', '//example.com/relative/path', '', '', '') netloc should be populated in both cases ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1407902&group_id=5470 From noreply at sourceforge.net Tue Jan 17 05:35:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 Jan 2006 20:35:42 -0800 Subject: [ python-Bugs-1403349 ] in email can't get attachments' filenames using get_filename Message-ID: Bugs item #1403349, was opened at 2006-01-11 16:47 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403349&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal P. (mpasniew) Assigned to: Barry A. Warsaw (bwarsaw) Summary: in email can't get attachments' filenames using get_filename Initial Comment: in the email package (2.4.1) the get_filename() method returns the MIME field "filename" but some messages have 'name' field instead, for example: USUALLY THE HEADER IS: Content-Type: application/octet-stream; name="XX.pdf" Content-Transfer-Encoding: base64 Content-Description: XX.pdf Content-Disposition: attachment; filename="XX.pdf" BUT SOMETIMES THE HEADER IS: Content-type: application/octet-stream; name="XX.xls" Content-transfer-encoding: base64 For this to work properly I had to code a hack along these lines: filename = part.get_filename() if not filename: ct = part.get("Content-type") m = re.compile('name=\"(\S+)\"').search(ct, 1) if m: filename=m.group(1) But it would be helpful to code this in the get_filename() Michal ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-16 23:35 Message: Logged In: YES user_id=12800 r42075 for Python 2.3 / email 2.5 (will close after porting to all other branches). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403349&group_id=5470 From noreply at sourceforge.net Tue Jan 17 06:09:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 Jan 2006 21:09:39 -0800 Subject: [ python-Bugs-1403349 ] in email can't get attachments' filenames using get_filename Message-ID: Bugs item #1403349, was opened at 2006-01-11 16:47 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403349&group_id=5470 Please note that this message will contain 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 Submitted By: Michal P. (mpasniew) Assigned to: Barry A. Warsaw (bwarsaw) Summary: in email can't get attachments' filenames using get_filename Initial Comment: in the email package (2.4.1) the get_filename() method returns the MIME field "filename" but some messages have 'name' field instead, for example: USUALLY THE HEADER IS: Content-Type: application/octet-stream; name="XX.pdf" Content-Transfer-Encoding: base64 Content-Description: XX.pdf Content-Disposition: attachment; filename="XX.pdf" BUT SOMETIMES THE HEADER IS: Content-type: application/octet-stream; name="XX.xls" Content-transfer-encoding: base64 For this to work properly I had to code a hack along these lines: filename = part.get_filename() if not filename: ct = part.get("Content-type") m = re.compile('name=\"(\S+)\"').search(ct, 1) if m: filename=m.group(1) But it would be helpful to code this in the get_filename() Michal ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-17 00:09 Message: Logged In: YES user_id=12800 r42076 for email 3.0 / python 2.5 r42077 for python 2.4 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-16 23:35 Message: Logged In: YES user_id=12800 r42075 for Python 2.3 / email 2.5 (will close after porting to all other branches). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1403349&group_id=5470 From noreply at sourceforge.net Tue Jan 17 06:29:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 Jan 2006 21:29:03 -0800 Subject: [ python-Bugs-1407069 ] bz2module with no long long type support Message-ID: Bugs item #1407069, was opened at 2006-01-15 22:33 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1407069&group_id=5470 Please note that this 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: Closed >Resolution: Fixed Priority: 5 Submitted By: kbob_ru (kbob_ru) >Assigned to: Neal Norwitz (nnorwitz) Summary: bz2module with no long long type support Initial Comment: in Modules/bz2module.c #if SIZEOF_LONG >= 8 #define BZS_TOTAL_OUT(bzs) \ (((long)bzs->total_out_hi32 << 32) + bzs- >total_out_lo32) #elif SIZEOF_LONG_LONG >= 8 #define BZS_TOTAL_OUT(bzs) \ (((PY_LONG_LONG)bzs->total_out_hi32 << 32) + bzs->total_out_lo32) #else #define BZS_TOTAL_OUT(bzs) \ bzs->total_out_lo32; #endif when #else statmen execute it leads to error, because no semicolon needed in the end of definition: #define BZS_TOTAL_OUT(bzs) \ bzs->total_out_lo32; This error found in version 2.3.5 and 2.4.2. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-16 21:29 Message: Logged In: YES user_id=33168 Thanks! Fixed in head and 2.4 (we don't maintain 2.3 any longer). Committed revision 42080. Committed revision 42081. (2.4) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1407069&group_id=5470 From noreply at sourceforge.net Tue Jan 17 06:35:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 Jan 2006 21:35:55 -0800 Subject: [ python-Bugs-1349106 ] email.Generators does not separates headers with "\r\n" Message-ID: Bugs item #1349106, was opened at 2005-11-05 11:50 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349106&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Manlio Perillo (manlioperillo) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Generators does not separates headers with "\r\n" Initial Comment: Regards. The email.Generator module does not separates headers with "\r\n". Manlio Perillo ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-17 00:35 Message: Logged In: YES user_id=12800 Correct; this is by design. If you're worried about protocols such as RFC 2821 requiring \r\n line endings, don't. The smtplib module automatically ensures proper line endings for the on-the-wire communication. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349106&group_id=5470 From noreply at sourceforge.net Tue Jan 17 07:00:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 16 Jan 2006 22:00:11 -0800 Subject: [ python-Bugs-1347874 ] FeedParser does not comply with RFC2822 Message-ID: Bugs item #1347874, was opened at 2005-11-03 21:58 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1347874&group_id=5470 Please note that this message will contain 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 Submitted By: Julian Phillips (quantumfyre) Assigned to: Barry A. Warsaw (bwarsaw) Summary: FeedParser does not comply with RFC2822 Initial Comment: FeedParser (from Lib/email/FeedParser.py) uses the regular expression: ^(From |[\041-\071\073-\176]{2,}:|[\t ]) to recognise Mail headers. However RFC2822 says: field-name := 1*ftext which would give the regular expression: ^(From |[\041-\071\073-\176]{1,}:|[\t ]) This causes mails that use single character header field names to be parsed incorrectly. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-17 01:00 Message: Logged In: YES user_id=12800 Fixed as suggested. r42083 in the trunk (Python 2.5) r42084 in the release24-maint branch (Python 2.4) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1347874&group_id=5470 From noreply at sourceforge.net Tue Jan 17 10:20:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 Jan 2006 01:20:17 -0800 Subject: [ python-Bugs-1349106 ] email.Generators does not separates headers with "\r\n" Message-ID: Bugs item #1349106, was opened at 2005-11-05 16:50 Message generated for change (Comment added) made by manlioperillo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349106&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Manlio Perillo (manlioperillo) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Generators does not separates headers with "\r\n" Initial Comment: Regards. The email.Generator module does not separates headers with "\r\n". Manlio Perillo ---------------------------------------------------------------------- >Comment By: Manlio Perillo (manlioperillo) Date: 2006-01-17 09:20 Message: Logged In: YES user_id=1054957 Ok, thanks. But what if I don't use the smtplib module? I discovered the bug because I have written a small NNTP server with twisted, using email module for parsing... ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-17 05:35 Message: Logged In: YES user_id=12800 Correct; this is by design. If you're worried about protocols such as RFC 2821 requiring \r\n line endings, don't. The smtplib module automatically ensures proper line endings for the on-the-wire communication. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349106&group_id=5470 From noreply at sourceforge.net Tue Jan 17 13:54:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 Jan 2006 04:54:06 -0800 Subject: [ python-Bugs-1349106 ] email.Generators does not separates headers with "\r\n" Message-ID: Bugs item #1349106, was opened at 2005-11-05 11:50 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349106&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Manlio Perillo (manlioperillo) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Generators does not separates headers with "\r\n" Initial Comment: Regards. The email.Generator module does not separates headers with "\r\n". Manlio Perillo ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-17 07:54 Message: Logged In: YES user_id=12800 The module that speaks the wire protocol should do the conversion. IMO, there's no other way to guarantee that you're RFC compliant. You could be getting your data from the email package, but you could be getting it from anywhere else, and /that/ source may not be RFC line ended either. Since you can't change every possible source of data for NNTP or SMTP, your network interface must guarantee conformance. ---------------------------------------------------------------------- Comment By: Manlio Perillo (manlioperillo) Date: 2006-01-17 04:20 Message: Logged In: YES user_id=1054957 Ok, thanks. But what if I don't use the smtplib module? I discovered the bug because I have written a small NNTP server with twisted, using email module for parsing... ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-17 00:35 Message: Logged In: YES user_id=12800 Correct; this is by design. If you're worried about protocols such as RFC 2821 requiring \r\n line endings, don't. The smtplib module automatically ensures proper line endings for the on-the-wire communication. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349106&group_id=5470 From noreply at sourceforge.net Tue Jan 17 17:26:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 Jan 2006 08:26:52 -0800 Subject: [ python-Bugs-1349106 ] email.Generators does not separates headers with "\r\n" Message-ID: Bugs item #1349106, was opened at 2005-11-05 16:50 Message generated for change (Comment added) made by manlioperillo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349106&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Manlio Perillo (manlioperillo) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Generators does not separates headers with "\r\n" Initial Comment: Regards. The email.Generator module does not separates headers with "\r\n". Manlio Perillo ---------------------------------------------------------------------- >Comment By: Manlio Perillo (manlioperillo) Date: 2006-01-17 16:26 Message: Logged In: YES user_id=1054957 I do not agree here (but I'm not an expert). First - the documentation says: """The email package attempts to be as RFC-compliant as possible, supporting in addition to RFC 2822, such MIME-related RFCs as RFC 2045, RFC 2046, RFC 2047, and RFC 2231. """ But, as I can see, the generated email does not conform to RFC 2822. Second - I use email package as a "filter". read raw email text, do some processing, generate raw email text. Really, I don't understand why generated headers don't are separed by '\r\n' and one must rely on an external tool for the right conversion. Thanks. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-17 12:54 Message: Logged In: YES user_id=12800 The module that speaks the wire protocol should do the conversion. IMO, there's no other way to guarantee that you're RFC compliant. You could be getting your data from the email package, but you could be getting it from anywhere else, and /that/ source may not be RFC line ended either. Since you can't change every possible source of data for NNTP or SMTP, your network interface must guarantee conformance. ---------------------------------------------------------------------- Comment By: Manlio Perillo (manlioperillo) Date: 2006-01-17 09:20 Message: Logged In: YES user_id=1054957 Ok, thanks. But what if I don't use the smtplib module? I discovered the bug because I have written a small NNTP server with twisted, using email module for parsing... ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-17 05:35 Message: Logged In: YES user_id=12800 Correct; this is by design. If you're worried about protocols such as RFC 2821 requiring \r\n line endings, don't. The smtplib module automatically ensures proper line endings for the on-the-wire communication. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349106&group_id=5470 From noreply at sourceforge.net Tue Jan 17 22:53:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 Jan 2006 13:53:43 -0800 Subject: [ python-Bugs-890010 ] Odd warning behaviors Message-ID: Bugs item #890010, was opened at 2004-02-03 17:25 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=890010&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) >Assigned to: Georg Brandl (birkenfeld) Summary: Odd warning behaviors Initial Comment: This is from Evan Simpson, on the zope-dev list. The bulk have to do with what happens if __name__ is set to None: Subject: Re: [Zope-dev] Re: Zope 2.7.0 rc2 + python 2.3.3 problem http://mail.zope.org/mailman/listinfo/zope-dev Python 2.3.3 (#2, Jan 13 2004, 00:47:05) [GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> range(1.0) __main__:1: DeprecationWarning: integer argument expected, got float [0] >>> So far, so good. However: Python 2.3.3 (#2, Jan 13 2004, 00:47:05) [GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> __name__=None >>> range(1.0) [] >>> 1+1 Traceback (most recent call last): File "/usr/lib/python2.3/warnings.py", line 57, in warn warn_explicit(message, category, filename, lineno, module, registry) File "/usr/lib/python2.3/warnings.py", line 63, in warn_explicit if module[-3:].lower() == ".py": TypeError: unsubscriptable object >>> ...and... Python 2.3.3 (#2, Jan 13 2004, 00:47:05) [GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import warnings >>> warnings.simplefilter("error", category=DeprecationWarning) >>> range(1.0) [] >>> 1+1 Traceback (most recent call last): File "/usr/lib/python2.3/warnings.py", line 57, in warn warn_explicit(message, category, filename, lineno, module, registry) File "/usr/lib/python2.3/warnings.py", line 92, in warn_explicit raise message DeprecationWarning: integer argument expected, got float >>> ...and... Python 2.3.3 (#2, Jan 13 2004, 00:47:05) [GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import pdb >>> __name__ = None >>> pdb.run('range(1.0)') > (1)?() (Pdb) s --Call-- > /usr/lib/python2.3/warnings.py(24)warn() -> def warn(message, category=None, stacklevel=1): (Pdb) r --Return-- /usr/lib/python2.3/bdb.py:302: RuntimeWarning: tp_compare didn't return -1 or -2 for exception i = max(0, len(stack) - 1) [traceback snipped] Looks like something isn't properly propagating exceptions. Cheers, Evan @ 4-am ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-01-17 16:53 Message: Logged In: YES user_id=31435 No, it's certainly not OK for range(1.0) to raise either DeprecationWarning or TypeError depending on what __name__ happens to be. But I may not understand what you mean. This is a screen scrape from current SVN trunk, on Windows: >>> __name__ = None; range(1.0) None:1: DeprecationWarning: integer argument expected, got float [0] I don't see TypeError there, so I'm not sure what """ In current SVN heads, range(1.0) gives DeprecationWarning and __name__=None; range(1.0) gives TypeError. """ means. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 17:28 Message: Logged In: YES user_id=1188172 In current SVN heads, range(1.0) gives DeprecationWarning and __name__=None; range(1.0) gives TypeError. Is this okay? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-02-16 19:51 Message: Logged In: YES user_id=31435 I'm listening, but with half of part of one ear. Have to agree convertsimple() was wrong in these cases, but can't make time for more than that. Reassigned to Jeremy, partly at random (his is one of the names that shows up as a recent getargs.c changer). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-02-12 09:09 Message: Logged In: YES user_id=6656 Is anyone listening? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-02-04 10:05 Message: Logged In: YES user_id=6656 Oops, wrong file. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-02-04 10:03 Message: Logged In: YES user_id=6656 How's this? It's horrible, but I'm not sure that can be avoided. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-02-04 08:22 Message: Logged In: YES user_id=6656 OK, the problem is that returning NULL from getargs.c:convertsimple indicates *success* (argh!). Fixing that provokes weird errors from handle_range_longs. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-02-04 07:10 Message: Logged In: YES user_id=6656 Might this be specific to range()? [mwh at pc150 build]$ ./python.exe -Werror Python 2.4a0 (#3, Feb 3 2004, 19:23:25) [GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> range(5.0) [] range()'s argument handling is somewhat odd ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=890010&group_id=5470 From noreply at sourceforge.net Wed Jan 18 00:47:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 17 Jan 2006 15:47:15 -0800 Subject: [ python-Bugs-1349106 ] email.Generators does not separates headers with "\r\n" Message-ID: Bugs item #1349106, was opened at 2005-11-05 11:50 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349106&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Manlio Perillo (manlioperillo) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Generators does not separates headers with "\r\n" Initial Comment: Regards. The email.Generator module does not separates headers with "\r\n". Manlio Perillo ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-17 18:47 Message: Logged In: YES user_id=12800 I hear what you're saying, but so far, it has been more convenient for developers when the generator outputs native line endings. I can see a case for a flag or other switch on the Generator instance to force RFC 2822 line endings. I would suggest joining the email-sig and posting a request there so the issue can be discussed as an RFE. ---------------------------------------------------------------------- Comment By: Manlio Perillo (manlioperillo) Date: 2006-01-17 11:26 Message: Logged In: YES user_id=1054957 I do not agree here (but I'm not an expert). First - the documentation says: """The email package attempts to be as RFC-compliant as possible, supporting in addition to RFC 2822, such MIME-related RFCs as RFC 2045, RFC 2046, RFC 2047, and RFC 2231. """ But, as I can see, the generated email does not conform to RFC 2822. Second - I use email package as a "filter". read raw email text, do some processing, generate raw email text. Really, I don't understand why generated headers don't are separed by '\r\n' and one must rely on an external tool for the right conversion. Thanks. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-17 07:54 Message: Logged In: YES user_id=12800 The module that speaks the wire protocol should do the conversion. IMO, there's no other way to guarantee that you're RFC compliant. You could be getting your data from the email package, but you could be getting it from anywhere else, and /that/ source may not be RFC line ended either. Since you can't change every possible source of data for NNTP or SMTP, your network interface must guarantee conformance. ---------------------------------------------------------------------- Comment By: Manlio Perillo (manlioperillo) Date: 2006-01-17 04:20 Message: Logged In: YES user_id=1054957 Ok, thanks. But what if I don't use the smtplib module? I discovered the bug because I have written a small NNTP server with twisted, using email module for parsing... ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-17 00:35 Message: Logged In: YES user_id=12800 Correct; this is by design. If you're worried about protocols such as RFC 2821 requiring \r\n line endings, don't. The smtplib module automatically ensures proper line endings for the on-the-wire communication. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349106&group_id=5470 From noreply at sourceforge.net Wed Jan 18 19:38:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 Jan 2006 10:38:04 -0800 Subject: [ python-Bugs-890010 ] Odd warning behaviors Message-ID: Bugs item #890010, was opened at 2004-02-03 23:25 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=890010&group_id=5470 Please note that this message 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 Submitted By: Tim Peters (tim_one) Assigned to: Georg Brandl (birkenfeld) Summary: Odd warning behaviors Initial Comment: This is from Evan Simpson, on the zope-dev list. The bulk have to do with what happens if __name__ is set to None: Subject: Re: [Zope-dev] Re: Zope 2.7.0 rc2 + python 2.3.3 problem http://mail.zope.org/mailman/listinfo/zope-dev Python 2.3.3 (#2, Jan 13 2004, 00:47:05) [GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> range(1.0) __main__:1: DeprecationWarning: integer argument expected, got float [0] >>> So far, so good. However: Python 2.3.3 (#2, Jan 13 2004, 00:47:05) [GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> __name__=None >>> range(1.0) [] >>> 1+1 Traceback (most recent call last): File "/usr/lib/python2.3/warnings.py", line 57, in warn warn_explicit(message, category, filename, lineno, module, registry) File "/usr/lib/python2.3/warnings.py", line 63, in warn_explicit if module[-3:].lower() == ".py": TypeError: unsubscriptable object >>> ...and... Python 2.3.3 (#2, Jan 13 2004, 00:47:05) [GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import warnings >>> warnings.simplefilter("error", category=DeprecationWarning) >>> range(1.0) [] >>> 1+1 Traceback (most recent call last): File "/usr/lib/python2.3/warnings.py", line 57, in warn warn_explicit(message, category, filename, lineno, module, registry) File "/usr/lib/python2.3/warnings.py", line 92, in warn_explicit raise message DeprecationWarning: integer argument expected, got float >>> ...and... Python 2.3.3 (#2, Jan 13 2004, 00:47:05) [GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import pdb >>> __name__ = None >>> pdb.run('range(1.0)') > (1)?() (Pdb) s --Call-- > /usr/lib/python2.3/warnings.py(24)warn() -> def warn(message, category=None, stacklevel=1): (Pdb) r --Return-- /usr/lib/python2.3/bdb.py:302: RuntimeWarning: tp_compare didn't return -1 or -2 for exception i = max(0, len(stack) - 1) [traceback snipped] Looks like something isn't properly propagating exceptions. Cheers, Evan @ 4-am ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-18 19:38 Message: Logged In: YES user_id=1188172 I fixed warnings inbetween, see revision 42028. So I guess this can be closed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-01-17 22:53 Message: Logged In: YES user_id=31435 No, it's certainly not OK for range(1.0) to raise either DeprecationWarning or TypeError depending on what __name__ happens to be. But I may not understand what you mean. This is a screen scrape from current SVN trunk, on Windows: >>> __name__ = None; range(1.0) None:1: DeprecationWarning: integer argument expected, got float [0] I don't see TypeError there, so I'm not sure what """ In current SVN heads, range(1.0) gives DeprecationWarning and __name__=None; range(1.0) gives TypeError. """ means. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 23:28 Message: Logged In: YES user_id=1188172 In current SVN heads, range(1.0) gives DeprecationWarning and __name__=None; range(1.0) gives TypeError. Is this okay? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-02-17 01:51 Message: Logged In: YES user_id=31435 I'm listening, but with half of part of one ear. Have to agree convertsimple() was wrong in these cases, but can't make time for more than that. Reassigned to Jeremy, partly at random (his is one of the names that shows up as a recent getargs.c changer). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-02-12 15:09 Message: Logged In: YES user_id=6656 Is anyone listening? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-02-04 16:05 Message: Logged In: YES user_id=6656 Oops, wrong file. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-02-04 16:03 Message: Logged In: YES user_id=6656 How's this? It's horrible, but I'm not sure that can be avoided. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-02-04 14:22 Message: Logged In: YES user_id=6656 OK, the problem is that returning NULL from getargs.c:convertsimple indicates *success* (argh!). Fixing that provokes weird errors from handle_range_longs. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-02-04 13:10 Message: Logged In: YES user_id=6656 Might this be specific to range()? [mwh at pc150 build]$ ./python.exe -Werror Python 2.4a0 (#3, Feb 3 2004, 19:23:25) [GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> range(5.0) [] range()'s argument handling is somewhat odd ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=890010&group_id=5470 From noreply at sourceforge.net Wed Jan 18 21:55:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 Jan 2006 12:55:38 -0800 Subject: [ python-Bugs-1409403 ] email.Message should supress warning from uu.decode Message-ID: Bugs item #1409403, was opened at 2006-01-18 12:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409403&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Sapiro (msapiro) Assigned to: Nobody/Anonymous (nobody) Summary: email.Message should supress warning from uu.decode Initial Comment: part.get_payload(decode=True) of a uuencoded email.Message() sub-part can result in warning messages being written to sys.stderr. These warnings occur when pad characters other than encoded zeros were used to fill out the last encoded line to a multiple of 4 characters (+1 for the count character). Such non-zero padded encoded parts are produced by some current versions of Eudora and perhaps other MUAs. The warnings are unnecessary in this case and cause problems for other software, e.g., Mailman. get_payload(decode=True) calls uu.decode to actually decode the part payload. It should specify the quiet=True flag in this call to supress the warning. A suggested patch against Python 2.4.2 is attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409403&group_id=5470 From noreply at sourceforge.net Wed Jan 18 21:57:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 Jan 2006 12:57:12 -0800 Subject: [ python-Bugs-1409403 ] email.Message should supress warning from uu.decode Message-ID: Bugs item #1409403, was opened at 2006-01-18 12:55 Message generated for change (Settings changed) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409403&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Sapiro (msapiro) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Message should supress warning from uu.decode Initial Comment: part.get_payload(decode=True) of a uuencoded email.Message() sub-part can result in warning messages being written to sys.stderr. These warnings occur when pad characters other than encoded zeros were used to fill out the last encoded line to a multiple of 4 characters (+1 for the count character). Such non-zero padded encoded parts are produced by some current versions of Eudora and perhaps other MUAs. The warnings are unnecessary in this case and cause problems for other software, e.g., Mailman. get_payload(decode=True) calls uu.decode to actually decode the part payload. It should specify the quiet=True flag in this call to supress the warning. A suggested patch against Python 2.4.2 is attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409403&group_id=5470 From noreply at sourceforge.net Wed Jan 18 22:57:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 Jan 2006 13:57:21 -0800 Subject: [ python-Bugs-1409443 ] frame->f_lasti not always correct Message-ID: Bugs item #1409443, was opened at 2006-01-18 21:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409443&group_id=5470 Please note that this message 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 Submitted By: John Ehresman (jpe) Assigned to: Nobody/Anonymous (nobody) Summary: frame->f_lasti not always correct Initial Comment: Contrary to the comment in ceval.c, the f_lasti field is not always correct because it is not updated by the PREDICT / PREDICTED macros. This means that when a GET_ITER is followed by a FOR_ITER, f_lasti will be left at the index of the GET_ITER the first time FOR_ITER is executed. I don't think this is a problem for YIELD_VALUE because it's not predicted to follow any other opcode. I'm running into this when examining bytecode in calling frames within a debugger callback. I suggest either documenting that f_lasti may be incorrect or adjusting it in the PREDICTED macro. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409443&group_id=5470 From noreply at sourceforge.net Wed Jan 18 23:09:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 Jan 2006 14:09:59 -0800 Subject: [ python-Bugs-1409455 ] email.Message.set_payload followed by bad result get_payload Message-ID: Bugs item #1409455, was opened at 2006-01-18 14:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409455&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Sapiro (msapiro) Assigned to: Nobody/Anonymous (nobody) Summary: email.Message.set_payload followed by bad result get_payload Initial Comment: Under certain circumstances, in particular when charset is 'iso-8859-1', where msg is an email.Message() instance, msg.set_payload(text, charset) 'apparently' encodes the text as quoted-printable and adds a Content-Transfer-Encoding: quoted-printable header to msg. I say 'apparently' because if one prints msg or creates a Generator instance and writes msg to a file, the message is printed/written as a correct, quoted-printable encoded message, but text = msg._payload or text = msg.get_payload() gives the original text, not quoted-printable encoded, and text = msg.get_payload(decode=True) gives a quoted-printable decoding of the original text which is munged if the original text included '=' in some ways. This is causing problems in Mailman which are currently worked around by flagging if the payload was set by set_payload() and not subsequently 'decoding' in that case, but it would be better if set_payload()/get_payload() worked properly. A script is attached which illustrates the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409455&group_id=5470 From noreply at sourceforge.net Wed Jan 18 23:19:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 Jan 2006 14:19:07 -0800 Subject: [ python-Bugs-1409460 ] email.Utils.parseaddr() gives arcane result Message-ID: Bugs item #1409460, was opened at 2006-01-18 14:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409460&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Sapiro (msapiro) Assigned to: Nobody/Anonymous (nobody) Summary: email.Utils.parseaddr() gives arcane result Initial Comment: email.Utils.parseaddr('Real Name ((comment)) ') returns ('comment ', 'Real') Granted the string above is invalid as RFC 2822 does not allow parentheses within comments, but most mail agents seem to at least take the contents of the angle brackets as the address in this case. rfc822.parseaddr() returns the same result in this case. If these functions aren't going to return their respective failure indication in this case, I think they should at least return 'addr... at example.com' as the second item of the returned tuple. Note that parseaddr('Real Name ((comment))') does return ('Real Name', 'addr... at example.com') as 'expected'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409460&group_id=5470 From noreply at sourceforge.net Thu Jan 19 00:25:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 Jan 2006 15:25:30 -0800 Subject: [ python-Bugs-1409455 ] email.Message.set_payload followed by bad result get_payload Message-ID: Bugs item #1409455, was opened at 2006-01-18 17:09 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409455&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Sapiro (msapiro) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Message.set_payload followed by bad result get_payload Initial Comment: Under certain circumstances, in particular when charset is 'iso-8859-1', where msg is an email.Message() instance, msg.set_payload(text, charset) 'apparently' encodes the text as quoted-printable and adds a Content-Transfer-Encoding: quoted-printable header to msg. I say 'apparently' because if one prints msg or creates a Generator instance and writes msg to a file, the message is printed/written as a correct, quoted-printable encoded message, but text = msg._payload or text = msg.get_payload() gives the original text, not quoted-printable encoded, and text = msg.get_payload(decode=True) gives a quoted-printable decoding of the original text which is munged if the original text included '=' in some ways. This is causing problems in Mailman which are currently worked around by flagging if the payload was set by set_payload() and not subsequently 'decoding' in that case, but it would be better if set_payload()/get_payload() worked properly. A script is attached which illustrates the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409455&group_id=5470 From noreply at sourceforge.net Thu Jan 19 00:25:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 Jan 2006 15:25:54 -0800 Subject: [ python-Bugs-1409460 ] email.Utils.parseaddr() gives arcane result Message-ID: Bugs item #1409460, was opened at 2006-01-18 17:19 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409460&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Sapiro (msapiro) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Utils.parseaddr() gives arcane result Initial Comment: email.Utils.parseaddr('Real Name ((comment)) ') returns ('comment ', 'Real') Granted the string above is invalid as RFC 2822 does not allow parentheses within comments, but most mail agents seem to at least take the contents of the angle brackets as the address in this case. rfc822.parseaddr() returns the same result in this case. If these functions aren't going to return their respective failure indication in this case, I think they should at least return 'addr... at example.com' as the second item of the returned tuple. Note that parseaddr('Real Name ((comment))') does return ('Real Name', 'addr... at example.com') as 'expected'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409460&group_id=5470 From noreply at sourceforge.net Thu Jan 19 01:35:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 Jan 2006 16:35:46 -0800 Subject: [ python-Bugs-1409538 ] email.Charset.py CODEC_MAP no longer requires 'japanese' Message-ID: Bugs item #1409538, was opened at 2006-01-19 00: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=1409538&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: email.Charset.py CODEC_MAP no longer requires 'japanese' Initial Comment: The commonly used JapaneseCodecs no longer requires 'japanese' prefix in codec specification. On the other hand if a user install CJKCodecs instead of JapaneseCodecs, 'japanese' prefix cause error. This was already fixed in email-3.0 (Python 2.4) but should be fixed in email-2.5.x if we want to support mailman-2.2 for Python 2.3. It looks like 'korean' can also be stripped. See attached patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409538&group_id=5470 From noreply at sourceforge.net Thu Jan 19 06:32:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 Jan 2006 21:32:51 -0800 Subject: [ python-Bugs-1409443 ] frame->f_lasti not always correct Message-ID: Bugs item #1409443, was opened at 2006-01-18 13:57 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409443&group_id=5470 Please note that this message 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 Submitted By: John Ehresman (jpe) >Assigned to: Raymond Hettinger (rhettinger) Summary: frame->f_lasti not always correct Initial Comment: Contrary to the comment in ceval.c, the f_lasti field is not always correct because it is not updated by the PREDICT / PREDICTED macros. This means that when a GET_ITER is followed by a FOR_ITER, f_lasti will be left at the index of the GET_ITER the first time FOR_ITER is executed. I don't think this is a problem for YIELD_VALUE because it's not predicted to follow any other opcode. I'm running into this when examining bytecode in calling frames within a debugger callback. I suggest either documenting that f_lasti may be incorrect or adjusting it in the PREDICTED macro. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-18 21:32 Message: Logged In: YES user_id=33168 Raymond? Given that PREDICTED was added for performance, I would lean toward updating the doc. I didn't look at the code, but I'm pretty sure John's description is accurate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409443&group_id=5470 From noreply at sourceforge.net Thu Jan 19 08:12:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 18 Jan 2006 23:12:33 -0800 Subject: [ python-Bugs-1391872 ] floating point literals don't work in non-US locale in 2.5 Message-ID: Bugs item #1391872, was opened at 2005-12-28 03:01 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&group_id=5470 Please note that this message 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 Submitted By: Fredrik Lundh (effbot) Assigned to: Neal Norwitz (nnorwitz) Summary: floating point literals don't work in non-US locale in 2.5 Initial Comment: According to reports on comp.lang.python, the current SVN trunk fails to handle floating point literals if the locale is changed: >>> import locale >>> locale.setlocale(locale.LC_ALL, '') 'German_Germany.1252' >>> 3.141592 3.0 This works just fine in 2.4.2. See the later portions of the thread "build curiosities of svn head (on WinXP)" for more details: http://groups.google.com/group/comp.lang.python/browse_ frm/thread/226584dd47047bb6/e609cb1a0d47e98f ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-01-18 23:12 Message: Logged In: YES user_id=357491 This still fails on OS X 10.4.4: AssertionError: using eval('3.14') failed for eu_ES This is using rev. 42094. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-29 12:37 Message: Logged In: YES user_id=38376 Verified and fixed in SVN. Assinging to Neal, in case he wants to add an extra locale test pass to his build robot. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-29 10:52 Message: Logged In: YES user_id=38376 Looks good to me. I'll check this in shortly. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-12-29 00:22 Message: Logged In: YES user_id=55188 The new patch tests it along with other locale-dependent tests on test__locale. How about this? ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-28 11:00 Message: Logged In: YES user_id=38376 I'm not sure you can make too many assumptions about the locale in the test suite, but I'm pretty sure that it would be a good idea to let your "build robot" run the test suite twice; once with the standard C locale, and once with a non-US locale (e.g. sv_SE.utf8 which does include some odd characters, different date and money formats, and a decimal comma). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-28 10:16 Message: Logged In: YES user_id=33168 Wow, I thought for sure I broke it with my recent patch to remove support for hex floats. But it looks like just an AST problem (which I can be blamed for too :-). The patch looks fine, but could you add tests so this doesn't happen again. Thanks! I'll be back in a week and try to fix it then if no one gets back to it. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-12-28 06:04 Message: Logged In: YES user_id=55188 Okay. Here's a fix. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-12-28 05:41 Message: Logged In: YES user_id=55188 This looks like a bug introduced by AST import; r39757 is okay but r39762 has such an error. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-12-28 03:02 Message: Logged In: YES user_id=38376 I just confirmed this on Unix: $ export LANG=sv_SE.utf8 $ ./python Python 2.5a0 (41806M, Dec 25 2005, 12:12:29) [GCC 2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 3.14 3.1400000000000001 >>> import locale >>> locale.setlocale(locale.LC_ALL, "") 'sv_SE.utf8' >>> 3.14 3.0 >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&group_id=5470 From noreply at sourceforge.net Thu Jan 19 13:58:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 19 Jan 2006 04:58:22 -0800 Subject: [ python-Bugs-1409538 ] email.Charset.py CODEC_MAP no longer requires 'japanese' Message-ID: Bugs item #1409538, was opened at 2006-01-18 19:35 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409538&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Charset.py CODEC_MAP no longer requires 'japanese' Initial Comment: The commonly used JapaneseCodecs no longer requires 'japanese' prefix in codec specification. On the other hand if a user install CJKCodecs instead of JapaneseCodecs, 'japanese' prefix cause error. This was already fixed in email-3.0 (Python 2.4) but should be fixed in email-2.5.x if we want to support mailman-2.2 for Python 2.3. It looks like 'korean' can also be stripped. See attached patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409538&group_id=5470 From noreply at sourceforge.net Fri Jan 20 10:08:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 01:08:14 -0800 Subject: [ python-Bugs-1371247 ] locale.windows_locale Message-ID: Bugs item #1371247, was opened at 2005-12-01 22:50 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1371247&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: locale.windows_locale Initial Comment: from locale.py: # # this maps windows language identifiers (as used on Windows 95 and # earlier) to locale strings. # # NOTE: this mapping is incomplete. If your language is missing, please # submit a bug report to Python bug manager, which you can find via: # http://www.python.org/dev/ # Make sure you include the missing language identifier and the suggested # locale code. # The complete mapping table can be found here: http://www.dx21.com/SCRIPTING/VBSCRIPT/LCID.ASP ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 10:08 Message: Logged In: YES user_id=1188172 Thanks, fixed in rev 42100, 42101. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2006-01-14 23:40 Message: Logged In: YES user_id=174455 See patch 1406159: http://sourceforge.net/tracker/index.php?func=detail&aid=1406159&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2005-12-01 23:30 Message: Logged In: YES user_id=731668 I believe there's a small typo in that page. Spanish 1034 says hex 0x0C0A when hex(1034) is 0x040A The rest seems correct (hex and int values match). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1371247&group_id=5470 From noreply at sourceforge.net Fri Jan 20 10:15:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 01:15:59 -0800 Subject: [ python-Bugs-1396471 ] file.tell() returns illegal value on Windows Message-ID: Bugs item #1396471, was opened at 2006-01-04 02:53 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396471&group_id=5470 Please note that this 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: Fixed Priority: 7 Submitted By: Tom Goddard (tom_goddard) Assigned to: Nobody/Anonymous (nobody) Summary: file.tell() returns illegal value on Windows Initial Comment: The file tell() method returns an illegal value that causes an exception when passed to seek(). This happens on Windows when a file that contains unix-style newlines '\n' is opened and read in text mode 'r'. Below is code that produces the problem on Windows 2.4.2 in an IDLE shell. The bug does not occur when using mode 'rU' or 'rb'. But I expect correct behaviour with mode 'r'. My understanding is that 'rU' translates line endings to '\n' in the returned string while mode 'r' still correctly reads the lines using readline(), recognizing all 3 common endline conventions, but does not translate (ie includes \n\r or \r or \n in returned string). The error in the tell() return value depends on how long the file is. Changing the 'more\n'*10 line in the example code will cause different incorrect return values. Previous bug reports have mentioned problems with tell/seek when using file iterators, the file.next() method and the "for line in file:" construct. This bug is different and just involves readline() and tell() with mode 'r'. Example code tellbug.py follows: wf = open('testdata', 'wb') wf.write('01234\n56789\n'+ 'more\n'*10) wf.close() f = open('testdata', 'r') f.readline() t = f.tell() print t f.seek(t) ------- Running gives: >>> execfile('tellbug.py') -5 Traceback (most recent call last): File "", line 1, in -toplevel- execfile('tellbug.py') File "tellbug.py", line 9, in -toplevel- f.seek(t) IOError: [Errno 22] Invalid argument ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 10:15 Message: Logged In: YES user_id=1188172 Documented as a Windows bug in revisions 42102,42103. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2006-01-16 04:24 Message: Logged In: YES user_id=174455 I have done some additional research on this. It appears the bug is in ftell of the windows c-library and it seems to be a 'known problem'. See: http://www.mathworks.com/access/helpdesk/help/techdoc/ref/ftell.html More here: http://www.cygwin.com/faq/faq.api.html http://gnuwin32.sourceforge.net/compile.html (search for ftell in both cases) Also see: http://sourceforge.net/tracker/index.php?func=detail&aid=1381717&group_id=5470&atid=105470 So even though the file isn't opened with 'rt' I gather from Tim Peter's remark about 't' on windows that the default is 't' anyway unless you really try. So this example is *exactly* what the matlab-people found. That is nice to know I guess but it doesn't really help to solve the problem. It seems to me there are three solutions. 1. ftell could be fixed for unix-files on windows.* Not very likely to happen soon. 2. Python could special-case this for this specific scenario. Way beyond my capabilities and probably too much hassle in any case especially since the 'fix' is so easy (just open with 'rb'). 3. Leave it as is but document it. I have submitted a (doc-)patch 1407021 (http://sourceforge.net/tracker/index.php?func=detail&aid=1407021&group_id=5470&atid=305470) for the library reference (libstdtypes.tex) that reads: Please note that tell() can return illegal values (after an fgets()) on Windows when reading files with UNIX-style line-endings. Use 'rb'-mode to circumvent this problem. * MS provides this note in the compatibility section of the c-runtime libraries: "Note: In this version of Visual C++, UNIX compatibility information has been removed from the function descriptions." In case your wondering what 'this version' is: VS.NET and VS 6.0. Apperantly there were no other 'previous versions'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396471&group_id=5470 From noreply at sourceforge.net Fri Jan 20 11:05:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 02:05:30 -0800 Subject: [ python-Bugs-1349106 ] email.Generators does not separates headers with "\r\n" Message-ID: Bugs item #1349106, was opened at 2005-11-05 16:50 Message generated for change (Comment added) made by manlioperillo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349106&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Manlio Perillo (manlioperillo) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Generators does not separates headers with "\r\n" Initial Comment: Regards. The email.Generator module does not separates headers with "\r\n". Manlio Perillo ---------------------------------------------------------------------- >Comment By: Manlio Perillo (manlioperillo) Date: 2006-01-20 10:05 Message: Logged In: YES user_id=1054957 But the generator does not output in native line endings! On Windows: >>> from email.Message import Message >>> msg = Message() >>> msg["From"] = "me" >>> msg["To"] = "you" >>> print repr(msg.as_string()) 'From: me\nTo: you\n\n' ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-17 23:47 Message: Logged In: YES user_id=12800 I hear what you're saying, but so far, it has been more convenient for developers when the generator outputs native line endings. I can see a case for a flag or other switch on the Generator instance to force RFC 2822 line endings. I would suggest joining the email-sig and posting a request there so the issue can be discussed as an RFE. ---------------------------------------------------------------------- Comment By: Manlio Perillo (manlioperillo) Date: 2006-01-17 16:26 Message: Logged In: YES user_id=1054957 I do not agree here (but I'm not an expert). First - the documentation says: """The email package attempts to be as RFC-compliant as possible, supporting in addition to RFC 2822, such MIME-related RFCs as RFC 2045, RFC 2046, RFC 2047, and RFC 2231. """ But, as I can see, the generated email does not conform to RFC 2822. Second - I use email package as a "filter". read raw email text, do some processing, generate raw email text. Really, I don't understand why generated headers don't are separed by '\r\n' and one must rely on an external tool for the right conversion. Thanks. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-17 12:54 Message: Logged In: YES user_id=12800 The module that speaks the wire protocol should do the conversion. IMO, there's no other way to guarantee that you're RFC compliant. You could be getting your data from the email package, but you could be getting it from anywhere else, and /that/ source may not be RFC line ended either. Since you can't change every possible source of data for NNTP or SMTP, your network interface must guarantee conformance. ---------------------------------------------------------------------- Comment By: Manlio Perillo (manlioperillo) Date: 2006-01-17 09:20 Message: Logged In: YES user_id=1054957 Ok, thanks. But what if I don't use the smtplib module? I discovered the bug because I have written a small NNTP server with twisted, using email module for parsing... ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-17 05:35 Message: Logged In: YES user_id=12800 Correct; this is by design. If you're worried about protocols such as RFC 2821 requiring \r\n line endings, don't. The smtplib module automatically ensures proper line endings for the on-the-wire communication. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349106&group_id=5470 From noreply at sourceforge.net Fri Jan 20 16:35:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 07:35:37 -0800 Subject: [ python-Bugs-1396471 ] file.tell() returns illegal value on Windows Message-ID: Bugs item #1396471, was opened at 2006-01-03 20:53 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396471&group_id=5470 Please note that this 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: Fixed Priority: 7 Submitted By: Tom Goddard (tom_goddard) Assigned to: Nobody/Anonymous (nobody) Summary: file.tell() returns illegal value on Windows Initial Comment: The file tell() method returns an illegal value that causes an exception when passed to seek(). This happens on Windows when a file that contains unix-style newlines '\n' is opened and read in text mode 'r'. Below is code that produces the problem on Windows 2.4.2 in an IDLE shell. The bug does not occur when using mode 'rU' or 'rb'. But I expect correct behaviour with mode 'r'. My understanding is that 'rU' translates line endings to '\n' in the returned string while mode 'r' still correctly reads the lines using readline(), recognizing all 3 common endline conventions, but does not translate (ie includes \n\r or \r or \n in returned string). The error in the tell() return value depends on how long the file is. Changing the 'more\n'*10 line in the example code will cause different incorrect return values. Previous bug reports have mentioned problems with tell/seek when using file iterators, the file.next() method and the "for line in file:" construct. This bug is different and just involves readline() and tell() with mode 'r'. Example code tellbug.py follows: wf = open('testdata', 'wb') wf.write('01234\n56789\n'+ 'more\n'*10) wf.close() f = open('testdata', 'r') f.readline() t = f.tell() print t f.seek(t) ------- Running gives: >>> execfile('tellbug.py') -5 Traceback (most recent call last): File "", line 1, in -toplevel- execfile('tellbug.py') File "tellbug.py", line 9, in -toplevel- f.seek(t) IOError: [Errno 22] Invalid argument ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-01-20 10:35 Message: Logged In: YES user_id=31435 Well, it's not a Windows bug. Platforms are allowed to insist on just about any restrictions they like for text files, and it's on the user's head if they open a non-text file in text mode. The C standard leaves all behavior undefined in such cases. Text files on Windows have \r\n line ends, and Windows isn't required to do anything in particular if a file with even one \n line end is opened in text mode. It so happens that a lot of things work the same way they work on Linux anyway, but not all. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 04:15 Message: Logged In: YES user_id=1188172 Documented as a Windows bug in revisions 42102,42103. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2006-01-15 22:24 Message: Logged In: YES user_id=174455 I have done some additional research on this. It appears the bug is in ftell of the windows c-library and it seems to be a 'known problem'. See: http://www.mathworks.com/access/helpdesk/help/techdoc/ref/ftell.html More here: http://www.cygwin.com/faq/faq.api.html http://gnuwin32.sourceforge.net/compile.html (search for ftell in both cases) Also see: http://sourceforge.net/tracker/index.php?func=detail&aid=1381717&group_id=5470&atid=105470 So even though the file isn't opened with 'rt' I gather from Tim Peter's remark about 't' on windows that the default is 't' anyway unless you really try. So this example is *exactly* what the matlab-people found. That is nice to know I guess but it doesn't really help to solve the problem. It seems to me there are three solutions. 1. ftell could be fixed for unix-files on windows.* Not very likely to happen soon. 2. Python could special-case this for this specific scenario. Way beyond my capabilities and probably too much hassle in any case especially since the 'fix' is so easy (just open with 'rb'). 3. Leave it as is but document it. I have submitted a (doc-)patch 1407021 (http://sourceforge.net/tracker/index.php?func=detail&aid=1407021&group_id=5470&atid=305470) for the library reference (libstdtypes.tex) that reads: Please note that tell() can return illegal values (after an fgets()) on Windows when reading files with UNIX-style line-endings. Use 'rb'-mode to circumvent this problem. * MS provides this note in the compatibility section of the c-runtime libraries: "Note: In this version of Visual C++, UNIX compatibility information has been removed from the function descriptions." In case your wondering what 'this version' is: VS.NET and VS 6.0. Apperantly there were no other 'previous versions'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396471&group_id=5470 From noreply at sourceforge.net Fri Jan 20 18:04:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 09:04:08 -0800 Subject: [ python-Bugs-1396471 ] file.tell() returns illegal value on Windows Message-ID: Bugs item #1396471, was opened at 2006-01-04 02:53 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396471&group_id=5470 Please note that this 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: Fixed Priority: 7 Submitted By: Tom Goddard (tom_goddard) Assigned to: Nobody/Anonymous (nobody) Summary: file.tell() returns illegal value on Windows Initial Comment: The file tell() method returns an illegal value that causes an exception when passed to seek(). This happens on Windows when a file that contains unix-style newlines '\n' is opened and read in text mode 'r'. Below is code that produces the problem on Windows 2.4.2 in an IDLE shell. The bug does not occur when using mode 'rU' or 'rb'. But I expect correct behaviour with mode 'r'. My understanding is that 'rU' translates line endings to '\n' in the returned string while mode 'r' still correctly reads the lines using readline(), recognizing all 3 common endline conventions, but does not translate (ie includes \n\r or \r or \n in returned string). The error in the tell() return value depends on how long the file is. Changing the 'more\n'*10 line in the example code will cause different incorrect return values. Previous bug reports have mentioned problems with tell/seek when using file iterators, the file.next() method and the "for line in file:" construct. This bug is different and just involves readline() and tell() with mode 'r'. Example code tellbug.py follows: wf = open('testdata', 'wb') wf.write('01234\n56789\n'+ 'more\n'*10) wf.close() f = open('testdata', 'r') f.readline() t = f.tell() print t f.seek(t) ------- Running gives: >>> execfile('tellbug.py') -5 Traceback (most recent call last): File "", line 1, in -toplevel- execfile('tellbug.py') File "tellbug.py", line 9, in -toplevel- f.seek(t) IOError: [Errno 22] Invalid argument ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 18:04 Message: Logged In: YES user_id=1188172 Acknowledged. I didn't use the word "bug" in the note anyway. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-01-20 16:35 Message: Logged In: YES user_id=31435 Well, it's not a Windows bug. Platforms are allowed to insist on just about any restrictions they like for text files, and it's on the user's head if they open a non-text file in text mode. The C standard leaves all behavior undefined in such cases. Text files on Windows have \r\n line ends, and Windows isn't required to do anything in particular if a file with even one \n line end is opened in text mode. It so happens that a lot of things work the same way they work on Linux anyway, but not all. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 10:15 Message: Logged In: YES user_id=1188172 Documented as a Windows bug in revisions 42102,42103. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2006-01-16 04:24 Message: Logged In: YES user_id=174455 I have done some additional research on this. It appears the bug is in ftell of the windows c-library and it seems to be a 'known problem'. See: http://www.mathworks.com/access/helpdesk/help/techdoc/ref/ftell.html More here: http://www.cygwin.com/faq/faq.api.html http://gnuwin32.sourceforge.net/compile.html (search for ftell in both cases) Also see: http://sourceforge.net/tracker/index.php?func=detail&aid=1381717&group_id=5470&atid=105470 So even though the file isn't opened with 'rt' I gather from Tim Peter's remark about 't' on windows that the default is 't' anyway unless you really try. So this example is *exactly* what the matlab-people found. That is nice to know I guess but it doesn't really help to solve the problem. It seems to me there are three solutions. 1. ftell could be fixed for unix-files on windows.* Not very likely to happen soon. 2. Python could special-case this for this specific scenario. Way beyond my capabilities and probably too much hassle in any case especially since the 'fix' is so easy (just open with 'rb'). 3. Leave it as is but document it. I have submitted a (doc-)patch 1407021 (http://sourceforge.net/tracker/index.php?func=detail&aid=1407021&group_id=5470&atid=305470) for the library reference (libstdtypes.tex) that reads: Please note that tell() can return illegal values (after an fgets()) on Windows when reading files with UNIX-style line-endings. Use 'rb'-mode to circumvent this problem. * MS provides this note in the compatibility section of the c-runtime libraries: "Note: In this version of Visual C++, UNIX compatibility information has been removed from the function descriptions." In case your wondering what 'this version' is: VS.NET and VS 6.0. Apperantly there were no other 'previous versions'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1396471&group_id=5470 From noreply at sourceforge.net Fri Jan 20 18:06:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 09:06:27 -0800 Subject: [ python-Bugs-1163367 ] correct/clarify documentation for super Message-ID: Bugs item #1163367, was opened at 2005-03-15 00:39 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: correct/clarify documentation for super Initial Comment: The current documentation for super is confusing. For instance, it says that it returns "the superclass of type" which is incorrect; it actually returns the next type in type's MRO. Well, to be truthful, it doesn't even do that; it returns a proxy object which makes that type's attributes available, but that's just another reason to fix the documentation. I suggest changing the wording to something like: """super(type[, object-or-type]) Return an object that exposes the attributes available through the type's superclasses, without exposing the attributes of the type itself. Attributes will be looked up using the normal resolution order, omitting the first class in the MRO (that is, the type itself). If the second argument is present, it should either be an instance of object, in which case isinstance(object-or-type, type) must be true, or it should be an instance of type, in which case issubclass(object-or-type, type) must be true. The typical use for this form of super is to call a cooperative superclass method: class C(B): def meth(self, arg): super(C, self).meth(arg) If the second argument to super is omitted, the super object returned will not expose any attributes directly. However, attributes will be accessible whenever the descriptor machinery is invoked, e.g. though explicit invocation of __get__. Note that super is undefined for implicit lookups using statements or operators such as "super(C, self)[name]". These must be spelled out with their explicit lookup, e.g. "super(C, self).__getitem__(name)". New in version 2.2. """ It's not perfect and I welcome suggestions for re-wording, but I think it's substantially more accurate about what super actually does. It also moves the "second argument omitted" situation to the end, since this is a vastly more uncommon use case. ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 18:06 Message: Logged In: YES user_id=1188172 See also Bug #973579 (which I closed as duplicate) for alternative wording. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470 From noreply at sourceforge.net Fri Jan 20 18:07:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 09:07:26 -0800 Subject: [ python-Bugs-973579 ] Doc error on super(cls,self) Message-ID: Bugs item #973579, was opened at 2004-06-16 00:43 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=973579&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: David MacQuigg (macquigg) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Doc error on super(cls,self) Initial Comment: In both the Library Reference, section 2.1, and in the Python 2.2 Quick Reference, page 19, the explanation for this function is: super( type[, object-or-type]) Returns the superclass of type. ... This is misleading. I could not get this function to work right until I realized that it is searching the entire MRO, not just the superclasses of 'type'. See comp.lang.python 6/11/04, same subject as above, for further discussion and an example. I think a better explanation would be: super(cls,self).m(arg) Calls method 'm' from a class in the MRO (Method Resolution Order) of 'self'. The selected class is the first one which is above 'cls' in the MRO and which contains 'm'. The 'super' built-in function actually returns not a class, but a 'super' object. This object can be saved, like a bound method, and later used to do a new search of the MRO for a different method to be applied to the saved instance. ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 18:07 Message: Logged In: YES user_id=1188172 #1163367 suggests a more complete new wording. Closing as duplicate. ---------------------------------------------------------------------- Comment By: David MacQuigg (macquigg) Date: 2004-07-21 17:20 Message: Logged In: YES user_id=676422 While waiting for the perfect solution, would it be possible to have links to this item at the places in the documentation where the corrections should be made (Library Reference 2.1, Quick Reference page 19)? It could save an hour of experimentation for each new user of this feature. ---------------------------------------------------------------------- Comment By: David MacQuigg (macquigg) Date: 2004-06-21 18:23 Message: Logged In: YES user_id=676422 I like the example, but the new explanation still leaves the impression that super() returns a class ( or something that acts like a class). This is what made super() so difficult to figure out the first time I tried it. The 'super' object returned by the function appears to be a collection of references, one to the 'self' instance, and one to each of the classes in the MRO of self above 'cls'. The reason it can't be just a class is that a given super object needs to retrieve a different class each time it is used, depending on what method is provided. The only thing lacking in the example is motivation for why we need super(B,self).meth(arg) instead of just calling C.meth (self,arg). I have a longer example and some motivation on page 16 in my OOP chapter at http://ece.arizona.edu/~edatools/Python/PythonOOP.doc but that may be too long if what we need here is a "man page" explanation. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-06-21 16:50 Message: Logged In: YES user_id=764593 Would an expanded example also help? I'm not sure I like my own wording yet, but ... I propose it as a straw man. """super returns the next parent class[1] class A(object): pass class B(A): def meth(self, arg): super(B, self).meth(arg) class C(A): pass class D(B, C): pass d=D() d.meth() In this case, the super(B, self) call will actually return a reference to class C. Class C is not a parent of class B, but it is the next parent for this particular instance d of class B. [1] Actually, a super class mimicing the parent class. """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=973579&group_id=5470 From noreply at sourceforge.net Fri Jan 20 18:07:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 09:07:48 -0800 Subject: [ python-Bugs-1163367 ] correct/clarify documentation for super Message-ID: Bugs item #1163367, was opened at 2005-03-15 00:39 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Steven Bethard (bediviere) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: correct/clarify documentation for super Initial Comment: The current documentation for super is confusing. For instance, it says that it returns "the superclass of type" which is incorrect; it actually returns the next type in type's MRO. Well, to be truthful, it doesn't even do that; it returns a proxy object which makes that type's attributes available, but that's just another reason to fix the documentation. I suggest changing the wording to something like: """super(type[, object-or-type]) Return an object that exposes the attributes available through the type's superclasses, without exposing the attributes of the type itself. Attributes will be looked up using the normal resolution order, omitting the first class in the MRO (that is, the type itself). If the second argument is present, it should either be an instance of object, in which case isinstance(object-or-type, type) must be true, or it should be an instance of type, in which case issubclass(object-or-type, type) must be true. The typical use for this form of super is to call a cooperative superclass method: class C(B): def meth(self, arg): super(C, self).meth(arg) If the second argument to super is omitted, the super object returned will not expose any attributes directly. However, attributes will be accessible whenever the descriptor machinery is invoked, e.g. though explicit invocation of __get__. Note that super is undefined for implicit lookups using statements or operators such as "super(C, self)[name]". These must be spelled out with their explicit lookup, e.g. "super(C, self).__getitem__(name)". New in version 2.2. """ It's not perfect and I welcome suggestions for re-wording, but I think it's substantially more accurate about what super actually does. It also moves the "second argument omitted" situation to the end, since this is a vastly more uncommon use case. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 18:06 Message: Logged In: YES user_id=1188172 See also Bug #973579 (which I closed as duplicate) for alternative wording. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470 From noreply at sourceforge.net Fri Jan 20 18:24:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 09:24:51 -0800 Subject: [ python-Bugs-1407902 ] urlparse does not know about sftp: urls Message-ID: Bugs item #1407902, was opened at 2006-01-17 04:47 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1407902&group_id=5470 Please note that this message will contain 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 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: urlparse does not know about sftp: urls Initial Comment: >>> from urlparse import urlparse >>> urlparse('sftp://example.com//absolute/path') ('sftp', '', '//example.com//absolute/path', '', '', '') >>> urlparse('sftp://example.com/relative/path') ('sftp', '', '//example.com/relative/path', '', '', '') netloc should be populated in both cases ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 18:24 Message: Logged In: YES user_id=1188172 Thanks for the report. Committed revisions 42108, 42109 (2.4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1407902&group_id=5470 From noreply at sourceforge.net Fri Jan 20 21:26:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 12:26:50 -0800 Subject: [ python-Bugs-1411097 ] urllib2.urlopen() hangs due to use of socket._fileobject? Message-ID: Bugs item #1411097, was opened at 2006-01-20 20: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=1411097&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2.urlopen() hangs due to use of socket._fileobject? Initial Comment: To reproduce: import urllib2 print urllib2.urlopen("http://66.117.37.13/").read() The attached patch "fixes" the hang, but that patch is not acceptable because it also removes the .readline() and .readlines() methods on the response object returned by urllib2.urlopen(). The patch seems to demonstrate that the problem is caused by the (ab)use of socket._fileobject in urllib2.AbstractHTTPHandler (I believe this hack was introduced when urllib2 switched to using httplib.HTTPConnection). Not sure yet what the actual problem is... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1411097&group_id=5470 From noreply at sourceforge.net Fri Jan 20 22:05:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 13:05:36 -0800 Subject: [ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs Message-ID: Bugs item #1338995, was opened at 2005-10-27 01:08 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 Please note that this message will contain 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 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: CVS webbrowser.py (1.40) bugs Initial Comment: There are two calls to _safequote that are only made on darwin, aka, Mac OS X. That function is missing. And the UnixBrowser is missing an & in the "simpler command" and thus causes python to hang until the browser is exited (if it wasn't running already). ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 22:05 Message: Logged In: YES user_id=1188172 Another try to fix it in 42121. I added a special case for OSX browsers wrt local URLs. Skip, can you test? ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-07 01:13 Message: Logged In: YES user_id=131838 And I agree it is desirable, but it didn't work reliably in 2.4 nor any earlier version, and it isn't documented to work. The urllib.urlopen example you gave fails miserably with Windows files names, i.e., given "C:\WINDOWS\system.ini" it tries to interpret the C as a scheme. You need to use urllib's pathname2url function and pass the result to urlopen. If webbrowser.open is fixed, then maybe there will be some pressure to fix urlopen as well. You just have been lucky or unlucky depending on how you view it. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-12-07 00:38 Message: Logged In: YES user_id=44345 All I'm saying is that if this form webbrowser.open("/tmp/foo.html") was supported in Python 2.4, possibly by recognizing the bare path and silently pretending the programmer wrote webbrowser.open("file://localhost/tmp/foo.html") then it ought to do the same in 2.5 unless you intend to break existing applications. How hard can it be to recognize that the first character of the "url" is "/" and prepend "file://localhost/" before passing it along to the user's chosen browser? I suggest compatibility with urllib.urlopen is desirable: >>> f = urllib.urlopen("/etc/hosts") >>> f.read() "##\n# Host Database\n# \n# Note that this file is consulted when the system is running in single-user\n# mode. At other times this information is handled by lookupd. By default,\n# lookupd gets information from NetInfo, so this file will not be consulted\n# unless you have changed lookupd's configuration.\n#\n# localhost is used to configure the loopback interface\n# when the system is booting. Do not change this entry.\n##\n127.0.0.1\tlocalhost montanaro.dyndns.org\n255.255.255.255\tbroadcasthost\n" Skip ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-06 23:27 Message: Logged In: YES user_id=131838 And you seem to have scanned my previous post and missed where I discussed all of the problems with webbrowser.open(path). I should have been more explicit that those were problems with the all versions of the webbrowser module. It is browser-dependent whether or not opening a path works at all. I have had to work around that "problem" for years (starting with grail in 1997 and carried over to the webbroswer module in 2001). Any cross-platform developer, that tests their code, already has a workaround in place. If the webbrowser documentation agreed with you, then I would agree with you as well. Although I feel we are already violently agreeing. "Fix" the documentation and I'll "fix" the code. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-12-06 22:57 Message: Logged In: YES user_id=44345 You're missing the point. It works in Python 2.4 and doesn't on CVS HEAD. I've already had to modify one application. Maybe the old webbrowser module used to prepend a "file://localhost/" to filenames that were missing schemes. All I know is it used to work and now it doesn't As is, 2.5 is likely to break some applications that rely on the behavior in 2.4. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-06 22:21 Message: Logged In: YES user_id=131838 Then file a bug report with whoever makes your web browser. It's not Python's webbrowser module's fault that the browser doesn't accept filesystem paths. The webbrowser module is only documented to work with URLs, so any code that depends on paths is arguably buggy. That said, if someone else will write a patch for the documentation, I will write a patch for the code. - Greg ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-12-06 21:40 Message: Logged In: YES user_id=44345 > Whether or not webbrowser.open should support filesystem > paths in addition to URLs, is a different > bug/question/patch. Given that it used to work, I consider it gratuitous breakage that it doesn't anymore. S ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-06 21:21 Message: Logged In: YES user_id=131838 Oops, that was bug #1352621 for an analysis of why the previous fix was bad. I closed it as a duplicate because this bug was reopened. The short answer to your question about schemeless URLs, is no, they aren't supposed to work because they are not URLs. Whether or not webbrowser.open should support filesystem paths in addition to URLs, is a different bug/question/patch. In my application, I encapsulate webbrowser.open with code that supports it and it could be added fairly easily. Here's the information needed for anyone to do so: Whether: webbrowser.open("/tmp/mmhelp.html") works or not is browser dependent (works with Netscape 4.76!). In fact, even the other example: webbrowser.open("file:///tmp/mmhelp.html") will fail on some browsers (Safari, may be fixed by now), and one needs to do: webbrowser.open("file://localhost/tmp/mmhelp.html") instead (so a bug, but one my application had to workaround). I recall there being cases of the reverse being true, but I can't find those notes. Constructing the file URL is a minor pain, but I'm not sure what I'd change. I use urllib.pathname2url(), but that doesn't add the file scheme. So I use urlparse.urlunparse to build the actual URL -- that seems like overkill, but I might have a fragment (some browsers support fragments with the file scheme, some just ignore them). The OS X bug is easy fix in between the calls to pathname2url and urlunparse. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-12-04 18:22 Message: Logged In: YES user_id=44345 I gave patch #1372125 a try. This still fails: webbrowser.open("/tmp/mmhelp.html") while this works: webbrowser.open("file:///tmp/mmhelp.html") Is the schemeless form supposed to work or not? Also, there appears to be a digit missing from the bug reference #135261 and a simple search for "webbrowser" doesn't turn it up. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-03 03:12 Message: Logged In: YES user_id=131838 See bug #135261 and patch #1372125. The patch contains changes to use subprocess.Popen instead of os.system for the UnixBrowser and fixes my problems with webbrowser.py and should address Oleg Broytmann concerns as well. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-11-18 21:36 Message: Logged In: YES user_id=4799 So it seems the new webbrowser.py is too new. May I suggest to rename the new module and doc to webbrowser2.py, and restore the old version of the module and the doc? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-11-15 05:08 Message: Logged In: YES user_id=44345 (Reopening. The webbrowser module still appears broken to me.) I'm new to this thread, but webbrowser.open() in current SVN (revision 41445) seems broken to me. This simple statement: webbrowser.open("somefile.html") returns True but fails to open the page in my currently running instance of Safari. Dropping back to Python 2.4.1, it works fine. I know webbrowser was a huge hack, but at least it appeared to do basic stuff fine. It would appear that's no longer the case. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-11-09 22:43 Message: Logged In: YES user_id=1188172 Fixed in Revision 41419. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-31 23:01 Message: Logged In: YES user_id=131838 Breaking applications that use webbrowser does not help application writers. It would be much more useful to me, as an application writer, if the webbrowser module gave an error saying it couldn't contact a web browser, rather than the new behavior of hanging my application. You have yet to address this common use case. Running the webbrowser in the background is a contract that the webbrowser module can't break and still be called the webbrowser module. I agree that the 2.4.2 version is a practical hack that should be fixed, but the CVS webbrower almost fixes it while breaking existing applications. Since adding an & is so bad (the web browser is already confirmed to exist and to be executable), the CVS webbrower could be changed to use the subprocess module instead of os.system, and the original webbrowser contract could be preserved. The wrong display or wrong xhost/xauth permissions are not a problem because the python GUI application that calls webbrowser would have failed to start up in the first place if those problems existed. Starting the web browser in the background only needs to confirm that the web browser actually started up. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-31 14:11 Message: Logged In: YES user_id=4799 Yes, I want. Current practice of running a browser in the background by default is deadly broken. The old code of webbrowser.py is full of dirty hacks. Look at Netscape._remote(). It tries to start a browser to send a remote command; if that fails it tries to start the browser in the background, waits an arbitrary number of seconds (why this? why not less? why not more?) and without testing if the browser in the background was started it retries sending the remote command. You can never know if the browser was started and if the command was sent becuase .open() does not return a result code. At the global level the bug is that webbrowser.py doesn't tri all browsers in the tryorder - it only concentrates on the first it found in PATH. What if the brwoser cannot be started (damaged disk image; wrong DISAPLY; wrong xhost/xauth permissions)? My patched webbrowser.py is much safer. It runs all browsers in the tryorder until it finds one that can be started. One doesn't need to wait a random number of seconds, too little for slow systems, too many for fast. .open() returns a success/fail status (on systems where it is possible to obtain one). The framework still alows you to shoot yourself in the foot, but you must do it explicitly. Either run os.system("shotgun-browser &") yourself or register your own ShotgunBrowser. Thus the new framework is safe by default but still flexible. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-28 20:49 Message: Logged In: YES user_id=131838 So you really want to change existing practice and break all Python GUI programs that invoke webbrowser.open? And the Elinks example proves my point. What is the point of it being a UnixBrowser, in the terminal window, if you can't send remote commands to it (because the Python GUI application is blocked until the browser exits)? Tty-based browsers are nice for completeness, but are really a last resort for a Python application, and imply that no windowing system is available (i.e, remotely logged in and not forwarding X connections, so not running GUI applications either). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-28 13:56 Message: Logged In: YES user_id=4799 No, I still think it is a bad idea to put a generic Unix browser to background by default. If you want to do it - do it explicitly. Start a browser in a background yourself, and use remote actions from the module to open new windows/tabs. Or register another browser, with different .open() and/or ._remote(). And, BTW, Elinks is a subclass of UnixBrowser, not GenericBrowser. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-27 19:35 Message: Logged In: YES user_id=131838 And I don't want starting up firefox to hang my python GUI either. So, if you look at the code more closely, lynx/links/elinks subclass from GenericBrowser not UnixBrowser, so adding the & to UnixBrowser is the correct thing to do. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-27 17:36 Message: Logged In: YES user_id=4799 Yes, _safequote() call seems like a bug. A leftover after I've merged a half dozens of patches into this one. Should be removed. But there should certainly be no '&'. You certainly dont want to start lynx/links/elinks in the background, do you?! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 From noreply at sourceforge.net Fri Jan 20 22:52:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 13:52:24 -0800 Subject: [ python-Feature Requests-1353344 ] python.desktop Message-ID: Feature Requests item #1353344, was opened at 2005-11-10 19:22 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1353344&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: python.desktop Initial Comment: I would very much like a /usr/share/applications/python.desktop file so that Python can be started from the Program-menu in Linux, just like you can from the Start-menu in Windows. I think it would be very neat and good for beginners. ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 22:52 Message: Logged In: YES user_id=1188172 It seems that the new Python website will feature a new icon. Perhaps that could be added to the distribution as the default Python icon. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2006-01-09 18:52 Message: Logged In: YES user_id=51702 In trunk there are PC/py.ico, PC/pyc.ico, PC/pycon.ico. I guess they would all work as icons, but I choose pycon.ico because that is the icon used on windows. I also wonder if the desktop file can be applied soon? It seems pretty trivial and uncontroversial to me. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-11-17 14:43 Message: Logged In: YES user_id=1188172 I added German translation. Regarding the icon: I do not like that very much. Isn't there another Python icon available in the standard sizes? ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2005-11-16 19:16 Message: Logged In: YES user_id=51702 I have attached a .desktop file and an icon. python.desktop goes into /usr/share/applications and pycon.png into /usr/share/pixmaps. It's only translated to Swedish because I don't know other languages to well. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-11-13 23:41 Message: Logged In: YES user_id=21627 Would you be willing to provide one? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1353344&group_id=5470 From noreply at sourceforge.net Fri Jan 20 23:01:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 14:01:11 -0800 Subject: [ python-Bugs-1378679 ] urllib2.HTTPBasicAuthHandler fails on non-default port Message-ID: Bugs item #1378679, was opened at 2005-12-12 12:50 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378679&group_id=5470 Please note that this message will contain 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 Submitted By: Mikhail Gusarov (gusarov) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2.HTTPBasicAuthHandler fails on non-default port Initial Comment: HTTPBasicAuthHandler (or, more precise, AbstractBasicAuthHandler) does not work when non- default port is in use: passwords added to it just not being passed back in answer to the 401 error code. Default port works fine. I tracked the problem with it to the HTTPPasswordMgr. find_user_password: it accepts 'authuri' and reduce it using reduce_uri(). AbstractBasicAuthHandler passes as 'authuri' parameter just hostname, in form 'myhost:myport' and this cause reduce_uri() to parse it as URI with schema 'myhost' and netloc 'myport', which is obviously wrong. Passing to the reduce_uri() hostname in form 'myhost' works fine. I placed the the program demonstrating the bug to the attach: it throws HTTPError in my case. Of course change the host, port, user and password to the reflecting your setup. given should be protected by the basic authentication. ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 23:01 Message: Logged In: YES user_id=1188172 Fixed in rev. 42130 in 2.4 branch. Already fixed in HEAD. ---------------------------------------------------------------------- Comment By: Mikhail Gusarov (gusarov) Date: 2005-12-12 13:10 Message: Logged In: YES user_id=501458 Problem was fixed by changing user, pw = self.passwd.find_user_password(realm, host) to the user, pw = self.passwd.find_user_password(realm, req. get_full_url()) in the problem function ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378679&group_id=5470 From noreply at sourceforge.net Fri Jan 20 23:10:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 14:10:16 -0800 Subject: [ python-Bugs-1339007 ] shelve.Shelf.__del__ throws exceptions Message-ID: Bugs item #1339007, was opened at 2005-10-27 01:30 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1339007&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Geoffrey T. Dairiki (dairiki) >Assigned to: Raymond Hettinger (rhettinger) Summary: shelve.Shelf.__del__ throws exceptions Initial Comment: Python calls an object's __del__ method, even if the objects __init__ method was unsuccessful (i.e. __init__ terminated via exception.) Because of this, if there is an error while attempting to open a Shelf, the destructor is still called, even though the Shelf is not fully constructed. The code in shelve.Shelf does not check for this possibility, and therefor triggers an AttributeError. Here is an example script which should reproduce the error. ===Begin test.py====l import shelve try: shelf = shelve.open('non-existant-file', flag='r') except: pass ===End test.py===== For me, the above script produces the message: Exception exceptions.AttributeError: "DbfilenameShelf instance has no attribute 'writeback'" in ignored I can reproduce this using either Python 2.4.1 or 2.3.5. I took a quick look at the current CVS version of shelve.py, and it appears to suffer the same problem. ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 23:10 Message: Logged In: YES user_id=1188172 Is this a bug? As exceptions in __del__ are ignored, this should do no harm. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1339007&group_id=5470 From noreply at sourceforge.net Sat Jan 21 00:19:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 15:19:51 -0800 Subject: [ python-Bugs-1409455 ] email.Message.set_payload followed by bad result get_payload Message-ID: Bugs item #1409455, was opened at 2006-01-18 14:09 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409455&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Sapiro (msapiro) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Message.set_payload followed by bad result get_payload Initial Comment: Under certain circumstances, in particular when charset is 'iso-8859-1', where msg is an email.Message() instance, msg.set_payload(text, charset) 'apparently' encodes the text as quoted-printable and adds a Content-Transfer-Encoding: quoted-printable header to msg. I say 'apparently' because if one prints msg or creates a Generator instance and writes msg to a file, the message is printed/written as a correct, quoted-printable encoded message, but text = msg._payload or text = msg.get_payload() gives the original text, not quoted-printable encoded, and text = msg.get_payload(decode=True) gives a quoted-printable decoding of the original text which is munged if the original text included '=' in some ways. This is causing problems in Mailman which are currently worked around by flagging if the payload was set by set_payload() and not subsequently 'decoding' in that case, but it would be better if set_payload()/get_payload() worked properly. A script is attached which illustrates the problem. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-01-20 15:19 Message: Logged In: YES user_id=1123998 I've looked at the email library and I see the problem. msg.set_payload() never QP encodes msg._payload. When the message is stringified or flattened by a generator, the generator's _handle_text() method does the encoding and it is msg._charset that signals the need to do this. Thus when the message object is ultimately converted to a suitable external form, the body is QP encoded, but internally it never is. Thus, subsequent msg.get_payload() calls return unexpected results. It appears (from minimal testing) that when a text message is parsed into an email.Message.Message instance, _charset is None even if there is a character set specification in a Content-Type: header. I have attached a patch (Message.py.patch.txt) which may fix the problem. It has only been tested against the already attached example.py so it is really untested. Also, it only addresses the quoted-printable case. I haven't even thought about whether there might be a similar problem involving base64. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409455&group_id=5470 From noreply at sourceforge.net Sat Jan 21 08:22:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 20 Jan 2006 23:22:05 -0800 Subject: [ python-Bugs-902075 ] urllib2 should be more robust for sloppy proxy URLs Message-ID: Bugs item #902075, was opened at 2004-02-22 11:05 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902075&group_id=5470 Please note that this message will contain 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 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 should be more robust for sloppy proxy URLs Initial Comment: passing an URL like "foo.bar.baz" instead of "http://foo.bar.baz" results in a stacktrace: 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 This could be fixed by calling urlparse.urlparse on the proxy url, either in the calling code or in the library code, which I would prefer to make it more robust about sloppy URLs passed in the http_proxy environment variable. ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-21 08:22 Message: Logged In: YES user_id=1188172 I committed a fix (similar to the patch) in rev. 42133 to the HEAD. I'm not sure whether to backport. ---------------------------------------------------------------------- Comment By: Andrew Bennetts (spiv) Date: 2006-01-17 04:04 Message: Logged In: YES user_id=50945 I think test cases would help the patch at http://bugs.debian.org/233305 get applied. ---------------------------------------------------------------------- Comment By: Chris Lawrence (lordsutch) Date: 2004-03-24 22:51 Message: Logged In: YES user_id=6757 I've put together a patch, which can be found at http://bugs.debian.org/233305; it isn't perfect (ideally the entire routine should be rewritten, as it's processing environment data that could be from the "wild"), but it avoids the traceback. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2004-02-22 11:19 Message: Logged In: YES user_id=60903 Ok, I see, PEP42 ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902075&group_id=5470 From noreply at sourceforge.net Sat Jan 21 16:06:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 21 Jan 2006 07:06:52 -0800 Subject: [ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs Message-ID: Bugs item #1338995, was opened at 2005-10-26 18:08 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 Please note that this message will contain 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 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: CVS webbrowser.py (1.40) bugs Initial Comment: There are two calls to _safequote that are only made on darwin, aka, Mac OS X. That function is missing. And the UnixBrowser is missing an & in the "simpler command" and thus causes python to hang until the browser is exited (if it wasn't running already). ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2006-01-21 09:06 Message: Logged In: YES user_id=44345 > Skip, can you test? Yes, it works, thanks. I can understand special casing local URLs, but why also OSX? Was that the only platform on which local URLs failed? ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 15:05 Message: Logged In: YES user_id=1188172 Another try to fix it in 42121. I added a special case for OSX browsers wrt local URLs. Skip, can you test? ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-06 18:13 Message: Logged In: YES user_id=131838 And I agree it is desirable, but it didn't work reliably in 2.4 nor any earlier version, and it isn't documented to work. The urllib.urlopen example you gave fails miserably with Windows files names, i.e., given "C:\WINDOWS\system.ini" it tries to interpret the C as a scheme. You need to use urllib's pathname2url function and pass the result to urlopen. If webbrowser.open is fixed, then maybe there will be some pressure to fix urlopen as well. You just have been lucky or unlucky depending on how you view it. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-12-06 17:38 Message: Logged In: YES user_id=44345 All I'm saying is that if this form webbrowser.open("/tmp/foo.html") was supported in Python 2.4, possibly by recognizing the bare path and silently pretending the programmer wrote webbrowser.open("file://localhost/tmp/foo.html") then it ought to do the same in 2.5 unless you intend to break existing applications. How hard can it be to recognize that the first character of the "url" is "/" and prepend "file://localhost/" before passing it along to the user's chosen browser? I suggest compatibility with urllib.urlopen is desirable: >>> f = urllib.urlopen("/etc/hosts") >>> f.read() "##\n# Host Database\n# \n# Note that this file is consulted when the system is running in single-user\n# mode. At other times this information is handled by lookupd. By default,\n# lookupd gets information from NetInfo, so this file will not be consulted\n# unless you have changed lookupd's configuration.\n#\n# localhost is used to configure the loopback interface\n# when the system is booting. Do not change this entry.\n##\n127.0.0.1\tlocalhost montanaro.dyndns.org\n255.255.255.255\tbroadcasthost\n" Skip ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-06 16:27 Message: Logged In: YES user_id=131838 And you seem to have scanned my previous post and missed where I discussed all of the problems with webbrowser.open(path). I should have been more explicit that those were problems with the all versions of the webbrowser module. It is browser-dependent whether or not opening a path works at all. I have had to work around that "problem" for years (starting with grail in 1997 and carried over to the webbroswer module in 2001). Any cross-platform developer, that tests their code, already has a workaround in place. If the webbrowser documentation agreed with you, then I would agree with you as well. Although I feel we are already violently agreeing. "Fix" the documentation and I'll "fix" the code. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-12-06 15:57 Message: Logged In: YES user_id=44345 You're missing the point. It works in Python 2.4 and doesn't on CVS HEAD. I've already had to modify one application. Maybe the old webbrowser module used to prepend a "file://localhost/" to filenames that were missing schemes. All I know is it used to work and now it doesn't As is, 2.5 is likely to break some applications that rely on the behavior in 2.4. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-06 15:21 Message: Logged In: YES user_id=131838 Then file a bug report with whoever makes your web browser. It's not Python's webbrowser module's fault that the browser doesn't accept filesystem paths. The webbrowser module is only documented to work with URLs, so any code that depends on paths is arguably buggy. That said, if someone else will write a patch for the documentation, I will write a patch for the code. - Greg ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-12-06 14:40 Message: Logged In: YES user_id=44345 > Whether or not webbrowser.open should support filesystem > paths in addition to URLs, is a different > bug/question/patch. Given that it used to work, I consider it gratuitous breakage that it doesn't anymore. S ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-06 14:21 Message: Logged In: YES user_id=131838 Oops, that was bug #1352621 for an analysis of why the previous fix was bad. I closed it as a duplicate because this bug was reopened. The short answer to your question about schemeless URLs, is no, they aren't supposed to work because they are not URLs. Whether or not webbrowser.open should support filesystem paths in addition to URLs, is a different bug/question/patch. In my application, I encapsulate webbrowser.open with code that supports it and it could be added fairly easily. Here's the information needed for anyone to do so: Whether: webbrowser.open("/tmp/mmhelp.html") works or not is browser dependent (works with Netscape 4.76!). In fact, even the other example: webbrowser.open("file:///tmp/mmhelp.html") will fail on some browsers (Safari, may be fixed by now), and one needs to do: webbrowser.open("file://localhost/tmp/mmhelp.html") instead (so a bug, but one my application had to workaround). I recall there being cases of the reverse being true, but I can't find those notes. Constructing the file URL is a minor pain, but I'm not sure what I'd change. I use urllib.pathname2url(), but that doesn't add the file scheme. So I use urlparse.urlunparse to build the actual URL -- that seems like overkill, but I might have a fragment (some browsers support fragments with the file scheme, some just ignore them). The OS X bug is easy fix in between the calls to pathname2url and urlunparse. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-12-04 11:22 Message: Logged In: YES user_id=44345 I gave patch #1372125 a try. This still fails: webbrowser.open("/tmp/mmhelp.html") while this works: webbrowser.open("file:///tmp/mmhelp.html") Is the schemeless form supposed to work or not? Also, there appears to be a digit missing from the bug reference #135261 and a simple search for "webbrowser" doesn't turn it up. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-02 20:12 Message: Logged In: YES user_id=131838 See bug #135261 and patch #1372125. The patch contains changes to use subprocess.Popen instead of os.system for the UnixBrowser and fixes my problems with webbrowser.py and should address Oleg Broytmann concerns as well. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-11-18 14:36 Message: Logged In: YES user_id=4799 So it seems the new webbrowser.py is too new. May I suggest to rename the new module and doc to webbrowser2.py, and restore the old version of the module and the doc? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-11-14 22:08 Message: Logged In: YES user_id=44345 (Reopening. The webbrowser module still appears broken to me.) I'm new to this thread, but webbrowser.open() in current SVN (revision 41445) seems broken to me. This simple statement: webbrowser.open("somefile.html") returns True but fails to open the page in my currently running instance of Safari. Dropping back to Python 2.4.1, it works fine. I know webbrowser was a huge hack, but at least it appeared to do basic stuff fine. It would appear that's no longer the case. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-11-09 15:43 Message: Logged In: YES user_id=1188172 Fixed in Revision 41419. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-31 16:01 Message: Logged In: YES user_id=131838 Breaking applications that use webbrowser does not help application writers. It would be much more useful to me, as an application writer, if the webbrowser module gave an error saying it couldn't contact a web browser, rather than the new behavior of hanging my application. You have yet to address this common use case. Running the webbrowser in the background is a contract that the webbrowser module can't break and still be called the webbrowser module. I agree that the 2.4.2 version is a practical hack that should be fixed, but the CVS webbrower almost fixes it while breaking existing applications. Since adding an & is so bad (the web browser is already confirmed to exist and to be executable), the CVS webbrower could be changed to use the subprocess module instead of os.system, and the original webbrowser contract could be preserved. The wrong display or wrong xhost/xauth permissions are not a problem because the python GUI application that calls webbrowser would have failed to start up in the first place if those problems existed. Starting the web browser in the background only needs to confirm that the web browser actually started up. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-31 07:11 Message: Logged In: YES user_id=4799 Yes, I want. Current practice of running a browser in the background by default is deadly broken. The old code of webbrowser.py is full of dirty hacks. Look at Netscape._remote(). It tries to start a browser to send a remote command; if that fails it tries to start the browser in the background, waits an arbitrary number of seconds (why this? why not less? why not more?) and without testing if the browser in the background was started it retries sending the remote command. You can never know if the browser was started and if the command was sent becuase .open() does not return a result code. At the global level the bug is that webbrowser.py doesn't tri all browsers in the tryorder - it only concentrates on the first it found in PATH. What if the brwoser cannot be started (damaged disk image; wrong DISAPLY; wrong xhost/xauth permissions)? My patched webbrowser.py is much safer. It runs all browsers in the tryorder until it finds one that can be started. One doesn't need to wait a random number of seconds, too little for slow systems, too many for fast. .open() returns a success/fail status (on systems where it is possible to obtain one). The framework still alows you to shoot yourself in the foot, but you must do it explicitly. Either run os.system("shotgun-browser &") yourself or register your own ShotgunBrowser. Thus the new framework is safe by default but still flexible. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-28 13:49 Message: Logged In: YES user_id=131838 So you really want to change existing practice and break all Python GUI programs that invoke webbrowser.open? And the Elinks example proves my point. What is the point of it being a UnixBrowser, in the terminal window, if you can't send remote commands to it (because the Python GUI application is blocked until the browser exits)? Tty-based browsers are nice for completeness, but are really a last resort for a Python application, and imply that no windowing system is available (i.e, remotely logged in and not forwarding X connections, so not running GUI applications either). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-28 06:56 Message: Logged In: YES user_id=4799 No, I still think it is a bad idea to put a generic Unix browser to background by default. If you want to do it - do it explicitly. Start a browser in a background yourself, and use remote actions from the module to open new windows/tabs. Or register another browser, with different .open() and/or ._remote(). And, BTW, Elinks is a subclass of UnixBrowser, not GenericBrowser. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-27 12:35 Message: Logged In: YES user_id=131838 And I don't want starting up firefox to hang my python GUI either. So, if you look at the code more closely, lynx/links/elinks subclass from GenericBrowser not UnixBrowser, so adding the & to UnixBrowser is the correct thing to do. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-27 10:36 Message: Logged In: YES user_id=4799 Yes, _safequote() call seems like a bug. A leftover after I've merged a half dozens of patches into this one. Should be removed. But there should certainly be no '&'. You certainly dont want to start lynx/links/elinks in the background, do you?! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 From noreply at sourceforge.net Sat Jan 21 20:04:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 21 Jan 2006 11:04:32 -0800 Subject: [ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs Message-ID: Bugs item #1338995, was opened at 2005-10-27 01:08 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 Please note that this message will contain 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 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: CVS webbrowser.py (1.40) bugs Initial Comment: There are two calls to _safequote that are only made on darwin, aka, Mac OS X. That function is missing. And the UnixBrowser is missing an & in the "simpler command" and thus causes python to hang until the browser is exited (if it wasn't running already). ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-21 20:04 Message: Logged In: YES user_id=1188172 Well, all of the Unix browsers I tried accept filenames without a problem, the os.startfile function on Windows does it in any case. That left OSX and Safari. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-01-21 16:06 Message: Logged In: YES user_id=44345 > Skip, can you test? Yes, it works, thanks. I can understand special casing local URLs, but why also OSX? Was that the only platform on which local URLs failed? ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 22:05 Message: Logged In: YES user_id=1188172 Another try to fix it in 42121. I added a special case for OSX browsers wrt local URLs. Skip, can you test? ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-07 01:13 Message: Logged In: YES user_id=131838 And I agree it is desirable, but it didn't work reliably in 2.4 nor any earlier version, and it isn't documented to work. The urllib.urlopen example you gave fails miserably with Windows files names, i.e., given "C:\WINDOWS\system.ini" it tries to interpret the C as a scheme. You need to use urllib's pathname2url function and pass the result to urlopen. If webbrowser.open is fixed, then maybe there will be some pressure to fix urlopen as well. You just have been lucky or unlucky depending on how you view it. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-12-07 00:38 Message: Logged In: YES user_id=44345 All I'm saying is that if this form webbrowser.open("/tmp/foo.html") was supported in Python 2.4, possibly by recognizing the bare path and silently pretending the programmer wrote webbrowser.open("file://localhost/tmp/foo.html") then it ought to do the same in 2.5 unless you intend to break existing applications. How hard can it be to recognize that the first character of the "url" is "/" and prepend "file://localhost/" before passing it along to the user's chosen browser? I suggest compatibility with urllib.urlopen is desirable: >>> f = urllib.urlopen("/etc/hosts") >>> f.read() "##\n# Host Database\n# \n# Note that this file is consulted when the system is running in single-user\n# mode. At other times this information is handled by lookupd. By default,\n# lookupd gets information from NetInfo, so this file will not be consulted\n# unless you have changed lookupd's configuration.\n#\n# localhost is used to configure the loopback interface\n# when the system is booting. Do not change this entry.\n##\n127.0.0.1\tlocalhost montanaro.dyndns.org\n255.255.255.255\tbroadcasthost\n" Skip ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-06 23:27 Message: Logged In: YES user_id=131838 And you seem to have scanned my previous post and missed where I discussed all of the problems with webbrowser.open(path). I should have been more explicit that those were problems with the all versions of the webbrowser module. It is browser-dependent whether or not opening a path works at all. I have had to work around that "problem" for years (starting with grail in 1997 and carried over to the webbroswer module in 2001). Any cross-platform developer, that tests their code, already has a workaround in place. If the webbrowser documentation agreed with you, then I would agree with you as well. Although I feel we are already violently agreeing. "Fix" the documentation and I'll "fix" the code. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-12-06 22:57 Message: Logged In: YES user_id=44345 You're missing the point. It works in Python 2.4 and doesn't on CVS HEAD. I've already had to modify one application. Maybe the old webbrowser module used to prepend a "file://localhost/" to filenames that were missing schemes. All I know is it used to work and now it doesn't As is, 2.5 is likely to break some applications that rely on the behavior in 2.4. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-06 22:21 Message: Logged In: YES user_id=131838 Then file a bug report with whoever makes your web browser. It's not Python's webbrowser module's fault that the browser doesn't accept filesystem paths. The webbrowser module is only documented to work with URLs, so any code that depends on paths is arguably buggy. That said, if someone else will write a patch for the documentation, I will write a patch for the code. - Greg ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-12-06 21:40 Message: Logged In: YES user_id=44345 > Whether or not webbrowser.open should support filesystem > paths in addition to URLs, is a different > bug/question/patch. Given that it used to work, I consider it gratuitous breakage that it doesn't anymore. S ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-06 21:21 Message: Logged In: YES user_id=131838 Oops, that was bug #1352621 for an analysis of why the previous fix was bad. I closed it as a duplicate because this bug was reopened. The short answer to your question about schemeless URLs, is no, they aren't supposed to work because they are not URLs. Whether or not webbrowser.open should support filesystem paths in addition to URLs, is a different bug/question/patch. In my application, I encapsulate webbrowser.open with code that supports it and it could be added fairly easily. Here's the information needed for anyone to do so: Whether: webbrowser.open("/tmp/mmhelp.html") works or not is browser dependent (works with Netscape 4.76!). In fact, even the other example: webbrowser.open("file:///tmp/mmhelp.html") will fail on some browsers (Safari, may be fixed by now), and one needs to do: webbrowser.open("file://localhost/tmp/mmhelp.html") instead (so a bug, but one my application had to workaround). I recall there being cases of the reverse being true, but I can't find those notes. Constructing the file URL is a minor pain, but I'm not sure what I'd change. I use urllib.pathname2url(), but that doesn't add the file scheme. So I use urlparse.urlunparse to build the actual URL -- that seems like overkill, but I might have a fragment (some browsers support fragments with the file scheme, some just ignore them). The OS X bug is easy fix in between the calls to pathname2url and urlunparse. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-12-04 18:22 Message: Logged In: YES user_id=44345 I gave patch #1372125 a try. This still fails: webbrowser.open("/tmp/mmhelp.html") while this works: webbrowser.open("file:///tmp/mmhelp.html") Is the schemeless form supposed to work or not? Also, there appears to be a digit missing from the bug reference #135261 and a simple search for "webbrowser" doesn't turn it up. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-12-03 03:12 Message: Logged In: YES user_id=131838 See bug #135261 and patch #1372125. The patch contains changes to use subprocess.Popen instead of os.system for the UnixBrowser and fixes my problems with webbrowser.py and should address Oleg Broytmann concerns as well. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-11-18 21:36 Message: Logged In: YES user_id=4799 So it seems the new webbrowser.py is too new. May I suggest to rename the new module and doc to webbrowser2.py, and restore the old version of the module and the doc? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-11-15 05:08 Message: Logged In: YES user_id=44345 (Reopening. The webbrowser module still appears broken to me.) I'm new to this thread, but webbrowser.open() in current SVN (revision 41445) seems broken to me. This simple statement: webbrowser.open("somefile.html") returns True but fails to open the page in my currently running instance of Safari. Dropping back to Python 2.4.1, it works fine. I know webbrowser was a huge hack, but at least it appeared to do basic stuff fine. It would appear that's no longer the case. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-11-09 22:43 Message: Logged In: YES user_id=1188172 Fixed in Revision 41419. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-31 23:01 Message: Logged In: YES user_id=131838 Breaking applications that use webbrowser does not help application writers. It would be much more useful to me, as an application writer, if the webbrowser module gave an error saying it couldn't contact a web browser, rather than the new behavior of hanging my application. You have yet to address this common use case. Running the webbrowser in the background is a contract that the webbrowser module can't break and still be called the webbrowser module. I agree that the 2.4.2 version is a practical hack that should be fixed, but the CVS webbrower almost fixes it while breaking existing applications. Since adding an & is so bad (the web browser is already confirmed to exist and to be executable), the CVS webbrower could be changed to use the subprocess module instead of os.system, and the original webbrowser contract could be preserved. The wrong display or wrong xhost/xauth permissions are not a problem because the python GUI application that calls webbrowser would have failed to start up in the first place if those problems existed. Starting the web browser in the background only needs to confirm that the web browser actually started up. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-31 14:11 Message: Logged In: YES user_id=4799 Yes, I want. Current practice of running a browser in the background by default is deadly broken. The old code of webbrowser.py is full of dirty hacks. Look at Netscape._remote(). It tries to start a browser to send a remote command; if that fails it tries to start the browser in the background, waits an arbitrary number of seconds (why this? why not less? why not more?) and without testing if the browser in the background was started it retries sending the remote command. You can never know if the browser was started and if the command was sent becuase .open() does not return a result code. At the global level the bug is that webbrowser.py doesn't tri all browsers in the tryorder - it only concentrates on the first it found in PATH. What if the brwoser cannot be started (damaged disk image; wrong DISAPLY; wrong xhost/xauth permissions)? My patched webbrowser.py is much safer. It runs all browsers in the tryorder until it finds one that can be started. One doesn't need to wait a random number of seconds, too little for slow systems, too many for fast. .open() returns a success/fail status (on systems where it is possible to obtain one). The framework still alows you to shoot yourself in the foot, but you must do it explicitly. Either run os.system("shotgun-browser &") yourself or register your own ShotgunBrowser. Thus the new framework is safe by default but still flexible. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-28 20:49 Message: Logged In: YES user_id=131838 So you really want to change existing practice and break all Python GUI programs that invoke webbrowser.open? And the Elinks example proves my point. What is the point of it being a UnixBrowser, in the terminal window, if you can't send remote commands to it (because the Python GUI application is blocked until the browser exits)? Tty-based browsers are nice for completeness, but are really a last resort for a Python application, and imply that no windowing system is available (i.e, remotely logged in and not forwarding X connections, so not running GUI applications either). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-28 13:56 Message: Logged In: YES user_id=4799 No, I still think it is a bad idea to put a generic Unix browser to background by default. If you want to do it - do it explicitly. Start a browser in a background yourself, and use remote actions from the module to open new windows/tabs. Or register another browser, with different .open() and/or ._remote(). And, BTW, Elinks is a subclass of UnixBrowser, not GenericBrowser. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-27 19:35 Message: Logged In: YES user_id=131838 And I don't want starting up firefox to hang my python GUI either. So, if you look at the code more closely, lynx/links/elinks subclass from GenericBrowser not UnixBrowser, so adding the & to UnixBrowser is the correct thing to do. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-27 17:36 Message: Logged In: YES user_id=4799 Yes, _safequote() call seems like a bug. A leftover after I've merged a half dozens of patches into this one. Should be removed. But there should certainly be no '&'. You certainly dont want to start lynx/links/elinks in the background, do you?! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 From noreply at sourceforge.net Sat Jan 21 20:50:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 21 Jan 2006 11:50:05 -0800 Subject: [ python-Bugs-1411674 ] "print statement" in libref index broken Message-ID: Bugs item #1411674, was opened at 2006-01-21 13:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1411674&group_id=5470 Please note that this 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 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: "print statement" in libref index broken Initial Comment: The "print statement" entry in the libref index refers the user to http://www.python.org/dev/doc/devel/lib/types.html#l2h-92 The source (libstdtypes.tex): \ulink{\keyword{print} statement}{../ref/print.html} suggests that the link should be to the reference manual. Something's fishy. This was reported on comp.lang.python by peter at monicol.co.uk. His report was against the current doc, but the problem still exists in the development version. Just passing it along... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1411674&group_id=5470 From noreply at sourceforge.net Sat Jan 21 20:59:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 21 Jan 2006 11:59:52 -0800 Subject: [ python-Bugs-1411674 ] "print statement" in libref index broken Message-ID: Bugs item #1411674, was opened at 2006-01-21 20:50 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1411674&group_id=5470 Please note that this 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 Submitted By: Skip Montanaro (montanaro) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: "print statement" in libref index broken Initial Comment: The "print statement" entry in the libref index refers the user to http://www.python.org/dev/doc/devel/lib/types.html#l2h-92 The source (libstdtypes.tex): \ulink{\keyword{print} statement}{../ref/print.html} suggests that the link should be to the reference manual. Something's fishy. This was reported on comp.lang.python by peter at monicol.co.uk. His report was against the current doc, but the problem still exists in the development version. Just passing it along... ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-21 20:59 Message: Logged In: YES user_id=1188172 The output is okay. The \ulink you state does not add the index entry, it's the \stindex one line above it. But it's questionable whether this mention of print merits an index entry. Fred? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1411674&group_id=5470 From noreply at sourceforge.net Sat Jan 21 21:17:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 21 Jan 2006 12:17:15 -0800 Subject: [ python-Bugs-1411695 ] XML.sax.saxutils.escape -- always escapes <, >, &, Message-ID: Bugs item #1411695, was opened at 2006-01-21 15: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=1411695&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Sandler (msandler) Assigned to: Nobody/Anonymous (nobody) Summary: XML.sax.saxutils.escape -- always escapes <, >, &, Initial Comment: sax.saxutils.escape -- always escapes <, >, &, even if entities are provided. E.g. escape("", {'a':'\a'}) would produce "<\abcd%rt;" instead of "<\abcd>" While it might be expected behaviour, the documentation states "You can escape other strings of data by passing a dictionary as the optional entities parameter. The keys and values must all be strings; each key will be replaced with its corresponding value. " and it is not at all obvious that entities specify _additional_ (to <, >, &) escape strings. It is also impossible to do custom escapes of <,>,& using saxutils.escape. (while custom escapes of < and > might be never necessary for XML, the escape function is general enough to be of interest in other circumstances). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1411695&group_id=5470 From noreply at sourceforge.net Sat Jan 21 23:10:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 21 Jan 2006 14:10:49 -0800 Subject: [ python-Bugs-1411097 ] urllib2.urlopen() hangs due to use of socket._fileobject? Message-ID: Bugs item #1411097, was opened at 2006-01-20 20:26 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1411097&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2.urlopen() hangs due to use of socket._fileobject? Initial Comment: To reproduce: import urllib2 print urllib2.urlopen("http://66.117.37.13/").read() The attached patch "fixes" the hang, but that patch is not acceptable because it also removes the .readline() and .readlines() methods on the response object returned by urllib2.urlopen(). The patch seems to demonstrate that the problem is caused by the (ab)use of socket._fileobject in urllib2.AbstractHTTPHandler (I believe this hack was introduced when urllib2 switched to using httplib.HTTPConnection). Not sure yet what the actual problem is... ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2006-01-21 22:10 Message: Logged In: YES user_id=261020 In fact the commit message for rev 36871 states the real reason _fileobject is used (handling chunked encoding), showing my workaround is even more harmful than I thought. Moreover, doing a urlopen on 66.117.37.13 shows the response *is* chunked. The problem seems to be caused by httplib failing to find a CRLF at the end of the chunked response, so the loop at the end of _read_chunked() never terminates. Haven't looked in detail yet, but I'm guessing a) it's the server's fault and b) httplib should work around it. Here's the commit message from 36871: Fix urllib2.urlopen() handling of chunked content encoding. The change to use the newer httplib interface admitted the possibility that we'd get an HTTP/1.1 chunked response, but the code didn't handle it correctly. The raw socket object can't be pass to addinfourl(), because it would read the undecoded response. Instead, addinfourl() must call HTTPResponse.read(), which will handle the decoding. One extra wrinkle is that the HTTPReponse object can't be passed to addinfourl() either, because it doesn't implement readline() or readlines(). As a quick hack, use socket._fileobject(), which implements those methods on top of a read buffer. (suggested by mwh) Finally, add some tests based on test_urllibnet. Thanks to Andrew Sawyers for originally reporting the chunked problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1411097&group_id=5470 From noreply at sourceforge.net Sun Jan 22 20:04:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 Jan 2006 11:04:59 -0800 Subject: [ python-Bugs-1412227 ] minor doc issues in os Message-ID: Bugs item #1412227, was opened at 2006-01-22 20: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=1412227&group_id=5470 Please note that this 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: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: tiissa (tiissa) Assigned to: Nobody/Anonymous (nobody) Summary: minor doc issues in os Initial Comment: Section 6.1.4 in libos.tex, in the description of the stat function, there is a new paragraph on FreeBSD with an incomplete parenthesis: ..."may be available (but may be only filled out of root tries to use them:" I guess it should read "(but may be only filled out if root tries to use them):" (but I may be wrong). Also, in the walk function, there is a typo : one "dirnames" should be "dirpath" instead (when describing the effect of a modification of dirnames in a bottom-up walk). In this same walk function, os.error is used although OSError is used everywhere else (to my incomplete knowledge). Is there a reason? I join a patch with these corrections and some small LaTeX macro changes in stat_float_times. Thank you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1412227&group_id=5470 From noreply at sourceforge.net Sun Jan 22 20:05:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 Jan 2006 11:05:39 -0800 Subject: [ python-Bugs-1412227 ] minor doc issues in os Message-ID: Bugs item #1412227, was opened at 2006-01-22 20:04 Message generated for change (Settings changed) made by tiissa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1412227&group_id=5470 Please note that this 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: Not a Bug Status: Open Resolution: None >Priority: 1 Submitted By: tiissa (tiissa) Assigned to: Nobody/Anonymous (nobody) Summary: minor doc issues in os Initial Comment: Section 6.1.4 in libos.tex, in the description of the stat function, there is a new paragraph on FreeBSD with an incomplete parenthesis: ..."may be available (but may be only filled out of root tries to use them:" I guess it should read "(but may be only filled out if root tries to use them):" (but I may be wrong). Also, in the walk function, there is a typo : one "dirnames" should be "dirpath" instead (when describing the effect of a modification of dirnames in a bottom-up walk). In this same walk function, os.error is used although OSError is used everywhere else (to my incomplete knowledge). Is there a reason? I join a patch with these corrections and some small LaTeX macro changes in stat_float_times. Thank you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1412227&group_id=5470 From noreply at sourceforge.net Sun Jan 22 20:35:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 Jan 2006 11:35:33 -0800 Subject: [ python-Bugs-1412227 ] minor doc issues in os Message-ID: Bugs item #1412227, was opened at 2006-01-22 20:04 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1412227&group_id=5470 Please note that this 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: Not a Bug >Status: Closed >Resolution: Fixed Priority: 1 Submitted By: tiissa (tiissa) Assigned to: Nobody/Anonymous (nobody) Summary: minor doc issues in os Initial Comment: Section 6.1.4 in libos.tex, in the description of the stat function, there is a new paragraph on FreeBSD with an incomplete parenthesis: ..."may be available (but may be only filled out of root tries to use them:" I guess it should read "(but may be only filled out if root tries to use them):" (but I may be wrong). Also, in the walk function, there is a typo : one "dirnames" should be "dirpath" instead (when describing the effect of a modification of dirnames in a bottom-up walk). In this same walk function, os.error is used although OSError is used everywhere else (to my incomplete knowledge). Is there a reason? I join a patch with these corrections and some small LaTeX macro changes in stat_float_times. Thank you. ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-01-22 20:35 Message: Logged In: YES user_id=1188172 Thanks for pointing those out! Committed revisions 42142, 42143 (2.4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1412227&group_id=5470 From noreply at sourceforge.net Mon Jan 23 08:46:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 22 Jan 2006 23:46:53 -0800 Subject: [ python-Bugs-1412580 ] locale.format gives wrong exception on some erroneous input Message-ID: Bugs item #1412580, was opened at 2006-01-23 07:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1412580&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tim Diggins (tdiggins) Assigned to: Nobody/Anonymous (nobody) Summary: locale.format gives wrong exception on some erroneous input Initial Comment: using '2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)]' on WinXpPro SP2 locale.format(formatString, val, grouping) when passed a formatString of the wrong type, ought to raise a TypeError (as some erroneous input does) Example: locale.format(2.3, 2.3) passes through AttributeError ("float has no attribute 'split'"). I thought perhaps the body of the method should be wrapped in a try:except block, and if any error is caught, then the arguments should be rigorously tested for type and lucid exceptions raised. See attachment for suggestion (with tests). I'm not clear whether if the format string is erroneous (bad syntax, or has too many/no %-s, the raised error should be ValueError (contractually correct) or conceivably whatever StringInterpolation raises (parallelism). I've put tests for both in - currently ValueError wins. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1412580&group_id=5470 From noreply at sourceforge.net Mon Jan 23 15:07:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 Jan 2006 06:07:38 -0800 Subject: [ python-Bugs-1412837 ] __self - Watcom compiler reserved word Message-ID: Bugs item #1412837, was opened at 2006-01-23 21: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=1412837&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: kbob_ru (kbob_ru) Assigned to: Nobody/Anonymous (nobody) Summary: __self - Watcom compiler reserved word Initial Comment: in Object/cobject.c there is new function int PyCObject_SetVoidPtr(PyObject *_self, void *cobj) Here _self is local variable name, but in Watcom compiler __self is reserved word means self- based pointer. When I replase _self with something else (_myself for example), it works fine! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1412837&group_id=5470 From noreply at sourceforge.net Mon Jan 23 15:13:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 Jan 2006 06:13:43 -0800 Subject: [ python-Bugs-1412845 ] function usage not in #ifdef WITH_THREAD #endif Message-ID: Bugs item #1412845, was opened at 2006-01-23 21: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=1412845&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: kbob_ru (kbob_ru) Assigned to: Nobody/Anonymous (nobody) Summary: function usage not in #ifdef WITH_THREAD #endif Initial Comment: in Python/pystate.c the performing and declaration of static function _PyGILState_NoteThreadState is out from #ifdef WITH_THREAD #endif. When compiling --without-thread compilation or linking fail. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1412845&group_id=5470 From noreply at sourceforge.net Mon Jan 23 17:30:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 Jan 2006 08:30:50 -0800 Subject: [ python-Bugs-1199282 ] subprocess _active.remove(self) self not in list _active Message-ID: Bugs item #1199282, was opened at 2005-05-10 18:24 Message generated for change (Comment added) made by hvb_tup You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: cheops (atila-cheops) Assigned to: Peter ?strand (astrand) Summary: subprocess _active.remove(self) self not in list _active Initial Comment: I start a subprocess in a seperate thread (25 concurrent threads) in some of the threads the following error occurs Exception in thread Thread-4: Traceback (most recent call last): File "C:\Python24\lib\threading.py", line 442, in __bootstrap self.run() File "upgrade.py", line 45, in run returncode = p.wait() File "C:\Python24\lib\subprocess.py", line 765, in wait _active.remove(self) ValueError: list.remove(x): x not in list this is the code that starts the subprocess and where I wait for the result p = subprocess.Popen('command', \ stdin=None, stdout=subprocess.PIPE, \ stderr=subprocess.STDOUT, universal_newlines=True) returncode = p.wait() errormessage = p.stdout.readlines() ---------------------------------------------------------------------- Comment By: HVB bei TUP (hvb_tup) Date: 2006-01-23 16:30 Message: Logged In: YES user_id=1434251 I have a similar problem. Python 2.4.1 under MS Windows 2003, Multi-Threaded application (about concurrent 10 threads). In my case the same error occurs during _cleanup called from __init__ : File "E:\lisa_ins\ewu\coop\reporting\python\tup_lisa\util\t hreadutil.py", line 582, in callSubProcess creationflags = creationflags File "C:\Python24\lib\subprocess.py", line 506, in __init__ _cleanup() File "C:\Python24\lib\subprocess.py", line 414, in _cleanup inst.poll() File "C:\Python24\lib\subprocess.py", line 755, in poll _active.remove(self) ValueError: list.remove(x): x not in list Is there a work-around? ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2005-09-19 09:29 Message: Logged In: YES user_id=1276121 I noticed this bug under windows to reproduce the bug, I attached the script I use, but this needs input, I tried with a simpler example (pinging a number of host concurrently) but that did not cause the bug. ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2005-06-23 16:03 Message: Logged In: YES user_id=344921 I believe it should be sufficient to add a try...except clause around _active.remove(). Can you upload a complete example that triggers the bug? Have you noticed this bug on Windows, UNIX or both platforms? ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2005-05-12 10:17 Message: Logged In: YES user_id=1276121 this might be related to bug 1183780 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470 From noreply at sourceforge.net Mon Jan 23 17:34:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 Jan 2006 08:34:29 -0800 Subject: [ python-Bugs-1199282 ] subprocess _active.remove(self) self not in list _active Message-ID: Bugs item #1199282, was opened at 2005-05-10 18:24 Message generated for change (Comment added) made by hvb_tup You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: cheops (atila-cheops) Assigned to: Peter ?strand (astrand) Summary: subprocess _active.remove(self) self not in list _active Initial Comment: I start a subprocess in a seperate thread (25 concurrent threads) in some of the threads the following error occurs Exception in thread Thread-4: Traceback (most recent call last): File "C:\Python24\lib\threading.py", line 442, in __bootstrap self.run() File "upgrade.py", line 45, in run returncode = p.wait() File "C:\Python24\lib\subprocess.py", line 765, in wait _active.remove(self) ValueError: list.remove(x): x not in list this is the code that starts the subprocess and where I wait for the result p = subprocess.Popen('command', \ stdin=None, stdout=subprocess.PIPE, \ stderr=subprocess.STDOUT, universal_newlines=True) returncode = p.wait() errormessage = p.stdout.readlines() ---------------------------------------------------------------------- Comment By: HVB bei TUP (hvb_tup) Date: 2006-01-23 16:34 Message: Logged In: YES user_id=1434251 BTW: In my case, I call python.exe from a Windows service. ---------------------------------------------------------------------- Comment By: HVB bei TUP (hvb_tup) Date: 2006-01-23 16:30 Message: Logged In: YES user_id=1434251 I have a similar problem. Python 2.4.1 under MS Windows 2003, Multi-Threaded application (about concurrent 10 threads). In my case the same error occurs during _cleanup called from __init__ : File "E:\lisa_ins\ewu\coop\reporting\python\tup_lisa\util\t hreadutil.py", line 582, in callSubProcess creationflags = creationflags File "C:\Python24\lib\subprocess.py", line 506, in __init__ _cleanup() File "C:\Python24\lib\subprocess.py", line 414, in _cleanup inst.poll() File "C:\Python24\lib\subprocess.py", line 755, in poll _active.remove(self) ValueError: list.remove(x): x not in list Is there a work-around? ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2005-09-19 09:29 Message: Logged In: YES user_id=1276121 I noticed this bug under windows to reproduce the bug, I attached the script I use, but this needs input, I tried with a simpler example (pinging a number of host concurrently) but that did not cause the bug. ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2005-06-23 16:03 Message: Logged In: YES user_id=344921 I believe it should be sufficient to add a try...except clause around _active.remove(). Can you upload a complete example that triggers the bug? Have you noticed this bug on Windows, UNIX or both platforms? ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2005-05-12 10:17 Message: Logged In: YES user_id=1276121 this might be related to bug 1183780 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470 From noreply at sourceforge.net Mon Jan 23 19:36:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 Jan 2006 10:36:51 -0800 Subject: [ python-Bugs-1412845 ] function usage not in #ifdef WITH_THREAD #endif Message-ID: Bugs item #1412845, was opened at 2006-01-23 14:13 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1412845&group_id=5470 Please note that this 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: Out of Date Priority: 5 Submitted By: kbob_ru (kbob_ru) >Assigned to: Michael Hudson (mwh) Summary: function usage not in #ifdef WITH_THREAD #endif Initial Comment: in Python/pystate.c the performing and declaration of static function _PyGILState_NoteThreadState is out from #ifdef WITH_THREAD #endif. When compiling --without-thread compilation or linking fail. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2006-01-23 18:36 Message: Logged In: YES user_id=6656 This has been fixed in SVN. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1412845&group_id=5470 From noreply at sourceforge.net Mon Jan 23 21:35:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 Jan 2006 12:35:45 -0800 Subject: [ python-Bugs-1413192 ] bsddb: segfault on db.associate call with Txn and large data Message-ID: Bugs item #1413192, was opened at 2006-01-23 12: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=1413192&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Roitman (rshura) Assigned to: Nobody/Anonymous (nobody) Summary: bsddb: segfault on db.associate call with Txn and large data Initial Comment: Problem confirmed on Python2.3.5/bsddb4.2.0.5 and Python2.4.2/bsddb4.3.0 on Debian sid and Ubuntu Breezy. It appears, that the associate call, necessary to create a secondary index, segfaults when: 1. There is a large amount of data 2. Environment is transactional. The http://www.gramps-project.org/files/bsddb/testcase.tar.gz contains the example code and two databases, pm.db and pm_ok.db -- both have the same number of keys and each data item is a pickled tuple with two elements. The second index is created over the unpickled data[1]. The pm.db segfaults and the pm_ok.db does not. The second db has much smaller data items in data[0]. If the environment is set up and opened without TXN then pm.db is also fine. Seems like a problem in associate call in a TXN environment, that is only seen with large enough data. Please let me know if I can be of further assistance. This is a show-stopper issue for me, I would go out of my way to help resolving this or finding a work-around. Thanks! Alex P.S. I could not attach the large file, probably due to the size limit on the upload, hence a link to the testcase. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 From noreply at sourceforge.net Mon Jan 23 21:41:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 Jan 2006 12:41:42 -0800 Subject: [ python-Bugs-1413192 ] bsddb: segfault on db.associate call with Txn and large data Message-ID: Bugs item #1413192, was opened at 2006-01-23 12:35 Message generated for change (Comment added) made by rshura You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Roitman (rshura) Assigned to: Nobody/Anonymous (nobody) Summary: bsddb: segfault on db.associate call with Txn and large data Initial Comment: Problem confirmed on Python2.3.5/bsddb4.2.0.5 and Python2.4.2/bsddb4.3.0 on Debian sid and Ubuntu Breezy. It appears, that the associate call, necessary to create a secondary index, segfaults when: 1. There is a large amount of data 2. Environment is transactional. The http://www.gramps-project.org/files/bsddb/testcase.tar.gz contains the example code and two databases, pm.db and pm_ok.db -- both have the same number of keys and each data item is a pickled tuple with two elements. The second index is created over the unpickled data[1]. The pm.db segfaults and the pm_ok.db does not. The second db has much smaller data items in data[0]. If the environment is set up and opened without TXN then pm.db is also fine. Seems like a problem in associate call in a TXN environment, that is only seen with large enough data. Please let me know if I can be of further assistance. This is a show-stopper issue for me, I would go out of my way to help resolving this or finding a work-around. Thanks! Alex P.S. I could not attach the large file, probably due to the size limit on the upload, hence a link to the testcase. ---------------------------------------------------------------------- >Comment By: Alex Roitman (rshura) Date: 2006-01-23 12:41 Message: Logged In: YES user_id=498357 Attaching test3.py containing same code without transactions. Works fine with either pm.db or pm_ok.db ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 From noreply at sourceforge.net Mon Jan 23 21:45:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 Jan 2006 12:45:38 -0800 Subject: [ python-Bugs-1413192 ] bsddb: segfault on db.associate call with Txn and large data Message-ID: Bugs item #1413192, was opened at 2006-01-23 21:35 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Roitman (rshura) >Assigned to: Neal Norwitz (nnorwitz) Summary: bsddb: segfault on db.associate call with Txn and large data Initial Comment: Problem confirmed on Python2.3.5/bsddb4.2.0.5 and Python2.4.2/bsddb4.3.0 on Debian sid and Ubuntu Breezy. It appears, that the associate call, necessary to create a secondary index, segfaults when: 1. There is a large amount of data 2. Environment is transactional. The http://www.gramps-project.org/files/bsddb/testcase.tar.gz contains the example code and two databases, pm.db and pm_ok.db -- both have the same number of keys and each data item is a pickled tuple with two elements. The second index is created over the unpickled data[1]. The pm.db segfaults and the pm_ok.db does not. The second db has much smaller data items in data[0]. If the environment is set up and opened without TXN then pm.db is also fine. Seems like a problem in associate call in a TXN environment, that is only seen with large enough data. Please let me know if I can be of further assistance. This is a show-stopper issue for me, I would go out of my way to help resolving this or finding a work-around. Thanks! Alex P.S. I could not attach the large file, probably due to the size limit on the upload, hence a link to the testcase. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-23 21:41 Message: Logged In: YES user_id=498357 Attaching test3.py containing same code without transactions. Works fine with either pm.db or pm_ok.db ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 From noreply at sourceforge.net Tue Jan 24 03:01:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 Jan 2006 18:01:30 -0800 Subject: [ python-Bugs-1413378 ] Popenhangs with latest Cygwin update Message-ID: Bugs item #1413378, was opened at 2006-01-23 18: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=1413378&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Eric McRae (sferic) Assigned to: Martin v. L??wis (loewis) Summary: Popenhangs with latest Cygwin update Initial Comment: Today's update of my Cygwin installation caused a long running Python/Tkinter application to fail to start. Further investigation shows it hanging on a simple popen call. The problem seems associated with importing Tkinter: =========== #! /usr/bin/python from Tkinter import * from os import popen print "Here" #grab a calander in case we need it calpipe = popen("/usr/bin/cal -3") caltext = calpipe.read(1000) calpipe.close() print "There" print caltext ========== prints "Here" and hangs. Windows task manager shows sh.exe and a copy of Python2.4.exe sharing most of the CPU time. If If I comment out the from Tkinter line, everthing works fine. Cygcheck info attached ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413378&group_id=5470 From noreply at sourceforge.net Tue Jan 24 03:05:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 Jan 2006 18:05:52 -0800 Subject: [ python-Bugs-1413379 ] Popened file object close hangs in latest Cygwin update Message-ID: Bugs item #1413379, was opened at 2006-01-23 18: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=1413379&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Eric McRae (sferic) Assigned to: Martin v. L??wis (loewis) Summary: Popened file object close hangs in latest Cygwin update Initial Comment: Today's update of my Cygwin installation caused a long running Python/Tkinter application to fail to start. Further investigation shows it hanging on a closed of a popened file object. The problem seems associated with importing Tkinter: ===========FILE START===== #! /usr/bin/python from Tkinter import * from os import popen print "Here" #grab a calander in case we need it calpipe = popen("/usr/bin/cal -3") caltext = calpipe.read(1000) print "Middle" calpipe.close() print "There" print caltext ==========FILE END===== prints "Here" and "Middle" and then hangs. Windows task manager shows sh.exe and a copy of Python2.4.exe sharing most of the CPU time. If I kill those two processes, the program finishes its output normally. If I comment out the from Tkinter line, everthing works fine. Cygcheck info attached ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413379&group_id=5470 From noreply at sourceforge.net Tue Jan 24 03:08:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 Jan 2006 18:08:07 -0800 Subject: [ python-Bugs-1413378 ] Popenhangs with latest Cygwin update Message-ID: Bugs item #1413378, was opened at 2006-01-23 18:01 Message generated for change (Settings changed) made by sferic You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413378&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.4 >Status: Deleted Resolution: None Priority: 5 Submitted By: Eric McRae (sferic) Assigned to: Martin v. L??wis (loewis) Summary: Popenhangs with latest Cygwin update Initial Comment: Today's update of my Cygwin installation caused a long running Python/Tkinter application to fail to start. Further investigation shows it hanging on a simple popen call. The problem seems associated with importing Tkinter: =========== #! /usr/bin/python from Tkinter import * from os import popen print "Here" #grab a calander in case we need it calpipe = popen("/usr/bin/cal -3") caltext = calpipe.read(1000) calpipe.close() print "There" print caltext ========== prints "Here" and hangs. Windows task manager shows sh.exe and a copy of Python2.4.exe sharing most of the CPU time. If If I comment out the from Tkinter line, everthing works fine. Cygcheck info attached ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413378&group_id=5470 From noreply at sourceforge.net Tue Jan 24 07:08:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 Jan 2006 22:08:31 -0800 Subject: [ python-Bugs-1412837 ] __self - Watcom compiler reserved word Message-ID: Bugs item #1412837, was opened at 2006-01-23 06:07 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1412837&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: kbob_ru (kbob_ru) >Assigned to: Neal Norwitz (nnorwitz) Summary: __self - Watcom compiler reserved word Initial Comment: in Object/cobject.c there is new function int PyCObject_SetVoidPtr(PyObject *_self, void *cobj) Here _self is local variable name, but in Watcom compiler __self is reserved word means self- based pointer. When I replase _self with something else (_myself for example), it works fine! ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-23 22:08 Message: Logged In: YES user_id=33168 Committed revision 42167. Committed revision 42168. (2.4) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1412837&group_id=5470 From noreply at sourceforge.net Tue Jan 24 07:45:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 Jan 2006 22:45:11 -0800 Subject: [ python-Bugs-1413192 ] bsddb: segfault on db.associate call with Txn and large data Message-ID: Bugs item #1413192, was opened at 2006-01-23 12:35 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Roitman (rshura) Assigned to: Neal Norwitz (nnorwitz) Summary: bsddb: segfault on db.associate call with Txn and large data Initial Comment: Problem confirmed on Python2.3.5/bsddb4.2.0.5 and Python2.4.2/bsddb4.3.0 on Debian sid and Ubuntu Breezy. It appears, that the associate call, necessary to create a secondary index, segfaults when: 1. There is a large amount of data 2. Environment is transactional. The http://www.gramps-project.org/files/bsddb/testcase.tar.gz contains the example code and two databases, pm.db and pm_ok.db -- both have the same number of keys and each data item is a pickled tuple with two elements. The second index is created over the unpickled data[1]. The pm.db segfaults and the pm_ok.db does not. The second db has much smaller data items in data[0]. If the environment is set up and opened without TXN then pm.db is also fine. Seems like a problem in associate call in a TXN environment, that is only seen with large enough data. Please let me know if I can be of further assistance. This is a show-stopper issue for me, I would go out of my way to help resolving this or finding a work-around. Thanks! Alex P.S. I could not attach the large file, probably due to the size limit on the upload, hence a link to the testcase. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-23 22:45 Message: Logged In: YES user_id=33168 I've got a much simpler test case. The problem seems to be triggered when the txn is deleted after the env (in Modules/_bsddb.c 917 vs 966). If I change the variable names in python, I don't get the same behaviour (ie, it doesn't crash). I removed the original data file, but if you change the_txn to txn, that might "fix" the problem. If not, try playing with different variable names and see if you can get it to not crash. Obviously there needs to be a real fix in C code, but I'm not sure what needs to happen. It doesn't look like we keep enough info to do this properly. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-23 12:41 Message: Logged In: YES user_id=498357 Attaching test3.py containing same code without transactions. Works fine with either pm.db or pm_ok.db ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 From noreply at sourceforge.net Tue Jan 24 08:03:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 23 Jan 2006 23:03:02 -0800 Subject: [ python-Bugs-1413192 ] bsddb: segfault on db.associate call with Txn and large data Message-ID: Bugs item #1413192, was opened at 2006-01-23 12:35 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Roitman (rshura) Assigned to: Neal Norwitz (nnorwitz) Summary: bsddb: segfault on db.associate call with Txn and large data Initial Comment: Problem confirmed on Python2.3.5/bsddb4.2.0.5 and Python2.4.2/bsddb4.3.0 on Debian sid and Ubuntu Breezy. It appears, that the associate call, necessary to create a secondary index, segfaults when: 1. There is a large amount of data 2. Environment is transactional. The http://www.gramps-project.org/files/bsddb/testcase.tar.gz contains the example code and two databases, pm.db and pm_ok.db -- both have the same number of keys and each data item is a pickled tuple with two elements. The second index is created over the unpickled data[1]. The pm.db segfaults and the pm_ok.db does not. The second db has much smaller data items in data[0]. If the environment is set up and opened without TXN then pm.db is also fine. Seems like a problem in associate call in a TXN environment, that is only seen with large enough data. Please let me know if I can be of further assistance. This is a show-stopper issue for me, I would go out of my way to help resolving this or finding a work-around. Thanks! Alex P.S. I could not attach the large file, probably due to the size limit on the upload, hence a link to the testcase. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-23 23:03 Message: Logged In: YES user_id=33168 I spoke too soon. The attached patch works for me or your original test case and my pared down version. It also passes the tests. It also fixes a potential memory leak. Let me know if this works for you. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-23 22:45 Message: Logged In: YES user_id=33168 I've got a much simpler test case. The problem seems to be triggered when the txn is deleted after the env (in Modules/_bsddb.c 917 vs 966). If I change the variable names in python, I don't get the same behaviour (ie, it doesn't crash). I removed the original data file, but if you change the_txn to txn, that might "fix" the problem. If not, try playing with different variable names and see if you can get it to not crash. Obviously there needs to be a real fix in C code, but I'm not sure what needs to happen. It doesn't look like we keep enough info to do this properly. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-23 12:41 Message: Logged In: YES user_id=498357 Attaching test3.py containing same code without transactions. Works fine with either pm.db or pm_ok.db ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 From noreply at sourceforge.net Tue Jan 24 09:03:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 00:03:26 -0800 Subject: [ python-Bugs-1227955 ] shelve/bsddb crash on db close Message-ID: Bugs item #1227955, was opened at 2005-06-26 16:38 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227955&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Scott (ses4j) Assigned to: Nobody/Anonymous (nobody) Summary: shelve/bsddb crash on db close Initial Comment: I have a 300 meg bsddb/hash db created and accessed by shelve. No problems when running python only. But I started accessing the code that opens it via a windows DLL, opening and closing the DB on PROCESS_ATTACH and DETACH. All of a sudden, it would crash in the bsddb module on closing/del'ing the db. Found a workaround by opening the db with shelve.BsddbShelf(..) instead of shelve.open(..) - then it closed fine when the DLL unloaded, no crash. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-24 00:03 Message: Logged In: YES user_id=33168 Perhaps this is related to bug 1413192? Could you try the patch there and see if it fixes this problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227955&group_id=5470 From noreply at sourceforge.net Tue Jan 24 09:04:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 00:04:42 -0800 Subject: [ python-Bugs-788526 ] Closing dbenv first bsddb doesn't release locks & segfau Message-ID: Bugs item #788526, was opened at 2003-08-13 22:13 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788526&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jane Austine (janeaustine50) Assigned to: Gregory P. Smith (greg) Summary: Closing dbenv first bsddb doesn't release locks & segfau Initial Comment: There is a test code named test_env_close in bsddb/test, but it doesn't test the case thoroughly. There seems to be a bug in closing the db environment first -- the lock is not released, and sometimes it seg-faults. Following is the code that shows this bug. <code> import os from bsddb import db dir,dbname='test_dbenv','test_db' def getDbEnv(dir): try: os.mkdir(dir) except: pass dbenv = db.DBEnv() dbenv.open(dir, db.DB_INIT_CDB| db.DB_CREATE |db.DB_INIT_MPOOL) return dbenv def getDbHandler(db_env,db_name): d = db.DB(dbenv) d.open(db_name, db.DB_BTREE, db.DB_CREATE) return d dbenv=getDbEnv(dir) assert dbenv.lock_stat()['nlocks']==0 d=getDbHandler(dbenv,dbname) assert dbenv.lock_stat()['nlocks']==1 try: dbenv.close() except db.DBError: pass else: assert 0 del d import gc gc.collect() dbenv=getDbEnv(dir) assert dbenv.lock_stat()['nlocks']==0,'number of current locks should be 0' #this fails </code> If you close dbenv before db handler, the lock is not released. Moreover, try this with dbshelve and it segfaults. <code> >>> from bsddb import dbshelve >>> dbenv2=getDbEnv('test_dbenv2') >>> d2=dbshelve.open(dbname,dbenv=dbenv2) >>> try: ... dbenv2.close() ... except db.DBError: ... pass ... else: ... assert 0 ... >>> >>> Exception bsddb._db.DBError: (0, 'DBEnv object has been closed') in Segmentation fault </code> Tested on: 1. linux with Python 2.3 final, Berkeley DB 4.1.25 2. windows xp with Python 2.3 final (with _bsddb that comes along) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-24 00:04 Message: Logged In: YES user_id=33168 Jane could try the patch in bug 1413192 to see if it fixes your problem? ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2004-06-16 15:18 Message: Logged In: YES user_id=413 Yes this bug is still there. A "workaround" is just a "don't do that" when it comes to closing sleepycat DBEnv objects while there are things using them still open. I believe we can prevent this... One proposal: internally in _bsddb.c DBEnv could be made to keep a weak reference to all objects created using it (DB and DBLock objects) and refuse to call the sleepycat close() method if any still exist (overridable using a force=1 flag). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-06-15 20:14 Message: Logged In: YES user_id=33168 Greg do you know anything about this? Is it still a problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788526&group_id=5470 From noreply at sourceforge.net Tue Jan 24 16:52:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 07:52:23 -0800 Subject: [ python-Bugs-495682 ] cannot handle http_proxy with user:pass@ Message-ID: Bugs item #495682, was opened at 2001-12-21 01:22 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=495682&group_id=5470 Please note that this message will contain 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: 3 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: cannot handle http_proxy with user:pass@ Initial Comment: [please CC 120013 at bugs.debian.org; the original report can be found at http://bugs.debian.org/120013 ] I tried to use an http_proxy variable which looks like: http://user:pass at proxy:3128/ with pass like \jkIoPd{ And I got this error : Traceback (most recent call last): File "/usr/bin/reportbug", line 1146, in ? main() File "/usr/bin/reportbug", line 628, in main http_proxy) File "/usr/lib/site-python/reportbug_ui_text.py", line 314, in handle_bts_query archived=archived) File "/usr/lib/site-python/debianbts.py", line 575, in get_reports result = get_cgi_reports(package, system, http_proxy, archived) File "/usr/lib/site-python/debianbts.py", line 494, in get_cgi_reports page = urlopen(url, proxies=proxies) File "/usr/lib/site-python/debianbts.py", line 382, in urlopen return _urlopener.open(url) File "/usr/lib/python2.1/urllib.py", line 176, in open return getattr(self, name)(url) File "/usr/lib/python2.1/urllib.py", line 277, in open_http h = httplib.HTTP(host) File "/usr/lib/python2.1/httplib.py", line 663, in __init__ self._conn = self._connection_class(host, port) File "/usr/lib/python2.1/httplib.py", line 342, in __init__ self._set_hostport(host, port) File "/usr/lib/python2.1/httplib.py", line 348, in _set_hostport port = int(host[i+1:]) ValueError: invalid literal for int(): \jkIoPd {@proxy:3128 But if I use http_proxy=http://10.0.0.1:3128/, it works well. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-01-24 16:52 Message: Logged In: YES user_id=21627 Fixed with said patch. ---------------------------------------------------------------------- Comment By: Johannes Nicolai (jonico) Date: 2005-11-05 18:09 Message: Logged In: YES user_id=863272 I have proposed a patch for this in the patch section: 1349118 is the number of the patch URL: https://sourceforge.net/tracker/index.php?func=detail&aid=1349118&group_id=5470&atid=305470 The patch also solves some other issues with proxies (now it correct handles protocols, where a proxy was specified but not supported and https proxies will also be used if a host requires www-authentification) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 23:28 Message: Logged In: YES user_id=6380 This is a feature request. If someone submits a patch, we'll happily apply it. It looks like urllib2 already supports this feature; you could try using that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=495682&group_id=5470 From noreply at sourceforge.net Tue Jan 24 16:57:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 07:57:27 -0800 Subject: [ python-Bugs-1413790 ] zipfile: inserting some filenames produces corrupt .zips Message-ID: Bugs item #1413790, was opened at 2006-01-24 09: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=1413790&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Grant Olson (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile: inserting some filenames produces corrupt .zips Initial Comment: Running something like the following produces a corrupt .zip file. The builtin XP zip folder view won't show any documents and attempting to extract via "right click -> Extract files..." will set off an untrusted file alert: import zipfile z = zipfile.ZipFile("c:\\foo.zip","w") z.write("c:\\autoexec.bat", "\\autoexec.bat") z.close() zipfile should either throw an error when adding these files or attempt to normalize the path. I would prefer that zipfile make the assumption that any files starting with absolute or relative pathnames ("\\foo\\bar.txt" or ".\\foo\\bar.txt") should join in at the root of the zipfile ("foo\\bar.txt" in this case). Patch to accomplish the latter is attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413790&group_id=5470 From noreply at sourceforge.net Tue Jan 24 19:50:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 10:50:21 -0800 Subject: [ python-Bugs-1413192 ] bsddb: segfault on db.associate call with Txn and large data Message-ID: Bugs item #1413192, was opened at 2006-01-23 12:35 Message generated for change (Comment added) made by rshura You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Roitman (rshura) Assigned to: Neal Norwitz (nnorwitz) Summary: bsddb: segfault on db.associate call with Txn and large data Initial Comment: Problem confirmed on Python2.3.5/bsddb4.2.0.5 and Python2.4.2/bsddb4.3.0 on Debian sid and Ubuntu Breezy. It appears, that the associate call, necessary to create a secondary index, segfaults when: 1. There is a large amount of data 2. Environment is transactional. The http://www.gramps-project.org/files/bsddb/testcase.tar.gz contains the example code and two databases, pm.db and pm_ok.db -- both have the same number of keys and each data item is a pickled tuple with two elements. The second index is created over the unpickled data[1]. The pm.db segfaults and the pm_ok.db does not. The second db has much smaller data items in data[0]. If the environment is set up and opened without TXN then pm.db is also fine. Seems like a problem in associate call in a TXN environment, that is only seen with large enough data. Please let me know if I can be of further assistance. This is a show-stopper issue for me, I would go out of my way to help resolving this or finding a work-around. Thanks! Alex P.S. I could not attach the large file, probably due to the size limit on the upload, hence a link to the testcase. ---------------------------------------------------------------------- >Comment By: Alex Roitman (rshura) Date: 2006-01-24 10:50 Message: Logged In: YES user_id=498357 Thanks for a quick response! OK, first thing first: your simpler testcase seems to expose yet another problem, not the one I had. In particular, your testcase segfaults for me on python2.4.2/bsddb4.3.0 but *does not* segfault with python2.3.5/bsddb4.2.0.5 In my testcase, I can definitely blame the segfault on the associate call, not on open. I can demonstrate it by either commenting out the associate call (no segfault) or by inserting a print statement right before the associate. So your testcase does not seem to have an exact same problem than my testcase. In my testcase nothing seems to depend on variable names (as one would expect). I am rebuilding python2.4 with your patch, will post results soon. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-23 23:03 Message: Logged In: YES user_id=33168 I spoke too soon. The attached patch works for me or your original test case and my pared down version. It also passes the tests. It also fixes a potential memory leak. Let me know if this works for you. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-23 22:45 Message: Logged In: YES user_id=33168 I've got a much simpler test case. The problem seems to be triggered when the txn is deleted after the env (in Modules/_bsddb.c 917 vs 966). If I change the variable names in python, I don't get the same behaviour (ie, it doesn't crash). I removed the original data file, but if you change the_txn to txn, that might "fix" the problem. If not, try playing with different variable names and see if you can get it to not crash. Obviously there needs to be a real fix in C code, but I'm not sure what needs to happen. It doesn't look like we keep enough info to do this properly. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-23 12:41 Message: Logged In: YES user_id=498357 Attaching test3.py containing same code without transactions. Works fine with either pm.db or pm_ok.db ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 From noreply at sourceforge.net Tue Jan 24 20:31:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 11:31:46 -0800 Subject: [ python-Bugs-1413192 ] bsddb: segfault on db.associate call with Txn and large data Message-ID: Bugs item #1413192, was opened at 2006-01-23 12:35 Message generated for change (Comment added) made by rshura You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Roitman (rshura) Assigned to: Neal Norwitz (nnorwitz) Summary: bsddb: segfault on db.associate call with Txn and large data Initial Comment: Problem confirmed on Python2.3.5/bsddb4.2.0.5 and Python2.4.2/bsddb4.3.0 on Debian sid and Ubuntu Breezy. It appears, that the associate call, necessary to create a secondary index, segfaults when: 1. There is a large amount of data 2. Environment is transactional. The http://www.gramps-project.org/files/bsddb/testcase.tar.gz contains the example code and two databases, pm.db and pm_ok.db -- both have the same number of keys and each data item is a pickled tuple with two elements. The second index is created over the unpickled data[1]. The pm.db segfaults and the pm_ok.db does not. The second db has much smaller data items in data[0]. If the environment is set up and opened without TXN then pm.db is also fine. Seems like a problem in associate call in a TXN environment, that is only seen with large enough data. Please let me know if I can be of further assistance. This is a show-stopper issue for me, I would go out of my way to help resolving this or finding a work-around. Thanks! Alex P.S. I could not attach the large file, probably due to the size limit on the upload, hence a link to the testcase. ---------------------------------------------------------------------- >Comment By: Alex Roitman (rshura) Date: 2006-01-24 11:31 Message: Logged In: YES user_id=498357 OK, built and installed all kinds of python packages with the patch. All tests are fine. Here goes: 1. Your testcase goes just fine, no segfault with the patched version. 2. Mine still segfaults. 3. I ran mine under gdb with python2.4-dbg package, here's the output (printed "shurafine" is my addition, to make sure that the correct code is being run): $ gdb python2.4-dbg GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) run test2.py Starting program: /usr/bin/python2.4-dbg test2.py [Thread debugging using libthread_db enabled] [New Thread -1210038592 (LWP 29629)] shurafine Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210038592 (LWP 29629)] 0xb7b57f3e in DB_associate (self=0xb7db9f58, args=0xb7dbd3b4, kwargs=0xb7db5e94) at /home/shura/src/python2.4-2.4.2/Modules/_bsddb.c:1219 1219 Py_DECREF(self->associateCallback); (gdb) Please let me know if I can be of further assistance. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 10:50 Message: Logged In: YES user_id=498357 Thanks for a quick response! OK, first thing first: your simpler testcase seems to expose yet another problem, not the one I had. In particular, your testcase segfaults for me on python2.4.2/bsddb4.3.0 but *does not* segfault with python2.3.5/bsddb4.2.0.5 In my testcase, I can definitely blame the segfault on the associate call, not on open. I can demonstrate it by either commenting out the associate call (no segfault) or by inserting a print statement right before the associate. So your testcase does not seem to have an exact same problem than my testcase. In my testcase nothing seems to depend on variable names (as one would expect). I am rebuilding python2.4 with your patch, will post results soon. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-23 23:03 Message: Logged In: YES user_id=33168 I spoke too soon. The attached patch works for me or your original test case and my pared down version. It also passes the tests. It also fixes a potential memory leak. Let me know if this works for you. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-23 22:45 Message: Logged In: YES user_id=33168 I've got a much simpler test case. The problem seems to be triggered when the txn is deleted after the env (in Modules/_bsddb.c 917 vs 966). If I change the variable names in python, I don't get the same behaviour (ie, it doesn't crash). I removed the original data file, but if you change the_txn to txn, that might "fix" the problem. If not, try playing with different variable names and see if you can get it to not crash. Obviously there needs to be a real fix in C code, but I'm not sure what needs to happen. It doesn't look like we keep enough info to do this properly. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-23 12:41 Message: Logged In: YES user_id=498357 Attaching test3.py containing same code without transactions. Works fine with either pm.db or pm_ok.db ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 From noreply at sourceforge.net Tue Jan 24 20:37:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 11:37:49 -0800 Subject: [ python-Bugs-1413192 ] bsddb: segfault on db.associate call with Txn and large data Message-ID: Bugs item #1413192, was opened at 2006-01-23 12:35 Message generated for change (Comment added) made by rshura You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Roitman (rshura) Assigned to: Neal Norwitz (nnorwitz) Summary: bsddb: segfault on db.associate call with Txn and large data Initial Comment: Problem confirmed on Python2.3.5/bsddb4.2.0.5 and Python2.4.2/bsddb4.3.0 on Debian sid and Ubuntu Breezy. It appears, that the associate call, necessary to create a secondary index, segfaults when: 1. There is a large amount of data 2. Environment is transactional. The http://www.gramps-project.org/files/bsddb/testcase.tar.gz contains the example code and two databases, pm.db and pm_ok.db -- both have the same number of keys and each data item is a pickled tuple with two elements. The second index is created over the unpickled data[1]. The pm.db segfaults and the pm_ok.db does not. The second db has much smaller data items in data[0]. If the environment is set up and opened without TXN then pm.db is also fine. Seems like a problem in associate call in a TXN environment, that is only seen with large enough data. Please let me know if I can be of further assistance. This is a show-stopper issue for me, I would go out of my way to help resolving this or finding a work-around. Thanks! Alex P.S. I could not attach the large file, probably due to the size limit on the upload, hence a link to the testcase. ---------------------------------------------------------------------- >Comment By: Alex Roitman (rshura) Date: 2006-01-24 11:37 Message: Logged In: YES user_id=498357 Done same tests on another Debian sid machine, exact same results (up to one line number, due to my extra fprintf statement): (gdb) run test2.py Starting program: /usr/bin/python2.4-dbg test2.py [Thread debugging using libthread_db enabled] [New Thread -1210390848 (LWP 5865)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210390848 (LWP 5865)] 0xb7b01eb4 in DB_associate (self=0xb7d63df0, args=0xb7d67234, kwargs=0xb7d5ee94) at /home/shura/src/python2.4-2.4.2/Modules/_bsddb.c:1218 1218 Py_DECREF(self->associateCallback); (gdb) ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 11:31 Message: Logged In: YES user_id=498357 OK, built and installed all kinds of python packages with the patch. All tests are fine. Here goes: 1. Your testcase goes just fine, no segfault with the patched version. 2. Mine still segfaults. 3. I ran mine under gdb with python2.4-dbg package, here's the output (printed "shurafine" is my addition, to make sure that the correct code is being run): $ gdb python2.4-dbg GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) run test2.py Starting program: /usr/bin/python2.4-dbg test2.py [Thread debugging using libthread_db enabled] [New Thread -1210038592 (LWP 29629)] shurafine Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210038592 (LWP 29629)] 0xb7b57f3e in DB_associate (self=0xb7db9f58, args=0xb7dbd3b4, kwargs=0xb7db5e94) at /home/shura/src/python2.4-2.4.2/Modules/_bsddb.c:1219 1219 Py_DECREF(self->associateCallback); (gdb) Please let me know if I can be of further assistance. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 10:50 Message: Logged In: YES user_id=498357 Thanks for a quick response! OK, first thing first: your simpler testcase seems to expose yet another problem, not the one I had. In particular, your testcase segfaults for me on python2.4.2/bsddb4.3.0 but *does not* segfault with python2.3.5/bsddb4.2.0.5 In my testcase, I can definitely blame the segfault on the associate call, not on open. I can demonstrate it by either commenting out the associate call (no segfault) or by inserting a print statement right before the associate. So your testcase does not seem to have an exact same problem than my testcase. In my testcase nothing seems to depend on variable names (as one would expect). I am rebuilding python2.4 with your patch, will post results soon. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-23 23:03 Message: Logged In: YES user_id=33168 I spoke too soon. The attached patch works for me or your original test case and my pared down version. It also passes the tests. It also fixes a potential memory leak. Let me know if this works for you. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-23 22:45 Message: Logged In: YES user_id=33168 I've got a much simpler test case. The problem seems to be triggered when the txn is deleted after the env (in Modules/_bsddb.c 917 vs 966). If I change the variable names in python, I don't get the same behaviour (ie, it doesn't crash). I removed the original data file, but if you change the_txn to txn, that might "fix" the problem. If not, try playing with different variable names and see if you can get it to not crash. Obviously there needs to be a real fix in C code, but I'm not sure what needs to happen. It doesn't look like we keep enough info to do this properly. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-23 12:41 Message: Logged In: YES user_id=498357 Attaching test3.py containing same code without transactions. Works fine with either pm.db or pm_ok.db ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 From noreply at sourceforge.net Tue Jan 24 20:40:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 11:40:17 -0800 Subject: [ python-Bugs-1413192 ] bsddb: segfault on db.associate call with Txn and large data Message-ID: Bugs item #1413192, was opened at 2006-01-23 12:35 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Roitman (rshura) Assigned to: Neal Norwitz (nnorwitz) Summary: bsddb: segfault on db.associate call with Txn and large data Initial Comment: Problem confirmed on Python2.3.5/bsddb4.2.0.5 and Python2.4.2/bsddb4.3.0 on Debian sid and Ubuntu Breezy. It appears, that the associate call, necessary to create a secondary index, segfaults when: 1. There is a large amount of data 2. Environment is transactional. The http://www.gramps-project.org/files/bsddb/testcase.tar.gz contains the example code and two databases, pm.db and pm_ok.db -- both have the same number of keys and each data item is a pickled tuple with two elements. The second index is created over the unpickled data[1]. The pm.db segfaults and the pm_ok.db does not. The second db has much smaller data items in data[0]. If the environment is set up and opened without TXN then pm.db is also fine. Seems like a problem in associate call in a TXN environment, that is only seen with large enough data. Please let me know if I can be of further assistance. This is a show-stopper issue for me, I would go out of my way to help resolving this or finding a work-around. Thanks! Alex P.S. I could not attach the large file, probably due to the size limit on the upload, hence a link to the testcase. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-24 11:40 Message: Logged In: YES user_id=33168 Could you pull the version of Modules/_bsddb.c out of SVN and then apply my patch? I believe your new problem was fixed recently. You can look in the Misc/NEWS file to find the exact patch. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 11:37 Message: Logged In: YES user_id=498357 Done same tests on another Debian sid machine, exact same results (up to one line number, due to my extra fprintf statement): (gdb) run test2.py Starting program: /usr/bin/python2.4-dbg test2.py [Thread debugging using libthread_db enabled] [New Thread -1210390848 (LWP 5865)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210390848 (LWP 5865)] 0xb7b01eb4 in DB_associate (self=0xb7d63df0, args=0xb7d67234, kwargs=0xb7d5ee94) at /home/shura/src/python2.4-2.4.2/Modules/_bsddb.c:1218 1218 Py_DECREF(self->associateCallback); (gdb) ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 11:31 Message: Logged In: YES user_id=498357 OK, built and installed all kinds of python packages with the patch. All tests are fine. Here goes: 1. Your testcase goes just fine, no segfault with the patched version. 2. Mine still segfaults. 3. I ran mine under gdb with python2.4-dbg package, here's the output (printed "shurafine" is my addition, to make sure that the correct code is being run): $ gdb python2.4-dbg GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) run test2.py Starting program: /usr/bin/python2.4-dbg test2.py [Thread debugging using libthread_db enabled] [New Thread -1210038592 (LWP 29629)] shurafine Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210038592 (LWP 29629)] 0xb7b57f3e in DB_associate (self=0xb7db9f58, args=0xb7dbd3b4, kwargs=0xb7db5e94) at /home/shura/src/python2.4-2.4.2/Modules/_bsddb.c:1219 1219 Py_DECREF(self->associateCallback); (gdb) Please let me know if I can be of further assistance. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 10:50 Message: Logged In: YES user_id=498357 Thanks for a quick response! OK, first thing first: your simpler testcase seems to expose yet another problem, not the one I had. In particular, your testcase segfaults for me on python2.4.2/bsddb4.3.0 but *does not* segfault with python2.3.5/bsddb4.2.0.5 In my testcase, I can definitely blame the segfault on the associate call, not on open. I can demonstrate it by either commenting out the associate call (no segfault) or by inserting a print statement right before the associate. So your testcase does not seem to have an exact same problem than my testcase. In my testcase nothing seems to depend on variable names (as one would expect). I am rebuilding python2.4 with your patch, will post results soon. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-23 23:03 Message: Logged In: YES user_id=33168 I spoke too soon. The attached patch works for me or your original test case and my pared down version. It also passes the tests. It also fixes a potential memory leak. Let me know if this works for you. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-23 22:45 Message: Logged In: YES user_id=33168 I've got a much simpler test case. The problem seems to be triggered when the txn is deleted after the env (in Modules/_bsddb.c 917 vs 966). If I change the variable names in python, I don't get the same behaviour (ie, it doesn't crash). I removed the original data file, but if you change the_txn to txn, that might "fix" the problem. If not, try playing with different variable names and see if you can get it to not crash. Obviously there needs to be a real fix in C code, but I'm not sure what needs to happen. It doesn't look like we keep enough info to do this properly. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-23 12:41 Message: Logged In: YES user_id=498357 Attaching test3.py containing same code without transactions. Works fine with either pm.db or pm_ok.db ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 From noreply at sourceforge.net Tue Jan 24 21:14:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 12:14:22 -0800 Subject: [ python-Bugs-1413192 ] bsddb: segfault on db.associate call with Txn and large data Message-ID: Bugs item #1413192, was opened at 2006-01-23 12:35 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Roitman (rshura) Assigned to: Neal Norwitz (nnorwitz) Summary: bsddb: segfault on db.associate call with Txn and large data Initial Comment: Problem confirmed on Python2.3.5/bsddb4.2.0.5 and Python2.4.2/bsddb4.3.0 on Debian sid and Ubuntu Breezy. It appears, that the associate call, necessary to create a secondary index, segfaults when: 1. There is a large amount of data 2. Environment is transactional. The http://www.gramps-project.org/files/bsddb/testcase.tar.gz contains the example code and two databases, pm.db and pm_ok.db -- both have the same number of keys and each data item is a pickled tuple with two elements. The second index is created over the unpickled data[1]. The pm.db segfaults and the pm_ok.db does not. The second db has much smaller data items in data[0]. If the environment is set up and opened without TXN then pm.db is also fine. Seems like a problem in associate call in a TXN environment, that is only seen with large enough data. Please let me know if I can be of further assistance. This is a show-stopper issue for me, I would go out of my way to help resolving this or finding a work-around. Thanks! Alex P.S. I could not attach the large file, probably due to the size limit on the upload, hence a link to the testcase. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2006-01-24 12:14 Message: Logged In: YES user_id=413 fwiw your patch looks good. it makes sense for a DBTxn to hold a reference to its DBEnv. (I suspect there may still be problems if someone calls DBEnv.close while there are outstanding DBTxn's but doing something about that would be a lot more work if its an actual issue) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-24 11:40 Message: Logged In: YES user_id=33168 Could you pull the version of Modules/_bsddb.c out of SVN and then apply my patch? I believe your new problem was fixed recently. You can look in the Misc/NEWS file to find the exact patch. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 11:37 Message: Logged In: YES user_id=498357 Done same tests on another Debian sid machine, exact same results (up to one line number, due to my extra fprintf statement): (gdb) run test2.py Starting program: /usr/bin/python2.4-dbg test2.py [Thread debugging using libthread_db enabled] [New Thread -1210390848 (LWP 5865)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210390848 (LWP 5865)] 0xb7b01eb4 in DB_associate (self=0xb7d63df0, args=0xb7d67234, kwargs=0xb7d5ee94) at /home/shura/src/python2.4-2.4.2/Modules/_bsddb.c:1218 1218 Py_DECREF(self->associateCallback); (gdb) ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 11:31 Message: Logged In: YES user_id=498357 OK, built and installed all kinds of python packages with the patch. All tests are fine. Here goes: 1. Your testcase goes just fine, no segfault with the patched version. 2. Mine still segfaults. 3. I ran mine under gdb with python2.4-dbg package, here's the output (printed "shurafine" is my addition, to make sure that the correct code is being run): $ gdb python2.4-dbg GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) run test2.py Starting program: /usr/bin/python2.4-dbg test2.py [Thread debugging using libthread_db enabled] [New Thread -1210038592 (LWP 29629)] shurafine Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210038592 (LWP 29629)] 0xb7b57f3e in DB_associate (self=0xb7db9f58, args=0xb7dbd3b4, kwargs=0xb7db5e94) at /home/shura/src/python2.4-2.4.2/Modules/_bsddb.c:1219 1219 Py_DECREF(self->associateCallback); (gdb) Please let me know if I can be of further assistance. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 10:50 Message: Logged In: YES user_id=498357 Thanks for a quick response! OK, first thing first: your simpler testcase seems to expose yet another problem, not the one I had. In particular, your testcase segfaults for me on python2.4.2/bsddb4.3.0 but *does not* segfault with python2.3.5/bsddb4.2.0.5 In my testcase, I can definitely blame the segfault on the associate call, not on open. I can demonstrate it by either commenting out the associate call (no segfault) or by inserting a print statement right before the associate. So your testcase does not seem to have an exact same problem than my testcase. In my testcase nothing seems to depend on variable names (as one would expect). I am rebuilding python2.4 with your patch, will post results soon. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-23 23:03 Message: Logged In: YES user_id=33168 I spoke too soon. The attached patch works for me or your original test case and my pared down version. It also passes the tests. It also fixes a potential memory leak. Let me know if this works for you. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-23 22:45 Message: Logged In: YES user_id=33168 I've got a much simpler test case. The problem seems to be triggered when the txn is deleted after the env (in Modules/_bsddb.c 917 vs 966). If I change the variable names in python, I don't get the same behaviour (ie, it doesn't crash). I removed the original data file, but if you change the_txn to txn, that might "fix" the problem. If not, try playing with different variable names and see if you can get it to not crash. Obviously there needs to be a real fix in C code, but I'm not sure what needs to happen. It doesn't look like we keep enough info to do this properly. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-23 12:41 Message: Logged In: YES user_id=498357 Attaching test3.py containing same code without transactions. Works fine with either pm.db or pm_ok.db ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 From noreply at sourceforge.net Tue Jan 24 21:19:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 12:19:56 -0800 Subject: [ python-Bugs-1414018 ] email.Utils.py: UnicodeError in RFC2322 header Message-ID: Bugs item #1414018, was opened at 2006-01-25 05:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1414018&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: A. Sagawa (qbin) Assigned to: Nobody/Anonymous (nobody) Summary: email.Utils.py: UnicodeError in RFC2322 header Initial Comment: Description: collapse_rfc2231_value does not handle UnicodeError exception. Therefore a header like this one can cause UnicodeError in attempting unicode conversion. --- Content-Type: text/plain; charset="ISO-2022-JP" Content-Disposition: attachment; filename*=iso-2022-jp''%1B%24BJs9p%3Dq%2D%21%1B%28B%2Etxt --- Test script: --- #! /usr/bin/env python import sys import email msg = email.message_from_file(sys.stdin) for part in msg.walk(): print part.get_params() print part.get_filename() --- run % env LANG=ja_JP.eucJP ./test.py < attached_sample.eml Background: Character 0x2d21 is invalid in JIS X0208 but defined in CP932 (Shift_JIS's superset by Microsoft). Conversion between Shift_JIS and ISO-2022-JP are computable because both of them based on JIS X0208. So sometimes CP932 characters appear in ISO-2022-JP encoded string, typically produced by Windows MUA. But Python's "ISO-2022-JP" means *pure* JIS X0208, thus conversion is failed. Workaround: Convert to fallback_charset and/or skip invalid character. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1414018&group_id=5470 From noreply at sourceforge.net Tue Jan 24 21:40:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 12:40:43 -0800 Subject: [ python-Bugs-1414018 ] email.Utils.py: UnicodeError in RFC2322 header Message-ID: Bugs item #1414018, was opened at 2006-01-24 21:19 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1414018&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: A. Sagawa (qbin) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Utils.py: UnicodeError in RFC2322 header Initial Comment: Description: collapse_rfc2231_value does not handle UnicodeError exception. Therefore a header like this one can cause UnicodeError in attempting unicode conversion. --- Content-Type: text/plain; charset="ISO-2022-JP" Content-Disposition: attachment; filename*=iso-2022-jp''%1B%24BJs9p%3Dq%2D%21%1B%28B%2Etxt --- Test script: --- #! /usr/bin/env python import sys import email msg = email.message_from_file(sys.stdin) for part in msg.walk(): print part.get_params() print part.get_filename() --- run % env LANG=ja_JP.eucJP ./test.py < attached_sample.eml Background: Character 0x2d21 is invalid in JIS X0208 but defined in CP932 (Shift_JIS's superset by Microsoft). Conversion between Shift_JIS and ISO-2022-JP are computable because both of them based on JIS X0208. So sometimes CP932 characters appear in ISO-2022-JP encoded string, typically produced by Windows MUA. But Python's "ISO-2022-JP" means *pure* JIS X0208, thus conversion is failed. Workaround: Convert to fallback_charset and/or skip invalid character. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1414018&group_id=5470 From noreply at sourceforge.net Tue Jan 24 21:50:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 12:50:52 -0800 Subject: [ python-Bugs-1413192 ] bsddb: segfault on db.associate call with Txn and large data Message-ID: Bugs item #1413192, was opened at 2006-01-23 12:35 Message generated for change (Comment added) made by rshura You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Roitman (rshura) Assigned to: Neal Norwitz (nnorwitz) Summary: bsddb: segfault on db.associate call with Txn and large data Initial Comment: Problem confirmed on Python2.3.5/bsddb4.2.0.5 and Python2.4.2/bsddb4.3.0 on Debian sid and Ubuntu Breezy. It appears, that the associate call, necessary to create a secondary index, segfaults when: 1. There is a large amount of data 2. Environment is transactional. The http://www.gramps-project.org/files/bsddb/testcase.tar.gz contains the example code and two databases, pm.db and pm_ok.db -- both have the same number of keys and each data item is a pickled tuple with two elements. The second index is created over the unpickled data[1]. The pm.db segfaults and the pm_ok.db does not. The second db has much smaller data items in data[0]. If the environment is set up and opened without TXN then pm.db is also fine. Seems like a problem in associate call in a TXN environment, that is only seen with large enough data. Please let me know if I can be of further assistance. This is a show-stopper issue for me, I would go out of my way to help resolving this or finding a work-around. Thanks! Alex P.S. I could not attach the large file, probably due to the size limit on the upload, hence a link to the testcase. ---------------------------------------------------------------------- >Comment By: Alex Roitman (rshura) Date: 2006-01-24 12:50 Message: Logged In: YES user_id=498357 With the SVN version of _bsddb.c I no longer have segfault with my test. Instead I have the following exception: Traceback (most recent call last): File "test2.py", line 37, in ? person_map.associate(surnames,find_surname,db.DB_CREATE,txn=the_txn) MemoryError: (12, 'Cannot allocate memory -- Lock table is out of available locks') Now, please bear with me here if you can. It's easy to shrug it off saying that I simply don't have enough locks for this huge txn. But the exact same code works fine with the pm_ok.db file from my testcase, and that file has exact same number of elements and exact same structure of both the data and the secondary index computation. So one would think that it needs exact same number of locks, and yet it works while pm.db does not. The only difference between the two data files is that in each data item, data[0] is much larger in pm.db and smaller in pm_ok.db Is it remotely possible that the actual error has nothing to do with locks but rather with the data size? What can I do to find out or fix this? Thanks for you help! ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2006-01-24 12:14 Message: Logged In: YES user_id=413 fwiw your patch looks good. it makes sense for a DBTxn to hold a reference to its DBEnv. (I suspect there may still be problems if someone calls DBEnv.close while there are outstanding DBTxn's but doing something about that would be a lot more work if its an actual issue) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-24 11:40 Message: Logged In: YES user_id=33168 Could you pull the version of Modules/_bsddb.c out of SVN and then apply my patch? I believe your new problem was fixed recently. You can look in the Misc/NEWS file to find the exact patch. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 11:37 Message: Logged In: YES user_id=498357 Done same tests on another Debian sid machine, exact same results (up to one line number, due to my extra fprintf statement): (gdb) run test2.py Starting program: /usr/bin/python2.4-dbg test2.py [Thread debugging using libthread_db enabled] [New Thread -1210390848 (LWP 5865)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210390848 (LWP 5865)] 0xb7b01eb4 in DB_associate (self=0xb7d63df0, args=0xb7d67234, kwargs=0xb7d5ee94) at /home/shura/src/python2.4-2.4.2/Modules/_bsddb.c:1218 1218 Py_DECREF(self->associateCallback); (gdb) ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 11:31 Message: Logged In: YES user_id=498357 OK, built and installed all kinds of python packages with the patch. All tests are fine. Here goes: 1. Your testcase goes just fine, no segfault with the patched version. 2. Mine still segfaults. 3. I ran mine under gdb with python2.4-dbg package, here's the output (printed "shurafine" is my addition, to make sure that the correct code is being run): $ gdb python2.4-dbg GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) run test2.py Starting program: /usr/bin/python2.4-dbg test2.py [Thread debugging using libthread_db enabled] [New Thread -1210038592 (LWP 29629)] shurafine Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210038592 (LWP 29629)] 0xb7b57f3e in DB_associate (self=0xb7db9f58, args=0xb7dbd3b4, kwargs=0xb7db5e94) at /home/shura/src/python2.4-2.4.2/Modules/_bsddb.c:1219 1219 Py_DECREF(self->associateCallback); (gdb) Please let me know if I can be of further assistance. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 10:50 Message: Logged In: YES user_id=498357 Thanks for a quick response! OK, first thing first: your simpler testcase seems to expose yet another problem, not the one I had. In particular, your testcase segfaults for me on python2.4.2/bsddb4.3.0 but *does not* segfault with python2.3.5/bsddb4.2.0.5 In my testcase, I can definitely blame the segfault on the associate call, not on open. I can demonstrate it by either commenting out the associate call (no segfault) or by inserting a print statement right before the associate. So your testcase does not seem to have an exact same problem than my testcase. In my testcase nothing seems to depend on variable names (as one would expect). I am rebuilding python2.4 with your patch, will post results soon. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-23 23:03 Message: Logged In: YES user_id=33168 I spoke too soon. The attached patch works for me or your original test case and my pared down version. It also passes the tests. It also fixes a potential memory leak. Let me know if this works for you. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-23 22:45 Message: Logged In: YES user_id=33168 I've got a much simpler test case. The problem seems to be triggered when the txn is deleted after the env (in Modules/_bsddb.c 917 vs 966). If I change the variable names in python, I don't get the same behaviour (ie, it doesn't crash). I removed the original data file, but if you change the_txn to txn, that might "fix" the problem. If not, try playing with different variable names and see if you can get it to not crash. Obviously there needs to be a real fix in C code, but I'm not sure what needs to happen. It doesn't look like we keep enough info to do this properly. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-23 12:41 Message: Logged In: YES user_id=498357 Attaching test3.py containing same code without transactions. Works fine with either pm.db or pm_ok.db ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 From noreply at sourceforge.net Tue Jan 24 22:12:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 13:12:47 -0800 Subject: [ python-Bugs-1413192 ] bsddb: segfault on db.associate call with Txn and large data Message-ID: Bugs item #1413192, was opened at 2006-01-23 12:35 Message generated for change (Comment added) made by rshura You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Roitman (rshura) Assigned to: Neal Norwitz (nnorwitz) Summary: bsddb: segfault on db.associate call with Txn and large data Initial Comment: Problem confirmed on Python2.3.5/bsddb4.2.0.5 and Python2.4.2/bsddb4.3.0 on Debian sid and Ubuntu Breezy. It appears, that the associate call, necessary to create a secondary index, segfaults when: 1. There is a large amount of data 2. Environment is transactional. The http://www.gramps-project.org/files/bsddb/testcase.tar.gz contains the example code and two databases, pm.db and pm_ok.db -- both have the same number of keys and each data item is a pickled tuple with two elements. The second index is created over the unpickled data[1]. The pm.db segfaults and the pm_ok.db does not. The second db has much smaller data items in data[0]. If the environment is set up and opened without TXN then pm.db is also fine. Seems like a problem in associate call in a TXN environment, that is only seen with large enough data. Please let me know if I can be of further assistance. This is a show-stopper issue for me, I would go out of my way to help resolving this or finding a work-around. Thanks! Alex P.S. I could not attach the large file, probably due to the size limit on the upload, hence a link to the testcase. ---------------------------------------------------------------------- >Comment By: Alex Roitman (rshura) Date: 2006-01-24 13:12 Message: Logged In: YES user_id=498357 Tried increasing locks, lockers, and locked objects to 10000 each and seems to help. So I guess the number of locks is data-size specific. I guess this is indeed a lock issue, so it's my problem now and not yours :-) Thanks for your help! ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 12:50 Message: Logged In: YES user_id=498357 With the SVN version of _bsddb.c I no longer have segfault with my test. Instead I have the following exception: Traceback (most recent call last): File "test2.py", line 37, in ? person_map.associate(surnames,find_surname,db.DB_CREATE,txn=the_txn) MemoryError: (12, 'Cannot allocate memory -- Lock table is out of available locks') Now, please bear with me here if you can. It's easy to shrug it off saying that I simply don't have enough locks for this huge txn. But the exact same code works fine with the pm_ok.db file from my testcase, and that file has exact same number of elements and exact same structure of both the data and the secondary index computation. So one would think that it needs exact same number of locks, and yet it works while pm.db does not. The only difference between the two data files is that in each data item, data[0] is much larger in pm.db and smaller in pm_ok.db Is it remotely possible that the actual error has nothing to do with locks but rather with the data size? What can I do to find out or fix this? Thanks for you help! ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2006-01-24 12:14 Message: Logged In: YES user_id=413 fwiw your patch looks good. it makes sense for a DBTxn to hold a reference to its DBEnv. (I suspect there may still be problems if someone calls DBEnv.close while there are outstanding DBTxn's but doing something about that would be a lot more work if its an actual issue) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-24 11:40 Message: Logged In: YES user_id=33168 Could you pull the version of Modules/_bsddb.c out of SVN and then apply my patch? I believe your new problem was fixed recently. You can look in the Misc/NEWS file to find the exact patch. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 11:37 Message: Logged In: YES user_id=498357 Done same tests on another Debian sid machine, exact same results (up to one line number, due to my extra fprintf statement): (gdb) run test2.py Starting program: /usr/bin/python2.4-dbg test2.py [Thread debugging using libthread_db enabled] [New Thread -1210390848 (LWP 5865)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210390848 (LWP 5865)] 0xb7b01eb4 in DB_associate (self=0xb7d63df0, args=0xb7d67234, kwargs=0xb7d5ee94) at /home/shura/src/python2.4-2.4.2/Modules/_bsddb.c:1218 1218 Py_DECREF(self->associateCallback); (gdb) ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 11:31 Message: Logged In: YES user_id=498357 OK, built and installed all kinds of python packages with the patch. All tests are fine. Here goes: 1. Your testcase goes just fine, no segfault with the patched version. 2. Mine still segfaults. 3. I ran mine under gdb with python2.4-dbg package, here's the output (printed "shurafine" is my addition, to make sure that the correct code is being run): $ gdb python2.4-dbg GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) run test2.py Starting program: /usr/bin/python2.4-dbg test2.py [Thread debugging using libthread_db enabled] [New Thread -1210038592 (LWP 29629)] shurafine Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210038592 (LWP 29629)] 0xb7b57f3e in DB_associate (self=0xb7db9f58, args=0xb7dbd3b4, kwargs=0xb7db5e94) at /home/shura/src/python2.4-2.4.2/Modules/_bsddb.c:1219 1219 Py_DECREF(self->associateCallback); (gdb) Please let me know if I can be of further assistance. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 10:50 Message: Logged In: YES user_id=498357 Thanks for a quick response! OK, first thing first: your simpler testcase seems to expose yet another problem, not the one I had. In particular, your testcase segfaults for me on python2.4.2/bsddb4.3.0 but *does not* segfault with python2.3.5/bsddb4.2.0.5 In my testcase, I can definitely blame the segfault on the associate call, not on open. I can demonstrate it by either commenting out the associate call (no segfault) or by inserting a print statement right before the associate. So your testcase does not seem to have an exact same problem than my testcase. In my testcase nothing seems to depend on variable names (as one would expect). I am rebuilding python2.4 with your patch, will post results soon. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-23 23:03 Message: Logged In: YES user_id=33168 I spoke too soon. The attached patch works for me or your original test case and my pared down version. It also passes the tests. It also fixes a potential memory leak. Let me know if this works for you. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-23 22:45 Message: Logged In: YES user_id=33168 I've got a much simpler test case. The problem seems to be triggered when the txn is deleted after the env (in Modules/_bsddb.c 917 vs 966). If I change the variable names in python, I don't get the same behaviour (ie, it doesn't crash). I removed the original data file, but if you change the_txn to txn, that might "fix" the problem. If not, try playing with different variable names and see if you can get it to not crash. Obviously there needs to be a real fix in C code, but I'm not sure what needs to happen. It doesn't look like we keep enough info to do this properly. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-23 12:41 Message: Logged In: YES user_id=498357 Attaching test3.py containing same code without transactions. Works fine with either pm.db or pm_ok.db ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 From noreply at sourceforge.net Wed Jan 25 00:34:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 15:34:29 -0800 Subject: [ python-Bugs-1295808 ] expat symbols should be namespaced in pyexpat Message-ID: Bugs item #1295808, was opened at 2005-09-19 21:44 Message generated for change (Comment added) made by tmick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295808&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Trent Mick (tmick) Assigned to: Martin v. L??wis (loewis) Summary: expat symbols should be namespaced in pyexpat Initial Comment: The Problem: - you embed Python in some app - the app dynamically loads libexpat of version X - the embedded Python imports pyexpat (which was built against libexpat version X+n) --> pyexpat gets the expat symbols from the already loaded and *older* libexpat: crash (Specifically the crash we observed was in getting an old XML_ErrorString (from xmlparse.c) and then calling it with newer values in the XML_Error enum: // pyexpat.c, line 1970 ... // Added in Expat 1.95.7. MYCONST(XML_ERROR_UNBOUND_PREFIX); ... The Solution: Prefix all a exported symbols with "PyExpat_". This is similar to what Mozilla does for some common libs: http://lxr.mozilla.org/seamonkey/source/modules/libimg/png/mozpngconf.h#115 I'll attach the gdb backtrace that we were getting and a patch. ---------------------------------------------------------------------- >Comment By: Trent Mick (tmick) Date: 2006-01-24 23:34 Message: Logged In: YES user_id=34892 > This seems to be a duplicate of bug #1075984. You are right. > Trent, is this patch sufficient to meet your embedding > needs so that nothing else needs to be done? Yes. > I do not think this patch can be applied to 2.4. That's fine. Getting this into Python >=2.5 would be good enough. Martin, Have you had a chance to review this? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-30 06:01 Message: Logged In: YES user_id=33168 This seems to be a duplicate of bug #1075984. I like this patch better, but perhaps both patches (the one here and the other bug report) should be implemented? I think Martin helps maintain pyexpat. Maybe he has some ideas about either or both of these bugs/patches. Martin, do you think these are safe to apply? I can apply the patch(es) if you think it's safe. Trent, is this patch sufficient to meet your embedding needs so that nothing else needs to be done? I do not think this patch can be applied to 2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295808&group_id=5470 From noreply at sourceforge.net Wed Jan 25 01:35:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 16:35:48 -0800 Subject: [ python-Bugs-1413192 ] bsddb: segfault on db.associate call with Txn and large data Message-ID: Bugs item #1413192, was opened at 2006-01-23 12:35 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Roitman (rshura) Assigned to: Neal Norwitz (nnorwitz) Summary: bsddb: segfault on db.associate call with Txn and large data Initial Comment: Problem confirmed on Python2.3.5/bsddb4.2.0.5 and Python2.4.2/bsddb4.3.0 on Debian sid and Ubuntu Breezy. It appears, that the associate call, necessary to create a secondary index, segfaults when: 1. There is a large amount of data 2. Environment is transactional. The http://www.gramps-project.org/files/bsddb/testcase.tar.gz contains the example code and two databases, pm.db and pm_ok.db -- both have the same number of keys and each data item is a pickled tuple with two elements. The second index is created over the unpickled data[1]. The pm.db segfaults and the pm_ok.db does not. The second db has much smaller data items in data[0]. If the environment is set up and opened without TXN then pm.db is also fine. Seems like a problem in associate call in a TXN environment, that is only seen with large enough data. Please let me know if I can be of further assistance. This is a show-stopper issue for me, I would go out of my way to help resolving this or finding a work-around. Thanks! Alex P.S. I could not attach the large file, probably due to the size limit on the upload, hence a link to the testcase. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2006-01-24 16:35 Message: Logged In: YES user_id=413 BerkeleyDB uses page locking so it makes sense that a database with larger data objects in it would require more locks assuming it is internally locking each page. That kind of tuning gets into BerkeleyDB internals where i suspect people on the comp.databases.berkeleydb newsgroup could answer things better. glad its working for you now. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 13:12 Message: Logged In: YES user_id=498357 Tried increasing locks, lockers, and locked objects to 10000 each and seems to help. So I guess the number of locks is data-size specific. I guess this is indeed a lock issue, so it's my problem now and not yours :-) Thanks for your help! ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 12:50 Message: Logged In: YES user_id=498357 With the SVN version of _bsddb.c I no longer have segfault with my test. Instead I have the following exception: Traceback (most recent call last): File "test2.py", line 37, in ? person_map.associate(surnames,find_surname,db.DB_CREATE,txn=the_txn) MemoryError: (12, 'Cannot allocate memory -- Lock table is out of available locks') Now, please bear with me here if you can. It's easy to shrug it off saying that I simply don't have enough locks for this huge txn. But the exact same code works fine with the pm_ok.db file from my testcase, and that file has exact same number of elements and exact same structure of both the data and the secondary index computation. So one would think that it needs exact same number of locks, and yet it works while pm.db does not. The only difference between the two data files is that in each data item, data[0] is much larger in pm.db and smaller in pm_ok.db Is it remotely possible that the actual error has nothing to do with locks but rather with the data size? What can I do to find out or fix this? Thanks for you help! ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2006-01-24 12:14 Message: Logged In: YES user_id=413 fwiw your patch looks good. it makes sense for a DBTxn to hold a reference to its DBEnv. (I suspect there may still be problems if someone calls DBEnv.close while there are outstanding DBTxn's but doing something about that would be a lot more work if its an actual issue) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-24 11:40 Message: Logged In: YES user_id=33168 Could you pull the version of Modules/_bsddb.c out of SVN and then apply my patch? I believe your new problem was fixed recently. You can look in the Misc/NEWS file to find the exact patch. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 11:37 Message: Logged In: YES user_id=498357 Done same tests on another Debian sid machine, exact same results (up to one line number, due to my extra fprintf statement): (gdb) run test2.py Starting program: /usr/bin/python2.4-dbg test2.py [Thread debugging using libthread_db enabled] [New Thread -1210390848 (LWP 5865)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210390848 (LWP 5865)] 0xb7b01eb4 in DB_associate (self=0xb7d63df0, args=0xb7d67234, kwargs=0xb7d5ee94) at /home/shura/src/python2.4-2.4.2/Modules/_bsddb.c:1218 1218 Py_DECREF(self->associateCallback); (gdb) ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 11:31 Message: Logged In: YES user_id=498357 OK, built and installed all kinds of python packages with the patch. All tests are fine. Here goes: 1. Your testcase goes just fine, no segfault with the patched version. 2. Mine still segfaults. 3. I ran mine under gdb with python2.4-dbg package, here's the output (printed "shurafine" is my addition, to make sure that the correct code is being run): $ gdb python2.4-dbg GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) run test2.py Starting program: /usr/bin/python2.4-dbg test2.py [Thread debugging using libthread_db enabled] [New Thread -1210038592 (LWP 29629)] shurafine Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210038592 (LWP 29629)] 0xb7b57f3e in DB_associate (self=0xb7db9f58, args=0xb7dbd3b4, kwargs=0xb7db5e94) at /home/shura/src/python2.4-2.4.2/Modules/_bsddb.c:1219 1219 Py_DECREF(self->associateCallback); (gdb) Please let me know if I can be of further assistance. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 10:50 Message: Logged In: YES user_id=498357 Thanks for a quick response! OK, first thing first: your simpler testcase seems to expose yet another problem, not the one I had. In particular, your testcase segfaults for me on python2.4.2/bsddb4.3.0 but *does not* segfault with python2.3.5/bsddb4.2.0.5 In my testcase, I can definitely blame the segfault on the associate call, not on open. I can demonstrate it by either commenting out the associate call (no segfault) or by inserting a print statement right before the associate. So your testcase does not seem to have an exact same problem than my testcase. In my testcase nothing seems to depend on variable names (as one would expect). I am rebuilding python2.4 with your patch, will post results soon. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-23 23:03 Message: Logged In: YES user_id=33168 I spoke too soon. The attached patch works for me or your original test case and my pared down version. It also passes the tests. It also fixes a potential memory leak. Let me know if this works for you. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-23 22:45 Message: Logged In: YES user_id=33168 I've got a much simpler test case. The problem seems to be triggered when the txn is deleted after the env (in Modules/_bsddb.c 917 vs 966). If I change the variable names in python, I don't get the same behaviour (ie, it doesn't crash). I removed the original data file, but if you change the_txn to txn, that might "fix" the problem. If not, try playing with different variable names and see if you can get it to not crash. Obviously there needs to be a real fix in C code, but I'm not sure what needs to happen. It doesn't look like we keep enough info to do this properly. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-23 12:41 Message: Logged In: YES user_id=498357 Attaching test3.py containing same code without transactions. Works fine with either pm.db or pm_ok.db ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 From noreply at sourceforge.net Wed Jan 25 03:21:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 18:21:18 -0800 Subject: [ python-Bugs-1413192 ] bsddb: segfault on db.associate call with Txn and large data Message-ID: Bugs item #1413192, was opened at 2006-01-23 12:35 Message generated for change (Comment added) made by rshura You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Roitman (rshura) Assigned to: Neal Norwitz (nnorwitz) Summary: bsddb: segfault on db.associate call with Txn and large data Initial Comment: Problem confirmed on Python2.3.5/bsddb4.2.0.5 and Python2.4.2/bsddb4.3.0 on Debian sid and Ubuntu Breezy. It appears, that the associate call, necessary to create a secondary index, segfaults when: 1. There is a large amount of data 2. Environment is transactional. The http://www.gramps-project.org/files/bsddb/testcase.tar.gz contains the example code and two databases, pm.db and pm_ok.db -- both have the same number of keys and each data item is a pickled tuple with two elements. The second index is created over the unpickled data[1]. The pm.db segfaults and the pm_ok.db does not. The second db has much smaller data items in data[0]. If the environment is set up and opened without TXN then pm.db is also fine. Seems like a problem in associate call in a TXN environment, that is only seen with large enough data. Please let me know if I can be of further assistance. This is a show-stopper issue for me, I would go out of my way to help resolving this or finding a work-around. Thanks! Alex P.S. I could not attach the large file, probably due to the size limit on the upload, hence a link to the testcase. ---------------------------------------------------------------------- >Comment By: Alex Roitman (rshura) Date: 2006-01-24 18:21 Message: Logged In: YES user_id=498357 While you guys are here, can I ask you if there's a way to return to the checkpoint made in a Txn-aware database? Specifically, is there a way to return to the latest checkpoing from within python? My problem is that if my data import fails in the middle, I want to undo some transactions that were committed, to have a clean import undo. Checkpoint seems like a nice way to do that, if only I could get back to it :-) ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2006-01-24 16:35 Message: Logged In: YES user_id=413 BerkeleyDB uses page locking so it makes sense that a database with larger data objects in it would require more locks assuming it is internally locking each page. That kind of tuning gets into BerkeleyDB internals where i suspect people on the comp.databases.berkeleydb newsgroup could answer things better. glad its working for you now. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 13:12 Message: Logged In: YES user_id=498357 Tried increasing locks, lockers, and locked objects to 10000 each and seems to help. So I guess the number of locks is data-size specific. I guess this is indeed a lock issue, so it's my problem now and not yours :-) Thanks for your help! ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 12:50 Message: Logged In: YES user_id=498357 With the SVN version of _bsddb.c I no longer have segfault with my test. Instead I have the following exception: Traceback (most recent call last): File "test2.py", line 37, in ? person_map.associate(surnames,find_surname,db.DB_CREATE,txn=the_txn) MemoryError: (12, 'Cannot allocate memory -- Lock table is out of available locks') Now, please bear with me here if you can. It's easy to shrug it off saying that I simply don't have enough locks for this huge txn. But the exact same code works fine with the pm_ok.db file from my testcase, and that file has exact same number of elements and exact same structure of both the data and the secondary index computation. So one would think that it needs exact same number of locks, and yet it works while pm.db does not. The only difference between the two data files is that in each data item, data[0] is much larger in pm.db and smaller in pm_ok.db Is it remotely possible that the actual error has nothing to do with locks but rather with the data size? What can I do to find out or fix this? Thanks for you help! ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2006-01-24 12:14 Message: Logged In: YES user_id=413 fwiw your patch looks good. it makes sense for a DBTxn to hold a reference to its DBEnv. (I suspect there may still be problems if someone calls DBEnv.close while there are outstanding DBTxn's but doing something about that would be a lot more work if its an actual issue) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-24 11:40 Message: Logged In: YES user_id=33168 Could you pull the version of Modules/_bsddb.c out of SVN and then apply my patch? I believe your new problem was fixed recently. You can look in the Misc/NEWS file to find the exact patch. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 11:37 Message: Logged In: YES user_id=498357 Done same tests on another Debian sid machine, exact same results (up to one line number, due to my extra fprintf statement): (gdb) run test2.py Starting program: /usr/bin/python2.4-dbg test2.py [Thread debugging using libthread_db enabled] [New Thread -1210390848 (LWP 5865)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210390848 (LWP 5865)] 0xb7b01eb4 in DB_associate (self=0xb7d63df0, args=0xb7d67234, kwargs=0xb7d5ee94) at /home/shura/src/python2.4-2.4.2/Modules/_bsddb.c:1218 1218 Py_DECREF(self->associateCallback); (gdb) ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 11:31 Message: Logged In: YES user_id=498357 OK, built and installed all kinds of python packages with the patch. All tests are fine. Here goes: 1. Your testcase goes just fine, no segfault with the patched version. 2. Mine still segfaults. 3. I ran mine under gdb with python2.4-dbg package, here's the output (printed "shurafine" is my addition, to make sure that the correct code is being run): $ gdb python2.4-dbg GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) run test2.py Starting program: /usr/bin/python2.4-dbg test2.py [Thread debugging using libthread_db enabled] [New Thread -1210038592 (LWP 29629)] shurafine Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210038592 (LWP 29629)] 0xb7b57f3e in DB_associate (self=0xb7db9f58, args=0xb7dbd3b4, kwargs=0xb7db5e94) at /home/shura/src/python2.4-2.4.2/Modules/_bsddb.c:1219 1219 Py_DECREF(self->associateCallback); (gdb) Please let me know if I can be of further assistance. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 10:50 Message: Logged In: YES user_id=498357 Thanks for a quick response! OK, first thing first: your simpler testcase seems to expose yet another problem, not the one I had. In particular, your testcase segfaults for me on python2.4.2/bsddb4.3.0 but *does not* segfault with python2.3.5/bsddb4.2.0.5 In my testcase, I can definitely blame the segfault on the associate call, not on open. I can demonstrate it by either commenting out the associate call (no segfault) or by inserting a print statement right before the associate. So your testcase does not seem to have an exact same problem than my testcase. In my testcase nothing seems to depend on variable names (as one would expect). I am rebuilding python2.4 with your patch, will post results soon. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-23 23:03 Message: Logged In: YES user_id=33168 I spoke too soon. The attached patch works for me or your original test case and my pared down version. It also passes the tests. It also fixes a potential memory leak. Let me know if this works for you. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-23 22:45 Message: Logged In: YES user_id=33168 I've got a much simpler test case. The problem seems to be triggered when the txn is deleted after the env (in Modules/_bsddb.c 917 vs 966). If I change the variable names in python, I don't get the same behaviour (ie, it doesn't crash). I removed the original data file, but if you change the_txn to txn, that might "fix" the problem. If not, try playing with different variable names and see if you can get it to not crash. Obviously there needs to be a real fix in C code, but I'm not sure what needs to happen. It doesn't look like we keep enough info to do this properly. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-23 12:41 Message: Logged In: YES user_id=498357 Attaching test3.py containing same code without transactions. Works fine with either pm.db or pm_ok.db ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 From noreply at sourceforge.net Wed Jan 25 06:23:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 21:23:19 -0800 Subject: [ python-Bugs-1413192 ] bsddb: segfault on db.associate call with Txn and large data Message-ID: Bugs item #1413192, was opened at 2006-01-23 12:35 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Roitman (rshura) Assigned to: Neal Norwitz (nnorwitz) Summary: bsddb: segfault on db.associate call with Txn and large data Initial Comment: Problem confirmed on Python2.3.5/bsddb4.2.0.5 and Python2.4.2/bsddb4.3.0 on Debian sid and Ubuntu Breezy. It appears, that the associate call, necessary to create a secondary index, segfaults when: 1. There is a large amount of data 2. Environment is transactional. The http://www.gramps-project.org/files/bsddb/testcase.tar.gz contains the example code and two databases, pm.db and pm_ok.db -- both have the same number of keys and each data item is a pickled tuple with two elements. The second index is created over the unpickled data[1]. The pm.db segfaults and the pm_ok.db does not. The second db has much smaller data items in data[0]. If the environment is set up and opened without TXN then pm.db is also fine. Seems like a problem in associate call in a TXN environment, that is only seen with large enough data. Please let me know if I can be of further assistance. This is a show-stopper issue for me, I would go out of my way to help resolving this or finding a work-around. Thanks! Alex P.S. I could not attach the large file, probably due to the size limit on the upload, hence a link to the testcase. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-24 21:23 Message: Logged In: YES user_id=33168 I'm sorry I'm not a Berkeley DB developer, I just play one on TV. :-) Seriously, I don't know anything about BDB. I was just trying to get it stable. Maybe Greg can answer your question. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 18:21 Message: Logged In: YES user_id=498357 While you guys are here, can I ask you if there's a way to return to the checkpoint made in a Txn-aware database? Specifically, is there a way to return to the latest checkpoing from within python? My problem is that if my data import fails in the middle, I want to undo some transactions that were committed, to have a clean import undo. Checkpoint seems like a nice way to do that, if only I could get back to it :-) ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2006-01-24 16:35 Message: Logged In: YES user_id=413 BerkeleyDB uses page locking so it makes sense that a database with larger data objects in it would require more locks assuming it is internally locking each page. That kind of tuning gets into BerkeleyDB internals where i suspect people on the comp.databases.berkeleydb newsgroup could answer things better. glad its working for you now. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 13:12 Message: Logged In: YES user_id=498357 Tried increasing locks, lockers, and locked objects to 10000 each and seems to help. So I guess the number of locks is data-size specific. I guess this is indeed a lock issue, so it's my problem now and not yours :-) Thanks for your help! ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 12:50 Message: Logged In: YES user_id=498357 With the SVN version of _bsddb.c I no longer have segfault with my test. Instead I have the following exception: Traceback (most recent call last): File "test2.py", line 37, in ? person_map.associate(surnames,find_surname,db.DB_CREATE,txn=the_txn) MemoryError: (12, 'Cannot allocate memory -- Lock table is out of available locks') Now, please bear with me here if you can. It's easy to shrug it off saying that I simply don't have enough locks for this huge txn. But the exact same code works fine with the pm_ok.db file from my testcase, and that file has exact same number of elements and exact same structure of both the data and the secondary index computation. So one would think that it needs exact same number of locks, and yet it works while pm.db does not. The only difference between the two data files is that in each data item, data[0] is much larger in pm.db and smaller in pm_ok.db Is it remotely possible that the actual error has nothing to do with locks but rather with the data size? What can I do to find out or fix this? Thanks for you help! ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2006-01-24 12:14 Message: Logged In: YES user_id=413 fwiw your patch looks good. it makes sense for a DBTxn to hold a reference to its DBEnv. (I suspect there may still be problems if someone calls DBEnv.close while there are outstanding DBTxn's but doing something about that would be a lot more work if its an actual issue) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-24 11:40 Message: Logged In: YES user_id=33168 Could you pull the version of Modules/_bsddb.c out of SVN and then apply my patch? I believe your new problem was fixed recently. You can look in the Misc/NEWS file to find the exact patch. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 11:37 Message: Logged In: YES user_id=498357 Done same tests on another Debian sid machine, exact same results (up to one line number, due to my extra fprintf statement): (gdb) run test2.py Starting program: /usr/bin/python2.4-dbg test2.py [Thread debugging using libthread_db enabled] [New Thread -1210390848 (LWP 5865)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210390848 (LWP 5865)] 0xb7b01eb4 in DB_associate (self=0xb7d63df0, args=0xb7d67234, kwargs=0xb7d5ee94) at /home/shura/src/python2.4-2.4.2/Modules/_bsddb.c:1218 1218 Py_DECREF(self->associateCallback); (gdb) ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 11:31 Message: Logged In: YES user_id=498357 OK, built and installed all kinds of python packages with the patch. All tests are fine. Here goes: 1. Your testcase goes just fine, no segfault with the patched version. 2. Mine still segfaults. 3. I ran mine under gdb with python2.4-dbg package, here's the output (printed "shurafine" is my addition, to make sure that the correct code is being run): $ gdb python2.4-dbg GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) run test2.py Starting program: /usr/bin/python2.4-dbg test2.py [Thread debugging using libthread_db enabled] [New Thread -1210038592 (LWP 29629)] shurafine Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210038592 (LWP 29629)] 0xb7b57f3e in DB_associate (self=0xb7db9f58, args=0xb7dbd3b4, kwargs=0xb7db5e94) at /home/shura/src/python2.4-2.4.2/Modules/_bsddb.c:1219 1219 Py_DECREF(self->associateCallback); (gdb) Please let me know if I can be of further assistance. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 10:50 Message: Logged In: YES user_id=498357 Thanks for a quick response! OK, first thing first: your simpler testcase seems to expose yet another problem, not the one I had. In particular, your testcase segfaults for me on python2.4.2/bsddb4.3.0 but *does not* segfault with python2.3.5/bsddb4.2.0.5 In my testcase, I can definitely blame the segfault on the associate call, not on open. I can demonstrate it by either commenting out the associate call (no segfault) or by inserting a print statement right before the associate. So your testcase does not seem to have an exact same problem than my testcase. In my testcase nothing seems to depend on variable names (as one would expect). I am rebuilding python2.4 with your patch, will post results soon. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-23 23:03 Message: Logged In: YES user_id=33168 I spoke too soon. The attached patch works for me or your original test case and my pared down version. It also passes the tests. It also fixes a potential memory leak. Let me know if this works for you. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-23 22:45 Message: Logged In: YES user_id=33168 I've got a much simpler test case. The problem seems to be triggered when the txn is deleted after the env (in Modules/_bsddb.c 917 vs 966). If I change the variable names in python, I don't get the same behaviour (ie, it doesn't crash). I removed the original data file, but if you change the_txn to txn, that might "fix" the problem. If not, try playing with different variable names and see if you can get it to not crash. Obviously there needs to be a real fix in C code, but I'm not sure what needs to happen. It doesn't look like we keep enough info to do this properly. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-23 12:41 Message: Logged In: YES user_id=498357 Attaching test3.py containing same code without transactions. Works fine with either pm.db or pm_ok.db ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 From noreply at sourceforge.net Wed Jan 25 06:29:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 21:29:43 -0800 Subject: [ python-Bugs-1413192 ] bsddb: segfault on db.associate call with Txn and large data Message-ID: Bugs item #1413192, was opened at 2006-01-23 12:35 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: Alex Roitman (rshura) Assigned to: Neal Norwitz (nnorwitz) Summary: bsddb: segfault on db.associate call with Txn and large data Initial Comment: Problem confirmed on Python2.3.5/bsddb4.2.0.5 and Python2.4.2/bsddb4.3.0 on Debian sid and Ubuntu Breezy. It appears, that the associate call, necessary to create a secondary index, segfaults when: 1. There is a large amount of data 2. Environment is transactional. The http://www.gramps-project.org/files/bsddb/testcase.tar.gz contains the example code and two databases, pm.db and pm_ok.db -- both have the same number of keys and each data item is a pickled tuple with two elements. The second index is created over the unpickled data[1]. The pm.db segfaults and the pm_ok.db does not. The second db has much smaller data items in data[0]. If the environment is set up and opened without TXN then pm.db is also fine. Seems like a problem in associate call in a TXN environment, that is only seen with large enough data. Please let me know if I can be of further assistance. This is a show-stopper issue for me, I would go out of my way to help resolving this or finding a work-around. Thanks! Alex P.S. I could not attach the large file, probably due to the size limit on the upload, hence a link to the testcase. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-24 21:29 Message: Logged In: YES user_id=33168 Committed revision 42177. Committed revision 42178. (2.4) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-24 21:23 Message: Logged In: YES user_id=33168 I'm sorry I'm not a Berkeley DB developer, I just play one on TV. :-) Seriously, I don't know anything about BDB. I was just trying to get it stable. Maybe Greg can answer your question. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 18:21 Message: Logged In: YES user_id=498357 While you guys are here, can I ask you if there's a way to return to the checkpoint made in a Txn-aware database? Specifically, is there a way to return to the latest checkpoing from within python? My problem is that if my data import fails in the middle, I want to undo some transactions that were committed, to have a clean import undo. Checkpoint seems like a nice way to do that, if only I could get back to it :-) ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2006-01-24 16:35 Message: Logged In: YES user_id=413 BerkeleyDB uses page locking so it makes sense that a database with larger data objects in it would require more locks assuming it is internally locking each page. That kind of tuning gets into BerkeleyDB internals where i suspect people on the comp.databases.berkeleydb newsgroup could answer things better. glad its working for you now. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 13:12 Message: Logged In: YES user_id=498357 Tried increasing locks, lockers, and locked objects to 10000 each and seems to help. So I guess the number of locks is data-size specific. I guess this is indeed a lock issue, so it's my problem now and not yours :-) Thanks for your help! ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 12:50 Message: Logged In: YES user_id=498357 With the SVN version of _bsddb.c I no longer have segfault with my test. Instead I have the following exception: Traceback (most recent call last): File "test2.py", line 37, in ? person_map.associate(surnames,find_surname,db.DB_CREATE,txn=the_txn) MemoryError: (12, 'Cannot allocate memory -- Lock table is out of available locks') Now, please bear with me here if you can. It's easy to shrug it off saying that I simply don't have enough locks for this huge txn. But the exact same code works fine with the pm_ok.db file from my testcase, and that file has exact same number of elements and exact same structure of both the data and the secondary index computation. So one would think that it needs exact same number of locks, and yet it works while pm.db does not. The only difference between the two data files is that in each data item, data[0] is much larger in pm.db and smaller in pm_ok.db Is it remotely possible that the actual error has nothing to do with locks but rather with the data size? What can I do to find out or fix this? Thanks for you help! ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2006-01-24 12:14 Message: Logged In: YES user_id=413 fwiw your patch looks good. it makes sense for a DBTxn to hold a reference to its DBEnv. (I suspect there may still be problems if someone calls DBEnv.close while there are outstanding DBTxn's but doing something about that would be a lot more work if its an actual issue) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-24 11:40 Message: Logged In: YES user_id=33168 Could you pull the version of Modules/_bsddb.c out of SVN and then apply my patch? I believe your new problem was fixed recently. You can look in the Misc/NEWS file to find the exact patch. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 11:37 Message: Logged In: YES user_id=498357 Done same tests on another Debian sid machine, exact same results (up to one line number, due to my extra fprintf statement): (gdb) run test2.py Starting program: /usr/bin/python2.4-dbg test2.py [Thread debugging using libthread_db enabled] [New Thread -1210390848 (LWP 5865)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210390848 (LWP 5865)] 0xb7b01eb4 in DB_associate (self=0xb7d63df0, args=0xb7d67234, kwargs=0xb7d5ee94) at /home/shura/src/python2.4-2.4.2/Modules/_bsddb.c:1218 1218 Py_DECREF(self->associateCallback); (gdb) ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 11:31 Message: Logged In: YES user_id=498357 OK, built and installed all kinds of python packages with the patch. All tests are fine. Here goes: 1. Your testcase goes just fine, no segfault with the patched version. 2. Mine still segfaults. 3. I ran mine under gdb with python2.4-dbg package, here's the output (printed "shurafine" is my addition, to make sure that the correct code is being run): $ gdb python2.4-dbg GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) run test2.py Starting program: /usr/bin/python2.4-dbg test2.py [Thread debugging using libthread_db enabled] [New Thread -1210038592 (LWP 29629)] shurafine Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210038592 (LWP 29629)] 0xb7b57f3e in DB_associate (self=0xb7db9f58, args=0xb7dbd3b4, kwargs=0xb7db5e94) at /home/shura/src/python2.4-2.4.2/Modules/_bsddb.c:1219 1219 Py_DECREF(self->associateCallback); (gdb) Please let me know if I can be of further assistance. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 10:50 Message: Logged In: YES user_id=498357 Thanks for a quick response! OK, first thing first: your simpler testcase seems to expose yet another problem, not the one I had. In particular, your testcase segfaults for me on python2.4.2/bsddb4.3.0 but *does not* segfault with python2.3.5/bsddb4.2.0.5 In my testcase, I can definitely blame the segfault on the associate call, not on open. I can demonstrate it by either commenting out the associate call (no segfault) or by inserting a print statement right before the associate. So your testcase does not seem to have an exact same problem than my testcase. In my testcase nothing seems to depend on variable names (as one would expect). I am rebuilding python2.4 with your patch, will post results soon. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-23 23:03 Message: Logged In: YES user_id=33168 I spoke too soon. The attached patch works for me or your original test case and my pared down version. It also passes the tests. It also fixes a potential memory leak. Let me know if this works for you. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-23 22:45 Message: Logged In: YES user_id=33168 I've got a much simpler test case. The problem seems to be triggered when the txn is deleted after the env (in Modules/_bsddb.c 917 vs 966). If I change the variable names in python, I don't get the same behaviour (ie, it doesn't crash). I removed the original data file, but if you change the_txn to txn, that might "fix" the problem. If not, try playing with different variable names and see if you can get it to not crash. Obviously there needs to be a real fix in C code, but I'm not sure what needs to happen. It doesn't look like we keep enough info to do this properly. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-23 12:41 Message: Logged In: YES user_id=498357 Attaching test3.py containing same code without transactions. Works fine with either pm.db or pm_ok.db ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 From noreply at sourceforge.net Wed Jan 25 06:31:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 21:31:24 -0800 Subject: [ python-Bugs-1413192 ] bsddb: segfault on db.associate call with Txn and large data Message-ID: Bugs item #1413192, was opened at 2006-01-23 12:35 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: Alex Roitman (rshura) Assigned to: Neal Norwitz (nnorwitz) Summary: bsddb: segfault on db.associate call with Txn and large data Initial Comment: Problem confirmed on Python2.3.5/bsddb4.2.0.5 and Python2.4.2/bsddb4.3.0 on Debian sid and Ubuntu Breezy. It appears, that the associate call, necessary to create a secondary index, segfaults when: 1. There is a large amount of data 2. Environment is transactional. The http://www.gramps-project.org/files/bsddb/testcase.tar.gz contains the example code and two databases, pm.db and pm_ok.db -- both have the same number of keys and each data item is a pickled tuple with two elements. The second index is created over the unpickled data[1]. The pm.db segfaults and the pm_ok.db does not. The second db has much smaller data items in data[0]. If the environment is set up and opened without TXN then pm.db is also fine. Seems like a problem in associate call in a TXN environment, that is only seen with large enough data. Please let me know if I can be of further assistance. This is a show-stopper issue for me, I would go out of my way to help resolving this or finding a work-around. Thanks! Alex P.S. I could not attach the large file, probably due to the size limit on the upload, hence a link to the testcase. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-24 21:31 Message: Logged In: YES user_id=33168 Oh, I forgot to say thanks for the good bug report and responding back. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-24 21:29 Message: Logged In: YES user_id=33168 Committed revision 42177. Committed revision 42178. (2.4) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-24 21:23 Message: Logged In: YES user_id=33168 I'm sorry I'm not a Berkeley DB developer, I just play one on TV. :-) Seriously, I don't know anything about BDB. I was just trying to get it stable. Maybe Greg can answer your question. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 18:21 Message: Logged In: YES user_id=498357 While you guys are here, can I ask you if there's a way to return to the checkpoint made in a Txn-aware database? Specifically, is there a way to return to the latest checkpoing from within python? My problem is that if my data import fails in the middle, I want to undo some transactions that were committed, to have a clean import undo. Checkpoint seems like a nice way to do that, if only I could get back to it :-) ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2006-01-24 16:35 Message: Logged In: YES user_id=413 BerkeleyDB uses page locking so it makes sense that a database with larger data objects in it would require more locks assuming it is internally locking each page. That kind of tuning gets into BerkeleyDB internals where i suspect people on the comp.databases.berkeleydb newsgroup could answer things better. glad its working for you now. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 13:12 Message: Logged In: YES user_id=498357 Tried increasing locks, lockers, and locked objects to 10000 each and seems to help. So I guess the number of locks is data-size specific. I guess this is indeed a lock issue, so it's my problem now and not yours :-) Thanks for your help! ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 12:50 Message: Logged In: YES user_id=498357 With the SVN version of _bsddb.c I no longer have segfault with my test. Instead I have the following exception: Traceback (most recent call last): File "test2.py", line 37, in ? person_map.associate(surnames,find_surname,db.DB_CREATE,txn=the_txn) MemoryError: (12, 'Cannot allocate memory -- Lock table is out of available locks') Now, please bear with me here if you can. It's easy to shrug it off saying that I simply don't have enough locks for this huge txn. But the exact same code works fine with the pm_ok.db file from my testcase, and that file has exact same number of elements and exact same structure of both the data and the secondary index computation. So one would think that it needs exact same number of locks, and yet it works while pm.db does not. The only difference between the two data files is that in each data item, data[0] is much larger in pm.db and smaller in pm_ok.db Is it remotely possible that the actual error has nothing to do with locks but rather with the data size? What can I do to find out or fix this? Thanks for you help! ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2006-01-24 12:14 Message: Logged In: YES user_id=413 fwiw your patch looks good. it makes sense for a DBTxn to hold a reference to its DBEnv. (I suspect there may still be problems if someone calls DBEnv.close while there are outstanding DBTxn's but doing something about that would be a lot more work if its an actual issue) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-24 11:40 Message: Logged In: YES user_id=33168 Could you pull the version of Modules/_bsddb.c out of SVN and then apply my patch? I believe your new problem was fixed recently. You can look in the Misc/NEWS file to find the exact patch. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 11:37 Message: Logged In: YES user_id=498357 Done same tests on another Debian sid machine, exact same results (up to one line number, due to my extra fprintf statement): (gdb) run test2.py Starting program: /usr/bin/python2.4-dbg test2.py [Thread debugging using libthread_db enabled] [New Thread -1210390848 (LWP 5865)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210390848 (LWP 5865)] 0xb7b01eb4 in DB_associate (self=0xb7d63df0, args=0xb7d67234, kwargs=0xb7d5ee94) at /home/shura/src/python2.4-2.4.2/Modules/_bsddb.c:1218 1218 Py_DECREF(self->associateCallback); (gdb) ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 11:31 Message: Logged In: YES user_id=498357 OK, built and installed all kinds of python packages with the patch. All tests are fine. Here goes: 1. Your testcase goes just fine, no segfault with the patched version. 2. Mine still segfaults. 3. I ran mine under gdb with python2.4-dbg package, here's the output (printed "shurafine" is my addition, to make sure that the correct code is being run): $ gdb python2.4-dbg GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) run test2.py Starting program: /usr/bin/python2.4-dbg test2.py [Thread debugging using libthread_db enabled] [New Thread -1210038592 (LWP 29629)] shurafine Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210038592 (LWP 29629)] 0xb7b57f3e in DB_associate (self=0xb7db9f58, args=0xb7dbd3b4, kwargs=0xb7db5e94) at /home/shura/src/python2.4-2.4.2/Modules/_bsddb.c:1219 1219 Py_DECREF(self->associateCallback); (gdb) Please let me know if I can be of further assistance. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-24 10:50 Message: Logged In: YES user_id=498357 Thanks for a quick response! OK, first thing first: your simpler testcase seems to expose yet another problem, not the one I had. In particular, your testcase segfaults for me on python2.4.2/bsddb4.3.0 but *does not* segfault with python2.3.5/bsddb4.2.0.5 In my testcase, I can definitely blame the segfault on the associate call, not on open. I can demonstrate it by either commenting out the associate call (no segfault) or by inserting a print statement right before the associate. So your testcase does not seem to have an exact same problem than my testcase. In my testcase nothing seems to depend on variable names (as one would expect). I am rebuilding python2.4 with your patch, will post results soon. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-23 23:03 Message: Logged In: YES user_id=33168 I spoke too soon. The attached patch works for me or your original test case and my pared down version. It also passes the tests. It also fixes a potential memory leak. Let me know if this works for you. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-23 22:45 Message: Logged In: YES user_id=33168 I've got a much simpler test case. The problem seems to be triggered when the txn is deleted after the env (in Modules/_bsddb.c 917 vs 966). If I change the variable names in python, I don't get the same behaviour (ie, it doesn't crash). I removed the original data file, but if you change the_txn to txn, that might "fix" the problem. If not, try playing with different variable names and see if you can get it to not crash. Obviously there needs to be a real fix in C code, but I'm not sure what needs to happen. It doesn't look like we keep enough info to do this properly. ---------------------------------------------------------------------- Comment By: Alex Roitman (rshura) Date: 2006-01-23 12:41 Message: Logged In: YES user_id=498357 Attaching test3.py containing same code without transactions. Works fine with either pm.db or pm_ok.db ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413192&group_id=5470 From noreply at sourceforge.net Wed Jan 25 06:58:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 21:58:24 -0800 Subject: [ python-Bugs-1332873 ] BSD DB test failures for BSD DB 4.1 Message-ID: Bugs item #1332873, was opened at 2005-10-19 22:30 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1332873&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Gregory P. Smith (greg) Summary: BSD DB test failures for BSD DB 4.1 Initial Comment: ====================================================================== FAIL: test01_associateWithDB (bsddb.test.test_associate.AssociateHashTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 220, in test01_associateWithDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: ('99', 'unknown artist|Unnamed song|Unknown') ====================================================================== FAIL: test02_associateAfterDB (bsddb.test.test_associate.AssociateHashTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 240, in test02_associateAfterDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: ('99', 'unknown artist|Unnamed song|Unknown') ====================================================================== FAIL: test01_associateWithDB (bsddb.test.test_associate.AssociateBTreeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 220, in test01_associateWithDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: ('99', 'unknown artist|Unnamed song|Unknown') ====================================================================== FAIL: test02_associateAfterDB (bsddb.test.test_associate.AssociateBTreeTestCase)---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 240, in test02_associateAfterDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: ('99', 'unknown artist|Unnamed song|Unknown') ====================================================================== FAIL: test01_associateWithDB (bsddb.test.test_associate.AssociateRecnoTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 220, in test01_associateWithDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: (99, 'unknown artist|Unnamed song|Unknown') ====================================================================== FAIL: test02_associateAfterDB (bsddb.test.test_associate.AssociateRecnoTestCase)---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 240, in test02_associateAfterDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: (99, 'unknown artist|Unnamed song|Unknown') ====================================================================== FAIL: test01_associateWithDB (bsddb.test.test_associate.AssociateBTreeTxnTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 220, in test01_associateWithDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: ('99', 'unknown artist|Unnamed song|Unknown') ====================================================================== FAIL: test02_associateAfterDB (bsddb.test.test_associate.AssociateBTreeTxnTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 240, in test02_associateAfterDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: ('99', 'unknown artist|Unnamed song|Unknown') ====================================================================== FAIL: test13_associate_in_transaction (bsddb.test.test_associate.AssociateBTreeTxnTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 364, in test13_associate_in_transaction self.txn_finish_test(self.secDB, txn=txn) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 331, in txn_finish_test self.finish_test(sDB, txn=txn) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: ('99', 'unknown artist|Unnamed song|Unknown') ====================================================================== FAIL: test01_associateWithDB (bsddb.test.test_associate.ShelveAssociateHashTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 220, in test01_associateWithDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: ('99', '(U\x0eunknown artistU\x0cUnnamed songU\x07Unknownq\x01tq\x02.') ====================================================================== FAIL: test02_associateAfterDB (bsddb.test.test_associate.ShelveAssociateHashTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 240, in test02_associateAfterDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: ('99', '(U\x0eunknown artistU\x0cUnnamed songU\x07Unknownq\x01tq\x02.') ====================================================================== FAIL: test01_associateWithDB (bsddb.test.test_associate.ShelveAssociateBTreeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 220, in test01_associateWithDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: ('99', '(U\x0eunknown artistU\x0cUnnamed songU\x07Unknownq\x01tq\x02.') ====================================================================== FAIL: test02_associateAfterDB (bsddb.test.test_associate.ShelveAssociateBTreeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 240, in test02_associateAfterDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: ('99', '(U\x0eunknown artistU\x0cUnnamed songU\x07Unknownq\x01tq\x02.') ====================================================================== FAIL: test01_associateWithDB (bsddb.test.test_associate.ShelveAssociateRecnoTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 220, in test01_associateWithDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: (99, '(U\x0eunknown artistU\x0cUnnamed songU\x07Unknownq\x01tq\x02.') ====================================================================== FAIL: test02_associateAfterDB (bsddb.test.test_associate.ShelveAssociateRecnoTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 240, in test02_associateAfterDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: (180388626531, '(U\x0eunknown artistU\x0cUnnamed songU\x07Unknownq\x01tq\x02.') ====================================================================== FAIL: test01_associateWithDB (bsddb.test.test_associate.ThreadedAssociateHashTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 220, in test01_associateWithDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: ('99', '(U\x0eunknown artistU\x0cUnnamed songU\x07Unknownq\x01tq\x02.') ====================================================================== FAIL: test02_associateAfterDB (bsddb.test.test_associate.ThreadedAssociateHashTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 240, in test02_associateAfterDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: ('99', '(U\x0eunknown artistU\x0cUnnamed songU\x07Unknownq\x01tq\x02.') ====================================================================== FAIL: test01_associateWithDB (bsddb.test.test_associate.ThreadedAssociateBTreeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 220, in test01_associateWithDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: ('99', '(U\x0eunknown artistU\x0cUnnamed songU\x07Unknownq\x01tq\x02.') ====================================================================== FAIL: test02_associateAfterDB (bsddb.test.test_associate.ThreadedAssociateBTreeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 240, in test02_associateAfterDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: ('99', '(U\x0eunknown artistU\x0cUnnamed songU\x07Unknownq\x01tq\x02.') ====================================================================== FAIL: test01_associateWithDB (bsddb.test.test_associate.ThreadedAssociateRecnoTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 220, in test01_associateWithDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: (99, '(U\x0eunknown artistU\x0cUnnamed songU\x07Unknownq\x01tq\x02.') ====================================================================== FAIL: test02_associateAfterDB (bsddb.test.test_associate.ThreadedAssociateRecnoTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 240, in test02_associateAfterDB self.finish_test(self.secDB) File "/home/neal/build/python/dist/clean/Lib/bsddb/test/test_associate.py", line 278, in finish_test assert vals[1] == 99 or vals[1] == '99', vals AssertionError: (180388626531, '(U\x0eunknown artistU\x0cUnnamed songU\x07Unknownq\x01tq\x02.') ---------------------------------------------------------------------- ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-24 21:58 Message: Logged In: YES user_id=33168 Fixed by patch 1407992. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-04 21:45 Message: Logged In: YES user_id=33168 Some of these were a 64 bit problem and were fixed in Committed revision 41915. Committed revision 41916. These are still a problem: test01_associateWithDB (bsddb.test.test_associate.AssociateHashTestCase) ... FAIL test02_associateAfterDB (bsddb.test.test_associate.AssociateHashTestCase) ... FAIL test01_associateWithDB (bsddb.test.test_associate.AssociateBTreeTestCase) ... FAIL test02_associateAfterDB (bsddb.test.test_associate.AssociateBTreeTestCase) ... FAIL test01_associateWithDB (bsddb.test.test_associate.AssociateRecnoTestCase) ... FAIL test02_associateAfterDB (bsddb.test.test_associate.AssociateRecnoTestCase) ... FAIL test01_associateWithDB (bsddb.test.test_associate.AssociateBTreeTxnTestCase) ... FAIL test02_associateAfterDB (bsddb.test.test_associate.AssociateBTreeTxnTestCase) ... FAIL test13_associate_in_transaction (bsddb.test.test_associate.AssociateBTreeTxnTestCase) ... FAIL test01_associateWithDB (bsddb.test.test_associate.ShelveAssociateHashTestCase) ... FAIL test02_associateAfterDB (bsddb.test.test_associate.ShelveAssociateHashTestCase) ... FAIL test01_associateWithDB (bsddb.test.test_associate.ShelveAssociateBTreeTestCase) ... FAIL test02_associateAfterDB (bsddb.test.test_associate.ShelveAssociateBTreeTestCase) ... FAIL test01_associateWithDB (bsddb.test.test_associate.ShelveAssociateRecnoTestCase) ... FAIL test02_associateAfterDB (bsddb.test.test_associate.ShelveAssociateRecnoTestCase) ... FAIL test01_associateWithDB (bsddb.test.test_associate.ThreadedAssociateHashTestCase) ... FAIL test02_associateAfterDB (bsddb.test.test_associate.ThreadedAssociateHashTestCase) ... FAIL test01_associateWithDB (bsddb.test.test_associate.ThreadedAssociateBTreeTestCase) ... FAIL test02_associateAfterDB (bsddb.test.test_associate.ThreadedAssociateBTreeTestCase) ... FAIL test01_associateWithDB (bsddb.test.test_associate.ThreadedAssociateRecnoTestCase) ... FAIL test02_associateAfterDB (bsddb.test.test_associate.ThreadedAssociateRecnoTestCase) ... FAIL ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1332873&group_id=5470 From noreply at sourceforge.net Wed Jan 25 07:05:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 22:05:59 -0800 Subject: [ python-Bugs-788526 ] Closing dbenv first bsddb doesn't release locks & segfau Message-ID: Bugs item #788526, was opened at 2003-08-13 22:13 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788526&group_id=5470 Please note that this message will contain 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: Works For Me Priority: 5 Submitted By: Jane Austine (janeaustine50) Assigned to: Gregory P. Smith (greg) Summary: Closing dbenv first bsddb doesn't release locks & segfau Initial Comment: There is a test code named test_env_close in bsddb/test, but it doesn't test the case thoroughly. There seems to be a bug in closing the db environment first -- the lock is not released, and sometimes it seg-faults. Following is the code that shows this bug. <code> import os from bsddb import db dir,dbname='test_dbenv','test_db' def getDbEnv(dir): try: os.mkdir(dir) except: pass dbenv = db.DBEnv() dbenv.open(dir, db.DB_INIT_CDB| db.DB_CREATE |db.DB_INIT_MPOOL) return dbenv def getDbHandler(db_env,db_name): d = db.DB(dbenv) d.open(db_name, db.DB_BTREE, db.DB_CREATE) return d dbenv=getDbEnv(dir) assert dbenv.lock_stat()['nlocks']==0 d=getDbHandler(dbenv,dbname) assert dbenv.lock_stat()['nlocks']==1 try: dbenv.close() except db.DBError: pass else: assert 0 del d import gc gc.collect() dbenv=getDbEnv(dir) assert dbenv.lock_stat()['nlocks']==0,'number of current locks should be 0' #this fails </code> If you close dbenv before db handler, the lock is not released. Moreover, try this with dbshelve and it segfaults. <code> >>> from bsddb import dbshelve >>> dbenv2=getDbEnv('test_dbenv2') >>> d2=dbshelve.open(dbname,dbenv=dbenv2) >>> try: ... dbenv2.close() ... except db.DBError: ... pass ... else: ... assert 0 ... >>> >>> Exception bsddb._db.DBError: (0, 'DBEnv object has been closed') in Segmentation fault </code> Tested on: 1. linux with Python 2.3 final, Berkeley DB 4.1.25 2. windows xp with Python 2.3 final (with _bsddb that comes along) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-24 22:05 Message: Logged In: YES user_id=33168 Assuming this was fixed by the patch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-24 00:04 Message: Logged In: YES user_id=33168 Jane could try the patch in bug 1413192 to see if it fixes your problem? ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2004-06-16 15:18 Message: Logged In: YES user_id=413 Yes this bug is still there. A "workaround" is just a "don't do that" when it comes to closing sleepycat DBEnv objects while there are things using them still open. I believe we can prevent this... One proposal: internally in _bsddb.c DBEnv could be made to keep a weak reference to all objects created using it (DB and DBLock objects) and refuse to call the sleepycat close() method if any still exist (overridable using a force=1 flag). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-06-15 20:14 Message: Logged In: YES user_id=33168 Greg do you know anything about this? Is it still a problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788526&group_id=5470 From noreply at sourceforge.net Wed Jan 25 07:10:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 22:10:10 -0800 Subject: [ python-Bugs-1033390 ] build doesn't pick up bsddb w/Mandrake 9.2 Message-ID: Bugs item #1033390, was opened at 2004-09-23 06:58 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033390&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) >Assigned to: Neal Norwitz (nnorwitz) Summary: build doesn't pick up bsddb w/Mandrake 9.2 Initial Comment: Mandrake 9.2 installs bsddb 4.1 under /usr/lib, and apparently Python 2.4a3's setup.py doesn't pick it up -- adding /usr/lib to the list of directories where bsddb 4 is being searched for, and rerunning make, seems to fix the problem. (Problem does not appear on Mandrake 9.1, where I had installed sleepycat's stuff under /usr/local/BerkeleyDB.4.1 "by hand"; nor on MacOSX, where I had a fink-installed one in /sw/lib; no similar problem with any other module on any of these platforms, except bsddb). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-24 22:10 Message: Logged In: YES user_id=33168 Alex? I suspect this isn't a problem any longer. If we don't hear back within a month, we'll close this report. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2004-12-13 04:15 Message: Logged In: YES user_id=413 Could you try this again using python CVS HEAD. I just committed a rework of setup.py's bsddb library+include file finding code that hopefully does the right thing for you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033390&group_id=5470 From noreply at sourceforge.net Wed Jan 25 07:12:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 22:12:05 -0800 Subject: [ python-Bugs-1227955 ] shelve/bsddb crash on db close Message-ID: Bugs item #1227955, was opened at 2005-06-26 16:38 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227955&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Scott (ses4j) >Assigned to: Neal Norwitz (nnorwitz) Summary: shelve/bsddb crash on db close Initial Comment: I have a 300 meg bsddb/hash db created and accessed by shelve. No problems when running python only. But I started accessing the code that opens it via a windows DLL, opening and closing the DB on PROCESS_ATTACH and DETACH. All of a sudden, it would crash in the bsddb module on closing/del'ing the db. Found a workaround by opening the db with shelve.BsddbShelf(..) instead of shelve.open(..) - then it closed fine when the DLL unloaded, no crash. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-24 22:12 Message: Logged In: YES user_id=33168 If we don't hear back within a month, we should close this as probably fixed by the patch that was checked in. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-24 00:03 Message: Logged In: YES user_id=33168 Perhaps this is related to bug 1413192? Could you try the patch there and see if it fixes this problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227955&group_id=5470 From noreply at sourceforge.net Wed Jan 25 07:25:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 22:25:14 -0800 Subject: [ python-Bugs-874534 ] 2.[345]: --with-wctype-functions 4 test failures Message-ID: Bugs item #874534, was opened at 2004-01-10 10:32 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=874534&group_id=5470 Please note that this 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: Wont Fix Priority: 5 Submitted By: Pierre (pierre42) Assigned to: Neal Norwitz (nnorwitz) Summary: 2.[345]: --with-wctype-functions 4 test failures Initial Comment: # gmake test case $MAKEFLAGS in \ *-s*) LD_LIBRARY_PATH=/tmp/Python-2.3.3:/usr/local/lib:/usr/local/qt/lib:/usr/local/kde/lib:/usr/local/pwlib/lib:/usr/local/openh323/lib CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; \ *) LD_LIBRARY_PATH=/tmp/Python-2.3.3:/usr/local/lib:/usr/local/qt/lib:/usr/local/kde/lib:/usr/local/pwlib/lib:/usr/local/openh323/lib CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py build;; \ esac running build running build_ext building 'dbm' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -fno-strict-aliasing -DHAVE_NDBM_H -I. -I/tmp/Python-2.3.3/./Include -I/usr/local/include -I/tmp/Python-2.3.3/Include -I/tmp/Python-2.3.3 -c /tmp/Python-2.3.3/Modules/dbmmodule.c -o build/temp.linux-i686-2.3/dbmmodule.o gcc -shared build/temp.linux-i686-2.3/dbmmodule.o -L/usr/local/lib -o build/lib.linux-i686-2.3/dbm.so *** WARNING: renaming "dbm" since importing it failed: build/lib.linux-i686-2.3/dbm.so: undefined symbol: dbm_firstkey running build_scripts find ./Lib -name '*.py[co]' -print | xargs rm -f LD_LIBRARY_PATH=/tmp/Python-2.3.3:/usr/local/lib:/usr/local/qt/lib:/usr/local/kde/lib:/usr/local/pwlib/lib:/usr/local/openh323/lib ./python -E -tt ./Lib/test/regrtest.py -l test_grammar [...] test_codecs test test_codecs failed -- Traceback (most recent call last): File "/tmp/Python-2.3.3/Lib/test/test_codecs.py", line 333, in test_nameprep raise test_support.TestFailed("Test 3.%d: %s" % (pos+1, str(e))) TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9' test_codeop [...] test_format /tmp/Python-2.3.3/Lib/test/test_format.py:19: FutureWarning: %u/%o/%x/%X of negative int will return a signed string in Python 2.4 and up result = formatstr % args test_fpformat [...] test_re test test_re produced unexpected output: ********************************************************************** *** lines 2-3 of actual output doesn't appear in expected output after line 1: + === Failed incorrectly ('(?u)\\b.\\b', u'\xc4', 0, 'found', u'\xc4') + === Failed incorrectly ('(?u)\\w', u'\xc4', 0, 'found', u'\xc4') ********************************************************************** test_regex [...] test_unicode test test_unicode failed -- errors occurred in test.test_unicode.UnicodeTest test_unicode_file test_unicode_file skipped -- No Unicode filesystem semantics on this platform. test_unicodedata test test_unicodedata failed -- Traceback (most recent call last): File "/tmp/Python-2.3.3/Lib/test/test_unicodedata.py", line 62, in test_method_checksum self.assertEqual(result, self.expectedchecksum) File "/tmp/Python-2.3.3/Lib/unittest.py", line 302, in failUnlessEqual raise self.failureException, \ AssertionError: 'c269de8355871e3210ae8710b45c2ddb0675b9d5' != 'a37276dc2c158bef6dfd908ad34525c97180fad9' test_univnewlines [...] test_zlib 222 tests OK. 4 tests failed: test_codecs test_re test_unicode test_unicodedata 29 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_cd test_cl test_curses test_dbm test_email_codecs test_gl test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound 2 skips unexpected on linux2: test_dbm test_locale gmake: *** [test] Error 1 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-01-09 04:11 Message: Logged In: YES user_id=38388 This option should/will go away in Python 2.5, so I don't think there's a need to bother with trying to fix problems related to it. The reason for the removal is that the option causes semantical problems and makes Unicode work in non-standard ways on platforms that use locale-aware extensions to the wc-type functions. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-08 21:47 Message: Logged In: YES user_id=33168 Confirmed these are still a current problem in SVN. The problem is: --with-wctype-functions. With this option all 4 tests fail on amd64 gentoo linux. ---------------------------------------------------------------------- Comment By: Matejcik (spektrum) Date: 2005-10-25 08:29 Message: Logged In: YES user_id=631694 i can confirm it happens in 2.3.3 and 2.3.5 compiler is gcc 3.3.3 or 4.0.2, happens with and without optimization i used the following configure options: --with-wctype-functions --with-fpectl --enable-shared --enable-unicode when using defaults, the tests pass ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 00:12 Message: Logged In: YES user_id=33168 Are you still having these problems? What compiler are you using? Have you tried building without optimization to see if the problems go away? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=874534&group_id=5470 From noreply at sourceforge.net Wed Jan 25 07:26:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 22:26:07 -0800 Subject: [ python-Bugs-786194 ] posixmodule uses utimes, which is broken in glibc-2.3.2 Message-ID: Bugs item #786194, was opened at 2003-08-10 02:34 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786194&group_id=5470 Please note that this 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.3 >Status: Closed Resolution: None Priority: 7 Submitted By: Matthias Klose (doko) Assigned to: Neal Norwitz (nnorwitz) Summary: posixmodule uses utimes, which is broken in glibc-2.3.2 Initial Comment: Maybe this is category 'Build' ... at least it results in '1970/01/01-01:00:01' timestamps on all files copied by distutils on glibc-2.3.2 based systems (2.3.1 seems to be ok). Disabling the detection of the utimes function in configure works around this. As this function is a wrapper around utime, why not use this one directly? Or check, if utimes correctly works. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-24 22:26 Message: Logged In: YES user_id=33168 Closing due to inactivity. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-01 22:54 Message: Logged In: YES user_id=33168 Matthias, can this be closed? Is this still relevant? ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-08-10 03:54 Message: Logged In: YES user_id=60903 for an utimes check see http://lists.debian.org/debian-glibc/2003/debian-glibc-200308/msg00115.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786194&group_id=5470 From noreply at sourceforge.net Wed Jan 25 07:28:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 22:28:03 -0800 Subject: [ python-Bugs-1196154 ] Error: ... ossaudiodev.c, line 48: Missing type specifier Message-ID: Bugs item #1196154, was opened at 2005-05-05 12:53 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196154&group_id=5470 Please note that this 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: Works For Me Priority: 5 Submitted By: Will L G (diskman) Assigned to: Neal Norwitz (nnorwitz) Summary: Error: ... ossaudiodev.c, line 48: Missing type specifier Initial Comment: RedHat Linux 7.2 [alpha] Kernel 2.6.11.6 Compaq C 6.5.2 Binutils 2.15 Make 2.8 Was receiving the error below and then a few little changes to make the configure script think I was using gcc while still using ccc... [root at jericho Python-2.4.1]# make case $MAKEFLAGS in \ *-s*) LD_LIBRARY_PATH=/usr2/www/linux- related/programming/python/Python- 2.4.1:/usr/X11R6/lib:/usr/lib:/usr/local/lib CC='ccache ccc - pthread' LDSHARED='ccache ccc -pthread -shared' OPT='- DNDEBUG -O' ./python -E ./setup.py -q build;; \ *) LD_LIBRARY_PATH=/usr2/www/linux- related/programming/python/Python- 2.4.1:/usr/X11R6/lib:/usr/lib:/usr/local/lib CC='ccache ccc - pthread' LDSHARED='ccache ccc -pthread -shared' OPT='- DNDEBUG -O' ./python -E ./setup.py build;; \ esac Could not find platform independent libraries Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] 'import site' failed; use -v for traceback Traceback (most recent call last): File "./setup.py", line 6, in ? import sys, os, getopt, imp, re ImportError: No module named os make: *** [sharedmods] Error 1 [root at jericho Python-2.4.1]# Here is a copy of the little script I used to set the env to use ccc while configuring python to compile using gcc and thus build the appropriate extensions: ./configure \ --prefix=/usr \ --sysconfdir=/etc \ --build=alphapca56-alpha-linux-gnu \ --without-gcc \ --enable-shared \ --with-dec-threads \ --with-cxx="ccache cxx" \ --with-cc="ccache ccc" \ --without-threads make CC="ccache ccc" CXX="ccache cxx" \ CFLAGS="-O5 -fast -mtune=ev56 -w -pipe - lpthread -threads" \ CXXFLAGS="-O5 -fast -mtune=ev56 -w -pipe - lpthread -threads" EVERYTHING compiled fine but for one little thing, two extensions didn't compile: building 'ossaudiodev' extension ccache ccc -DNDEBUG -O -fPIC -OPT:Olimit=0 -I. - I/usr2/www/pub/alpha-RH7/programming/python/Python- 2.4.1/./Include -I/usr/local/include -I/usr2/www/pub/alpha- RH7/programming/python/Python-2.4.1/Include - I/usr2/www/pub/alpha-RH7/programming/python/Python- 2.4.1 -c /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/Modules/ossaudiodev.c -o build/temp.linux-alpha- 2.4/ossaudiodev.o cc: Error: /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/Modules/ossaudiodev.c, line 48: Missing type specifier or type qualifier. (missingtype) PyObject_HEAD; -----------------^ cc: Error: /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/Modules/ossaudiodev.c, line 57: Missing type specifier or type qualifier. (missingtype) PyObject_HEAD; -----------------^ ccache ccc -DNDEBUG -O -fPIC -OPT:Olimit=0 -I. - I/usr2/www/pub/alpha-RH7/programming/python/Python- 2.4.1/./Include -I/usr/local/include -I/usr2/www/pub/alpha- RH7/programming/python/Python-2.4.1/Include - I/usr2/www/pub/alpha-RH7/programming/python/Python- 2.4.1 -c /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/Modules/ossaudiodev.c -o build/temp.linux-alpha- 2.4/ossaudiodev.o cc: Error: /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/Modules/ossaudiodev.c, line 48: Missing type specifier or type qualifier. (missingtype) PyObject_HEAD; -----------------^ cc: Error: /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/Modules/ossaudiodev.c, line 57: Missing type specifier or type qualifier. (missingtype) PyObject_HEAD; -----------------^ cc: Info: /usr2/www/pub/alpha- RH7/programming/python/Python- 2.4.1/./Include/objimpl.h, line 255: In this declaration, type long double has the same representation as type double on this platform. (longdoublenyi) long double dummy; /* force worst-case alignment */ ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-09 23:20 Message: Logged In: YES user_id=33168 The problem could be an extra ; on the PyObject_HEAD line. (There shouldn't be any.) The semi-colon has been removed in SVN. Can you verify that is the problem? The fix wasn't ported to 2.4, but that's easy enough if removing the semi-colon fixes the problem. If you want faster resolution, perhaps you can volunteer to help out. ---------------------------------------------------------------------- Comment By: Will L G (diskman) Date: 2005-08-04 09:13 Message: Logged In: YES user_id=312992 I thought Python-2.4.1 was in 'bug fix' mode? Well this fucker is as OLD as dirt... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196154&group_id=5470 From noreply at sourceforge.net Wed Jan 25 08:08:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 24 Jan 2006 23:08:57 -0800 Subject: [ python-Bugs-1199282 ] subprocess _active.remove(self) self not in list _active Message-ID: Bugs item #1199282, was opened at 2005-05-10 18:24 Message generated for change (Comment added) made by atila-cheops You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: cheops (atila-cheops) Assigned to: Peter ?strand (astrand) Summary: subprocess _active.remove(self) self not in list _active Initial Comment: I start a subprocess in a seperate thread (25 concurrent threads) in some of the threads the following error occurs Exception in thread Thread-4: Traceback (most recent call last): File "C:\Python24\lib\threading.py", line 442, in __bootstrap self.run() File "upgrade.py", line 45, in run returncode = p.wait() File "C:\Python24\lib\subprocess.py", line 765, in wait _active.remove(self) ValueError: list.remove(x): x not in list this is the code that starts the subprocess and where I wait for the result p = subprocess.Popen('command', \ stdin=None, stdout=subprocess.PIPE, \ stderr=subprocess.STDOUT, universal_newlines=True) returncode = p.wait() errormessage = p.stdout.readlines() ---------------------------------------------------------------------- >Comment By: cheops (atila-cheops) Date: 2006-01-25 07:08 Message: Logged In: YES user_id=1276121 As suggested by astrand adding a try ... except clause in the file subprocess.py did the job I had to add that try ... except clause in 2 places if you look in the file there are 2 instances were list.remove(x) occurs unprotected. try: list.remove(x) except: pass I have worked with 2.4.0, 2.4.1 and 2.4.2 and all three needed the patch. Hope this helps. ---------------------------------------------------------------------- Comment By: HVB bei TUP (hvb_tup) Date: 2006-01-23 16:34 Message: Logged In: YES user_id=1434251 BTW: In my case, I call python.exe from a Windows service. ---------------------------------------------------------------------- Comment By: HVB bei TUP (hvb_tup) Date: 2006-01-23 16:30 Message: Logged In: YES user_id=1434251 I have a similar problem. Python 2.4.1 under MS Windows 2003, Multi-Threaded application (about concurrent 10 threads). In my case the same error occurs during _cleanup called from __init__ : File "E:\lisa_ins\ewu\coop\reporting\python\tup_lisa\util\t hreadutil.py", line 582, in callSubProcess creationflags = creationflags File "C:\Python24\lib\subprocess.py", line 506, in __init__ _cleanup() File "C:\Python24\lib\subprocess.py", line 414, in _cleanup inst.poll() File "C:\Python24\lib\subprocess.py", line 755, in poll _active.remove(self) ValueError: list.remove(x): x not in list Is there a work-around? ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2005-09-19 09:29 Message: Logged In: YES user_id=1276121 I noticed this bug under windows to reproduce the bug, I attached the script I use, but this needs input, I tried with a simpler example (pinging a number of host concurrently) but that did not cause the bug. ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2005-06-23 16:03 Message: Logged In: YES user_id=344921 I believe it should be sufficient to add a try...except clause around _active.remove(). Can you upload a complete example that triggers the bug? Have you noticed this bug on Windows, UNIX or both platforms? ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2005-05-12 10:17 Message: Logged In: YES user_id=1276121 this might be related to bug 1183780 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470 From noreply at sourceforge.net Wed Jan 25 09:10:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 25 Jan 2006 00:10:00 -0800 Subject: [ python-Bugs-1199282 ] subprocess _active.remove(self) self not in list _active Message-ID: Bugs item #1199282, was opened at 2005-05-10 18:24 Message generated for change (Comment added) made by hvb_tup You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: cheops (atila-cheops) Assigned to: Peter ?strand (astrand) Summary: subprocess _active.remove(self) self not in list _active Initial Comment: I start a subprocess in a seperate thread (25 concurrent threads) in some of the threads the following error occurs Exception in thread Thread-4: Traceback (most recent call last): File "C:\Python24\lib\threading.py", line 442, in __bootstrap self.run() File "upgrade.py", line 45, in run returncode = p.wait() File "C:\Python24\lib\subprocess.py", line 765, in wait _active.remove(self) ValueError: list.remove(x): x not in list this is the code that starts the subprocess and where I wait for the result p = subprocess.Popen('command', \ stdin=None, stdout=subprocess.PIPE, \ stderr=subprocess.STDOUT, universal_newlines=True) returncode = p.wait() errormessage = p.stdout.readlines() ---------------------------------------------------------------------- Comment By: HVB bei TUP (hvb_tup) Date: 2006-01-25 08:10 Message: Logged In: YES user_id=1434251 Wouldn't it be best to completely remove any references to "_active" and "_cleanup"? ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2006-01-25 07:08 Message: Logged In: YES user_id=1276121 As suggested by astrand adding a try ... except clause in the file subprocess.py did the job I had to add that try ... except clause in 2 places if you look in the file there are 2 instances were list.remove(x) occurs unprotected. try: list.remove(x) except: pass I have worked with 2.4.0, 2.4.1 and 2.4.2 and all three needed the patch. Hope this helps. ---------------------------------------------------------------------- Comment By: HVB bei TUP (hvb_tup) Date: 2006-01-23 16:34 Message: Logged In: YES user_id=1434251 BTW: In my case, I call python.exe from a Windows service. ---------------------------------------------------------------------- Comment By: HVB bei TUP (hvb_tup) Date: 2006-01-23 16:30 Message: Logged In: YES user_id=1434251 I have a similar problem. Python 2.4.1 under MS Windows 2003, Multi-Threaded application (about concurrent 10 threads). In my case the same error occurs during _cleanup called from __init__ : File "E:\lisa_ins\ewu\coop\reporting\python\tup_lisa\util\t hreadutil.py", line 582, in callSubProcess creationflags = creationflags File "C:\Python24\lib\subprocess.py", line 506, in __init__ _cleanup() File "C:\Python24\lib\subprocess.py", line 414, in _cleanup inst.poll() File "C:\Python24\lib\subprocess.py", line 755, in poll _active.remove(self) ValueError: list.remove(x): x not in list Is there a work-around? ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2005-09-19 09:29 Message: Logged In: YES user_id=1276121 I noticed this bug under windows to reproduce the bug, I attached the script I use, but this needs input, I tried with a simpler example (pinging a number of host concurrently) but that did not cause the bug. ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2005-06-23 16:03 Message: Logged In: YES user_id=344921 I believe it should be sufficient to add a try...except clause around _active.remove(). Can you upload a complete example that triggers the bug? Have you noticed this bug on Windows, UNIX or both platforms? ---------------------------------------------------------------------- Comment By: cheops (atila-cheops) Date: 2005-05-12 10:17 Message: Logged In: YES user_id=1276121 this might be related to bug 1183780 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470 From noreply at sourceforge.net Wed Jan 25 09:36:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 25 Jan 2006 00:36:40 -0800 Subject: [ python-Bugs-786194 ] posixmodule uses utimes, which is broken in glibc-2.3.2 Message-ID: Bugs item #786194, was opened at 2003-08-10 11:34 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786194&group_id=5470 Please note that this 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.3 Status: Closed Resolution: None Priority: 7 Submitted By: Matthias Klose (doko) Assigned to: Neal Norwitz (nnorwitz) Summary: posixmodule uses utimes, which is broken in glibc-2.3.2 Initial Comment: Maybe this is category 'Build' ... at least it results in '1970/01/01-01:00:01' timestamps on all files copied by distutils on glibc-2.3.2 based systems (2.3.1 seems to be ok). Disabling the detection of the utimes function in configure works around this. As this function is a wrapper around utime, why not use this one directly? Or check, if utimes correctly works. ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2006-01-25 09:36 Message: Logged In: YES user_id=60903 It is not necessary for glibc-2.3.5 and more recent versions, older glibc versions still have the problem. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-25 07:26 Message: Logged In: YES user_id=33168 Closing due to inactivity. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 07:54 Message: Logged In: YES user_id=33168 Matthias, can this be closed? Is this still relevant? ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-08-10 12:54 Message: Logged In: YES user_id=60903 for an utimes check see http://lists.debian.org/debian-glibc/2003/debian-glibc-200308/msg00115.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786194&group_id=5470 From noreply at sourceforge.net Wed Jan 25 09:41:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 25 Jan 2006 00:41:51 -0800 Subject: [ python-Bugs-786194 ] posixmodule uses utimes, which is broken in glibc-2.3.2 Message-ID: Bugs item #786194, was opened at 2003-08-10 02:34 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786194&group_id=5470 Please note that this 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.3 Status: Closed Resolution: None Priority: 7 Submitted By: Matthias Klose (doko) Assigned to: Neal Norwitz (nnorwitz) Summary: posixmodule uses utimes, which is broken in glibc-2.3.2 Initial Comment: Maybe this is category 'Build' ... at least it results in '1970/01/01-01:00:01' timestamps on all files copied by distutils on glibc-2.3.2 based systems (2.3.1 seems to be ok). Disabling the detection of the utimes function in configure works around this. As this function is a wrapper around utime, why not use this one directly? Or check, if utimes correctly works. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-25 00:41 Message: Logged In: YES user_id=33168 Thanks for the comment. I don't think we will try to cater to this bug in glibc. BTW, are you still working on Debian a lot? Are there many outstanding bugs wrt python? ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2006-01-25 00:36 Message: Logged In: YES user_id=60903 It is not necessary for glibc-2.3.5 and more recent versions, older glibc versions still have the problem. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-24 22:26 Message: Logged In: YES user_id=33168 Closing due to inactivity. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-01 22:54 Message: Logged In: YES user_id=33168 Matthias, can this be closed? Is this still relevant? ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-08-10 03:54 Message: Logged In: YES user_id=60903 for an utimes check see http://lists.debian.org/debian-glibc/2003/debian-glibc-200308/msg00115.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786194&group_id=5470 From noreply at sourceforge.net Wed Jan 25 15:25:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 25 Jan 2006 06:25:48 -0800 Subject: [ python-Bugs-1414612 ] Can only install 1 of each version of Python on Windows Message-ID: Bugs item #1414612, was opened at 2006-01-25 14:25 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=1414612&group_id=5470 Please note that this 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: Open Resolution: None Priority: 5 Submitted By: Max M Rasmussen (maxmcorp) Assigned to: Nobody/Anonymous (nobody) Summary: Can only install 1 of each version of Python on Windows Initial Comment: It is not possible to install more than one version of Python 2.4 on a Windows machine with the current installer. First time The installer is used, it is fine. Next time I have tree options: Change, Repair & Remove. I need a "Install another instance" I work in Zope, and recently I have been developing in Zope 3. Zope 3 is installed under "site-packages". If I only need one Version of Zope 3, it is no problem. But if I need both 3.2 and the current trunk from subversion, I cannot do it, as I can only install one version of Zope 3.x per python. And with only one Python, that means I can only have one version of Zope 3.x. As far as I can figure out, this must be a general problem for different library version that must be tested on the same Python version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1414612&group_id=5470 From noreply at sourceforge.net Wed Jan 25 16:03:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 25 Jan 2006 07:03:59 -0800 Subject: [ python-Bugs-1414612 ] Can only install 1 of each version of Python on Windows Message-ID: Bugs item #1414612, was opened at 2006-01-25 09:25 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1414612&group_id=5470 Please note that this 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: Open Resolution: None Priority: 5 Submitted By: Max M Rasmussen (maxmcorp) Assigned to: Nobody/Anonymous (nobody) Summary: Can only install 1 of each version of Python on Windows Initial Comment: It is not possible to install more than one version of Python 2.4 on a Windows machine with the current installer. First time The installer is used, it is fine. Next time I have tree options: Change, Repair & Remove. I need a "Install another instance" I work in Zope, and recently I have been developing in Zope 3. Zope 3 is installed under "site-packages". If I only need one Version of Zope 3, it is no problem. But if I need both 3.2 and the current trunk from subversion, I cannot do it, as I can only install one version of Zope 3.x per python. And with only one Python, that means I can only have one version of Zope 3.x. As far as I can figure out, this must be a general problem for different library version that must be tested on the same Python version. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-01-25 10:03 Message: Logged In: YES user_id=31435 You _can_ install a given Python version multiple times on Windows now, but to do so you need to set up a new account (which is easy) for each one, and do "just for me" (not "all users") installs of Python (and giving each a different installation directory). It can be a pain switching between accounts, but that's your only hope for short-term relief. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1414612&group_id=5470 From noreply at sourceforge.net Wed Jan 25 16:23:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 25 Jan 2006 07:23:41 -0800 Subject: [ python-Bugs-1414673 ] Underspecified behaviour of string.split/rsplit Message-ID: Bugs item #1414673, was opened at 2006-01-25 10: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=1414673&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Underspecified behaviour of string.split/rsplit Initial Comment: The documentation for the string methods split and rsplit do not address the case where sep=None and maxsplit=0. Should this strip off the leading and trailing whitespace, but not do any splits? Should it simply return the invocant string? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1414673&group_id=5470 From noreply at sourceforge.net Wed Jan 25 16:39:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 25 Jan 2006 07:39:04 -0800 Subject: [ python-Bugs-1339007 ] shelve.Shelf.__del__ throws exceptions Message-ID: Bugs item #1339007, was opened at 2005-10-26 16:30 Message generated for change (Comment added) made by dairiki You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1339007&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Geoffrey T. Dairiki (dairiki) Assigned to: Raymond Hettinger (rhettinger) Summary: shelve.Shelf.__del__ throws exceptions Initial Comment: Python calls an object's __del__ method, even if the objects __init__ method was unsuccessful (i.e. __init__ terminated via exception.) Because of this, if there is an error while attempting to open a Shelf, the destructor is still called, even though the Shelf is not fully constructed. The code in shelve.Shelf does not check for this possibility, and therefor triggers an AttributeError. Here is an example script which should reproduce the error. ===Begin test.py====l import shelve try: shelf = shelve.open('non-existant-file', flag='r') except: pass ===End test.py===== For me, the above script produces the message: Exception exceptions.AttributeError: "DbfilenameShelf instance has no attribute 'writeback'" in ignored I can reproduce this using either Python 2.4.1 or 2.3.5. I took a quick look at the current CVS version of shelve.py, and it appears to suffer the same problem. ---------------------------------------------------------------------- >Comment By: Geoffrey T. Dairiki (dairiki) Date: 2006-01-25 07:39 Message: Logged In: YES user_id=45814 Exceptions thrown in __del__ are not quite complete ignored, since the fact that they are being "ignored" is reported on sys.stderr. The bug in question results in spurious, confusing messages being issued to sys.stderr. I say it is a bug. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 14:10 Message: Logged In: YES user_id=1188172 Is this a bug? As exceptions in __del__ are ignored, this should do no harm. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1339007&group_id=5470 From noreply at sourceforge.net Wed Jan 25 16:43:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 25 Jan 2006 07:43:15 -0800 Subject: [ python-Bugs-1414697 ] inconsistency in help(set) Message-ID: Bugs item #1414697, was opened at 2006-01-25 18:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1414697&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gregory Petrosyan (gregory_p) Assigned to: Nobody/Anonymous (nobody) Summary: inconsistency in help(set) Initial Comment: >>> help(set) Help on class set in module __builtin__: class set(object) | set(iterable) --> set object | | Build an unordered collection. | | Methods defined here: | ... It would be better for docstring to be """Build an unordered collection with no duplicate elements.""" instead of """Build an unordered collection.""" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1414697&group_id=5470 From noreply at sourceforge.net Wed Jan 25 21:52:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 25 Jan 2006 12:52:00 -0800 Subject: [ python-Bugs-1413790 ] zipfile: inserting some filenames produces corrupt .zips Message-ID: Bugs item #1413790, was opened at 2006-01-24 09:57 Message generated for change (Comment added) made by logistix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413790&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Grant Olson (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile: inserting some filenames produces corrupt .zips Initial Comment: Running something like the following produces a corrupt .zip file. The builtin XP zip folder view won't show any documents and attempting to extract via "right click -> Extract files..." will set off an untrusted file alert: import zipfile z = zipfile.ZipFile("c:\\foo.zip","w") z.write("c:\\autoexec.bat", "\\autoexec.bat") z.close() zipfile should either throw an error when adding these files or attempt to normalize the path. I would prefer that zipfile make the assumption that any files starting with absolute or relative pathnames ("\\foo\\bar.txt" or ".\\foo\\bar.txt") should join in at the root of the zipfile ("foo\\bar.txt" in this case). Patch to accomplish the latter is attached. ---------------------------------------------------------------------- >Comment By: Grant Olson (logistix) Date: 2006-01-25 14:52 Message: Logged In: YES user_id=699438 Just wanted to note that the documentation of the .zip format from pkzip explicitly states that a drive letter or leading slash is not allowed. The pertinent text: file name: (Variable) The name of the file, with optional relative path. The path stored should not contain a drive or device letter, or a leading slash. All slashes should be forward slashes '/' as opposed to backwards slashes '\' for compatibility with Amiga and UNIX file systems etc. If input came from standard input, there is no file name field. If encrypting the central directory and general purpose bit flag 13 is set indicating masking, the file name stored in the Local Header will not be the actual file name. A masking value consisting of a unique hexadecimal value will be stored. This value will be sequentially incremented for each file in the archive. See the section on the Strong Encryption Specification for details on retrieving the encrypted file name. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413790&group_id=5470 From noreply at sourceforge.net Thu Jan 26 15:38:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 Jan 2006 06:38:18 -0800 Subject: [ python-Bugs-1415455 ] Typo in online documentation - 6.8.3.6 Replacing popen2.* Message-ID: Bugs item #1415455, was opened at 2006-01-26 14: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=1415455&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Phil Wright (phlipped) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in online documentation - 6.8.3.6 Replacing popen2.* Initial Comment: I think a module name is misspelled on the following page of the Python Library Reference ... Document: Python Library Reference Page Title: 6.8.3.6 Replacing popen2.* Page Address: http://docs.python.org/lib/node246.html The page contains the following text ... "The popen2.Popen3 and popen3.Popen4 basically works as subprocess.Popen, except that:" The reference to the class "popen3.Popen4" should be "popen2.Popen4" (There is no module "popen3") The correct text would be ... "The popen2.Popen3 and popen2.Popen4 basically works as subprocess.Popen, except that:" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1415455&group_id=5470 From noreply at sourceforge.net Thu Jan 26 17:04:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 26 Jan 2006 08:04:09 -0800 Subject: [ python-Bugs-1380970 ] split() description not fully accurate Message-ID: Bugs item #1380970, was opened at 2005-12-14 18:33 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1380970&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: K.C. (kace) Assigned to: Raymond Hettinger (rhettinger) Summary: split() description not fully accurate Initial Comment: The page http://docs.python.org/lib/string-methods.html reads, in part, "If sep is not specified or is None, a different splitting algorithm is applied. First, whitespace characters (spaces, tabs, newlines, returns, and formfeeds) are stripped from both ends." However, this is not the behaviour that I'm seeing. (Although, I should note that I'd find the described behaviour more desirable.) Example, >>> trow = '1586\tsome-int-name\tNODES: 111_222\n' >>> print trow 1234 some-int-name NODES: 111_222 >>> trow.split(None,2) ['1234', 'some-int-name', 'NODES: 111_222\n'] # end example. Notice that the trailing newline has not been stripped as the documentation said it should be. Thanks all. K.C. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-01-26 11:04 Message: Logged In: YES user_id=1344176 I've provided a patch for this: #1414934. ---------------------------------------------------------------------- Comment By: K.C. (kace) Date: 2005-12-14 18:36 Message: Logged In: YES user_id=741142 Also, (oops) the example comes from the most recent version: $ python Python 2.4.2 (#2, Oct 4 2005, 13:57:10) [GCC 3.4.2 [FreeBSD] 20040728] on freebsd5 Type "help", "copyright", "credits" or "license" for more information. >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1380970&group_id=5470 From noreply at sourceforge.net Fri Jan 27 15:51:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 Jan 2006 06:51:15 -0800 Subject: [ python-Bugs-1416477 ] Inconsistency between StringIO and cStringIO Message-ID: Bugs item #1416477, was opened at 2006-01-27 14: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=1416477&group_id=5470 Please note that this 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 Submitted By: Michael Kerrin (mkerrin) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistency between StringIO and cStringIO Initial Comment: The readline method for StringIO defalt argument for the size arguement is None while for all other file-like objects it is -1. So if we pass in -1 to the StringIO readline method, all lines are returned, again inconsistent with the other file-like objects, and if we pass in None to any other file-like object we get a TypeError, int required. The attached python script is a very simple example of what I mean. Note that this is causing me a lot of grief in trying to get tests to pass for a simple fix to an open source project. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1416477&group_id=5470 From noreply at sourceforge.net Fri Jan 27 15:55:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 Jan 2006 06:55:40 -0800 Subject: [ python-Bugs-1416477 ] Inconsistency between StringIO and cStringIO Message-ID: Bugs item #1416477, was opened at 2006-01-27 09:51 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1416477&group_id=5470 Please note that this 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 Submitted By: Michael Kerrin (mkerrin) >Assigned to: Raymond Hettinger (rhettinger) Summary: Inconsistency between StringIO and cStringIO Initial Comment: The readline method for StringIO defalt argument for the size arguement is None while for all other file-like objects it is -1. So if we pass in -1 to the StringIO readline method, all lines are returned, again inconsistent with the other file-like objects, and if we pass in None to any other file-like object we get a TypeError, int required. The attached python script is a very simple example of what I mean. Note that this is causing me a lot of grief in trying to get tests to pass for a simple fix to an open source project. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1416477&group_id=5470 From noreply at sourceforge.net Fri Jan 27 15:56:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 Jan 2006 06:56:23 -0800 Subject: [ python-Bugs-1414697 ] inconsistency in help(set) Message-ID: Bugs item #1414697, was opened at 2006-01-25 10:43 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1414697&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gregory Petrosyan (gregory_p) >Assigned to: Raymond Hettinger (rhettinger) Summary: inconsistency in help(set) Initial Comment: >>> help(set) Help on class set in module __builtin__: class set(object) | set(iterable) --> set object | | Build an unordered collection. | | Methods defined here: | ... It would be better for docstring to be """Build an unordered collection with no duplicate elements.""" instead of """Build an unordered collection.""" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1414697&group_id=5470 From noreply at sourceforge.net Fri Jan 27 16:38:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 27 Jan 2006 07:38:33 -0800 Subject: [ python-Bugs-1416544 ] Problem with SOAPpy on 64-bit systems Message-ID: Bugs item #1416544, was opened at 2006-01-27 15: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=1416544&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo J. A. M. Carneiro (gustavo) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with SOAPpy on 64-bit systems Initial Comment: Python 2.4.2 (#2, Sep 30 2005, 22:19:27) [GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu8)] on linux2 I get a traceback in SOAPpy: File "/usr/lib/python2.4/site-packages/SOAPpy/Parser.py", line 852, in convertToBasicTypes if fpconst.isNaN(d): File "/usr/lib/python2.4/site-packages/SOAPpy/fpconst.py", line 90, in isNaN return (_exponent(value)==0x7ff and _mantissa(value)!=0) File "/usr/lib/python2.4/site-packages/SOAPpy/fpconst.py", line 72, in _exponent ll = _double_as_longs(dval) File "/usr/lib/python2.4/site-packages/SOAPpy/fpconst.py", line 51, in _double_as_longs tmp = struct.unpack('ll',struct.pack('d', dval)) error: unpack str size does not match format I'm on a AMD64 system. Thus 'l', which long, is 64-bits wide, that's why this fails. Changing 'll' to 'ii' seems to fix the problem, but I'm not expert on SOAP :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1416544&group_id=5470 From noreply at sourceforge.net Sat Jan 28 10:18:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 Jan 2006 01:18:01 -0800 Subject: [ python-Bugs-1267547 ] bdist_rpm hardcodes setup.py as the script name Message-ID: Bugs item #1267547, was opened at 2005-08-24 02:59 Message generated for change (Comment added) made by pearu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267547&group_id=5470 Please note that this 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: 7 Submitted By: Fernando P?rez (fer_perez) Assigned to: Martin v. L??wis (loewis) Summary: bdist_rpm hardcodes setup.py as the script name Initial Comment: The bdist_rpm command hardcodes 'setup.py' as the name of the setup script in the .spec file it generates. A grep of the bdist_rpm file shows this: planck[command]> grep -n -C 3 setup.py bdist_rpm.py 454- 455- # rpm scripts 456- # figure out default build script 457: def_build = "%s setup.py build" % self.python 458- if self.use_rpm_opt_flags: 459- def_build = 'env CFLAGS="$RPM_OPT_FLAGS" ' + def_build 460- -- 468- ('prep', 'prep_script', "%setup"), 469- ('build', 'build_script', def_build), 470- ('install', 'install_script', 471: ("%s setup.py install " 472- "--root=$RPM_BUILD_ROOT " 473- "--record=INSTALLED_FILES") % self.python), 474- ('clean', 'clean_script', "rm -rf $RPM_BUILD_ROOT"), But there are packages out there which ship with multiple setup files, named setup-foo.py, setup-bar.py, etc. While distutils correctly copies over the proper setup-X.py file to the build/ directory, the bdist_rpm command fails because rpm then tries to issue a build command against 'setup.py', which doesn't exist. An example can be seen by downloading the clnum library from http://calcrpnpy.sourceforge.net/clnum.html, and trying: lanck[rpncalc-2.0]> python clnum_setup.py bdist_rpm running bdist_rpm creating build creating build/bdist.linux-i686 creating build/bdist.linux-i686/rpm creating build/bdist.linux-i686/rpm/SOURCES creating build/bdist.linux-i686/rpm/SPECS creating build/bdist.linux-i686/rpm/BUILD creating build/bdist.linux-i686/rpm/RPMS creating build/bdist.linux-i686/rpm/SRPMS writing 'build/bdist.linux-i686/rpm/SPECS/clnum.spec' running sdist warning: sdist: manifest template 'MANIFEST.in' does not exist (using default file list) warning: sdist: standard file not found: should have one of README, README.txt writing manifest file 'MANIFEST' creating clnum-1.0 creating clnum-1.0/clnum creating clnum-1.0/clnum/src creating clnum-1.0/test making hard links in clnum-1.0... hard linking clnum_setup.py -> clnum-1.0 hard linking clnum/__init__.py -> clnum-1.0/clnum hard linking clnum/_clnum_str.py -> clnum-1.0/clnum hard linking clnum/src/clnum.cpp -> clnum-1.0/clnum/src hard linking test/test_clnum.py -> clnum-1.0/test [... snip] Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.8191 + umask 022 + cd /usr/local/installers/src/rpncalc-2.0/build/bdist.linux-i686/rpm/BUILD + cd clnum-1.0 + LANG=C + export LANG + unset DISPLAY + env 'CFLAGS=-O2 -g -pipe -m32 -march=i386 -mtune=pentium4' python setup.py build python: can't open file 'setup.py' error: Bad exit status from /var/tmp/rpm-tmp.8191 (%build) I think that the fix is as simple as replacing the hardcoded 'setup.py' name by os.path.basename(sys.argv[0]), but I'm not 100% sure. ---------------------------------------------------------------------- Comment By: Pearu Peterson (pearu) Date: 2006-01-28 11:18 Message: Logged In: YES user_id=88489 Related bug is 828743. In numpy.distutils we have long time used the same patch as suggested by fer_perez without problems. ---------------------------------------------------------------------- Comment By: Fernando P?rez (fer_perez) Date: 2005-08-24 20:12 Message: Logged In: YES user_id=395388 Well, here's a patch against 2.4 (sorry, but I can't build from CVS right now, I hope this is enough. I tested it on my problem build linked above, and it now works correctly, but I'm not a distutils expert, so I can't vouch 100% that it won't break in some corner case. It would be worth making sure that other similar commands (like the new bdist_deb in CVS) don't share the problem. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-08-24 08:41 Message: Logged In: YES user_id=21627 Would you like to try your proposed fix yourself, and contribute a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267547&group_id=5470 From noreply at sourceforge.net Sat Jan 28 13:20:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 Jan 2006 04:20:22 -0800 Subject: [ python-Bugs-1416544 ] Problem with SOAPpy on 64-bit systems Message-ID: Bugs item #1416544, was opened at 2006-01-27 16:38 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1416544&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library >Group: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Gustavo J. A. M. Carneiro (gustavo) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with SOAPpy on 64-bit systems Initial Comment: Python 2.4.2 (#2, Sep 30 2005, 22:19:27) [GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu8)] on linux2 I get a traceback in SOAPpy: File "/usr/lib/python2.4/site-packages/SOAPpy/Parser.py", line 852, in convertToBasicTypes if fpconst.isNaN(d): File "/usr/lib/python2.4/site-packages/SOAPpy/fpconst.py", line 90, in isNaN return (_exponent(value)==0x7ff and _mantissa(value)!=0) File "/usr/lib/python2.4/site-packages/SOAPpy/fpconst.py", line 72, in _exponent ll = _double_as_longs(dval) File "/usr/lib/python2.4/site-packages/SOAPpy/fpconst.py", line 51, in _double_as_longs tmp = struct.unpack('ll',struct.pack('d', dval)) error: unpack str size does not match format I'm on a AMD64 system. Thus 'l', which long, is 64-bits wide, that's why this fails. Changing 'll' to 'ii' seems to fix the problem, but I'm not expert on SOAP :) ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-01-28 13:20 Message: Logged In: YES user_id=21627 Notice that SOAPpy is not part of the Python core distribution. Please report this to the SOAPpy authors. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1416544&group_id=5470 From noreply at sourceforge.net Sat Jan 28 13:26:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 Jan 2006 04:26:55 -0800 Subject: [ python-Bugs-1414612 ] Can only install 1 of each version of Python on Windows Message-ID: Bugs item #1414612, was opened at 2006-01-25 15:25 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1414612&group_id=5470 Please note that this 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: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Max M Rasmussen (maxmcorp) Assigned to: Nobody/Anonymous (nobody) Summary: Can only install 1 of each version of Python on Windows Initial Comment: It is not possible to install more than one version of Python 2.4 on a Windows machine with the current installer. First time The installer is used, it is fine. Next time I have tree options: Change, Repair & Remove. I need a "Install another instance" I work in Zope, and recently I have been developing in Zope 3. Zope 3 is installed under "site-packages". If I only need one Version of Zope 3, it is no problem. But if I need both 3.2 and the current trunk from subversion, I cannot do it, as I can only install one version of Zope 3.x per python. And with only one Python, that means I can only have one version of Zope 3.x. As far as I can figure out, this must be a general problem for different library version that must be tested on the same Python version. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-01-28 13:26 Message: Logged In: YES user_id=21627 This is by the design of the Microsoft Windows installer. Each MSI file is identified by package code and product code. If you want to install the same package twice (in the same account), you have to change all UUIDs in the MSI package. I believe MSI "transforms" could help here. I'm closing this as "won't fix". If you still think this feature is necessary, please resubmit as a feature request (RFE). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-01-25 16:03 Message: Logged In: YES user_id=31435 You _can_ install a given Python version multiple times on Windows now, but to do so you need to set up a new account (which is easy) for each one, and do "just for me" (not "all users") installs of Python (and giving each a different installation directory). It can be a pain switching between accounts, but that's your only hope for short-term relief. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1414612&group_id=5470 From noreply at sourceforge.net Sat Jan 28 20:24:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 Jan 2006 11:24:21 -0800 Subject: [ python-Bugs-1417554 ] SimpleHTTPServer doesn't return last-modified headers Message-ID: Bugs item #1417554, was opened at 2006-01-28 13: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=1417554&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Aaron Swartz (aaronsw) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleHTTPServer doesn't return last-modified headers Initial Comment: SimpleHTTPServer doesn't return any Last-Modified headers with its responses, which means browsers can't cache them, which means if you try and view pages with images and things it has to reload all of them every time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417554&group_id=5470 From noreply at sourceforge.net Sat Jan 28 20:25:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 Jan 2006 11:25:08 -0800 Subject: [ python-Bugs-1417554 ] SimpleHTTPServer doesn't return last-modified headers Message-ID: Bugs item #1417554, was opened at 2006-01-28 13:24 Message generated for change (Comment added) made by aaronsw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417554&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Aaron Swartz (aaronsw) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleHTTPServer doesn't return last-modified headers Initial Comment: SimpleHTTPServer doesn't return any Last-Modified headers with its responses, which means browsers can't cache them, which means if you try and view pages with images and things it has to reload all of them every time. ---------------------------------------------------------------------- >Comment By: Aaron Swartz (aaronsw) Date: 2006-01-28 13:25 Message: Logged In: YES user_id=122141 Here's a patch: http://sourceforge.net/tracker/index.php? func=detail&aid=1417555&group_id=5470&atid=305470 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417554&group_id=5470 From noreply at sourceforge.net Sat Jan 28 22:16:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 Jan 2006 13:16:00 -0800 Subject: [ python-Bugs-1417598 ] EditorWindow demo causes attr-error Message-ID: Bugs item #1417598, was opened at 2006-01-29 06: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=1417598&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: snowman (snow_k2) Assigned to: Nobody/Anonymous (nobody) Summary: EditorWindow demo causes attr-error Initial Comment: Running EditorWindow.py causes next error : >>>>>>>>>> Traceback (most recent call last): File "C:\Python24\Lib\idlelib\EditorWindow.py", line 1410, in -toplevel- test() File "C:\Python24\Lib\idlelib\EditorWindow.py", line 1404, in test edit = EditorWindow(root=root, filename=filename) File "C:\Python24\Lib\idlelib\EditorWindow.py", line 190, in __init__ self.update_recent_files_list() File "C:\Python24\Lib\idlelib\EditorWindow.py", line 602, in update_recent_files_list if self.top.hasattr('instance_dict'): AttributeError: ListedToplevel instance has no attribute 'hasattr' <<<<<<< I think EditorWindow.update_recent_files_list() should check the 'instance_dict' attribute existance before accessing self.top.instance_dict.keys() in the def. if hasattr(self.top, 'instance_dict'): xxxxx xxxxx ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417598&group_id=5470 From noreply at sourceforge.net Sun Jan 29 02:04:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 28 Jan 2006 17:04:39 -0800 Subject: [ python-Bugs-1417699 ] float/atof have become locale aware Message-ID: Bugs item #1417699, was opened at 2006-01-29 02: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=1417699&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Bernhard Herzog (bernhard) Assigned to: Nobody/Anonymous (nobody) Summary: float/atof have become locale aware Initial Comment: The builtin float and the function string.atof have become locale aware in Python 2.4: Python 2.4.2 (#1, Nov 29 2005, 16:07:55) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> import string >>> locale.setlocale(locale.LC_ALL, "de_DE") 'de_DE' >>> float("1,5") 1.5 >>> string.atof("1,5") 1.5 This doesn't match what's specified in pep 331: - float() and str() stay locale-unaware. It also doesn't match the documentation for atof: Convert a string to a floating point number. The string must have the standard syntax for a floating point literal in Python, optionally preceded by a sign ("+" or "-"). Note that this behaves identical to the built-in function float() when passed a string. The documentation for float() doesn't state which format is accepted by float(), though. The reason for this behavior is ultimately, that PyOS_ascii_strtod accepts the locale specific convention in addition to the "C"-locale/python convention, even though the comment in the code preceding its definition states: This function behaves like the standard strtod() function does in the C locale. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&group_id=5470 From noreply at sourceforge.net Mon Jan 30 02:30:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 29 Jan 2006 17:30:28 -0800 Subject: [ python-Bugs-686667 ] os.spawnv(P_WAIT, ...) on Linux doesn't handle EINTR Message-ID: Bugs item #686667, was opened at 2003-02-14 11:47 Message generated for change (Comment added) made by david_k_hess You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=686667&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bernhard Herzog (bernhard) Assigned to: Nobody/Anonymous (nobody) Summary: os.spawnv(P_WAIT, ...) on Linux doesn't handle EINTR Initial Comment: The implementation of os.spawnv when called with the P_WAIT flag calls waitpid to wait for the subprocess. If this function is aborted early because of a signal, i.e. if it raises OSError with EINTR, it should be called again. I ran across this bug when trying to write a test case for a script that stops another process. Both the script and the other process are executed as subprocesses of the test program. The stop script is executed with os.spawnv(P_WAIT, ...) to wait until the script completed. Unfortunately when it stops the other process a SIGCHLD is sent to the test program which then aborts the waitpid with an exception. Tested with Python 2.1.3, 2.2 and CVS from 2003-02-13 Platform: Debian GNU/Linux, Kernel 2.4.20 ---------------------------------------------------------------------- Comment By: David Hess (david_k_hess) Date: 2006-01-29 19:30 Message: Logged In: YES user_id=896179 Also seen on Mac OS X 10.4.4 (Darwin 8.4.0) with Python 2.4.2. The Zope guys are seeing it too: http://mail.zope.org/pipermail/zope-collector-monitor/2005-December/ 006267.html It seems remarkable that this bug has been open for 3 years. spawn*() are pretty much useless without a fix. Here's patch that works for me: --- /Users/dhess/os.py 2006-01-29 19:29:25.000000000 -0600 +++ /opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/os.py 2006-01-29 19:29:32.000000000 -0600 @@ -532,7 +532,13 @@ if mode == P_NOWAIT: return pid # Caller is responsible for waiting! while 1: - wpid, sts = waitpid(pid, 0) + try: + wpid, sts = waitpid(pid, 0) + except OSError, exc: + import errno + if exc.errno == errno.EINTR: + continue + raise if WIFSTOPPED(sts): continue elif WIFSIGNALED(sts): ---------------------------------------------------------------------- Comment By: Mark Mc Loughlin (markmc) Date: 2005-05-09 07:07 Message: Logged In: YES user_id=116392 Seeing this on Ubuntu with Sabayon (www.gnome.org/projects/sabayon): http://bugzilla.gnome.org/show_bug.cgi?id=303034 Python version is 2.4.1 This is particularily painful because there's no way to get the PID of the process which waitpid was wating on when it was interrupted, so there's no way to reap the child ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=686667&group_id=5470 From noreply at sourceforge.net Mon Jan 30 08:43:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 29 Jan 2006 23:43:56 -0800 Subject: [ python-Bugs-1418374 ] PyRun_SimpleString won't parse \\x Message-ID: Bugs item #1418374, was opened at 2006-01-30 07:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1418374&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: gnupun (gnupun) Assigned to: Nobody/Anonymous (nobody) Summary: PyRun_SimpleString won't parse \\x Initial Comment: I'm trying to use Python 2.4.2 from C on Win XP. The following line of C code generates an error: test.c: PyRun_SimpleString( "s = 'C:\\xyz'\n" ); Output: ValueError: invalid \x escape The error message only occurs if 'x' follows the slashes '\\x'. That is, no other letter causes this problem: PyRun_SimpleString( "s = 'C:\\ayz'\n" ); PyRun_SimpleString( "s = 'C:\\yyz'\n" ); Using forward slashes also prevents the error: PyRun_SimpleString( "s = "C:/xyz'\n" ); // ok ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1418374&group_id=5470 From noreply at sourceforge.net Mon Jan 30 17:16:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 Jan 2006 08:16:45 -0800 Subject: [ python-Bugs-1418374 ] PyRun_SimpleString won't parse \\x Message-ID: Bugs item #1418374, was opened at 2006-01-30 08:43 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1418374&group_id=5470 Please note that this 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: Deleted >Resolution: Invalid Priority: 5 Submitted By: gnupun (gnupun) Assigned to: Nobody/Anonymous (nobody) Summary: PyRun_SimpleString won't parse \\x Initial Comment: I'm trying to use Python 2.4.2 from C on Win XP. The following line of C code generates an error: test.c: PyRun_SimpleString( "s = 'C:\\xyz'\n" ); Output: ValueError: invalid \x escape The error message only occurs if 'x' follows the slashes '\\x'. That is, no other letter causes this problem: PyRun_SimpleString( "s = 'C:\\ayz'\n" ); PyRun_SimpleString( "s = 'C:\\yyz'\n" ); Using forward slashes also prevents the error: PyRun_SimpleString( "s = "C:/xyz'\n" ); // ok ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2006-01-30 17:16 Message: Logged In: YES user_id=38376 > The following line of C code generates an error C uses the same escape rules as Python, so your first test snippet looks like "C:\xyz" to Python. which is is an invalid string literal, just as the message says. see the Python language reference to details on string literal syntax. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1418374&group_id=5470 From noreply at sourceforge.net Tue Jan 31 04:19:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 Jan 2006 19:19:29 -0800 Subject: [ python-Bugs-1419652 ] PyImport_AppendInittab stores pointer to parameter Message-ID: Bugs item #1419652, was opened at 2006-01-31 03:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1419652&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: coder_5 (coder_5) Assigned to: Nobody/Anonymous (nobody) Summary: PyImport_AppendInittab stores pointer to parameter Initial Comment: signature is: int PyImport_AppendInittab(char *name, void (*initfunc)(void)) if the 'name' pointer is freed or overwritten directly after the call to PyImport_AppendInittab, this call returns true but fails making the module known, and the interpreter crashes on PyFinalize(); this suggests that PyImport_AppendInittab stores the name pointer and uses it later, after leaving this function. this is undocumented and leads to crashes if name is freed in the meantime. (a typical c problem) this function is important to boost::python library to extend python with c++. workaround for c/c++ users: -malloc a char* for the name, -copy the modulename to name -call PyImport_AppendInittab with this name -DONT free name. (leaving a memory-leak) btw, 'char *' should be 'const char*', but this applies to most other Python API functions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1419652&group_id=5470 From noreply at sourceforge.net Tue Jan 31 08:08:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 30 Jan 2006 23:08:08 -0800 Subject: [ python-Bugs-1419989 ] class dictionary shortcircuits __getattr__ Message-ID: Bugs item #1419989, was opened at 2006-01-31 02:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1419989&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Shaun Cutts (shauncutts) Assigned to: Nobody/Anonymous (nobody) Summary: class dictionary shortcircuits __getattr__ Initial Comment: page 3.3.2 of Language Reference states: "....Note that at least for instance variables, you can fake total control by not inserting any values in the instance attribute dictionary (but instead inserting them in another object)." A counterexample (doctest style): ----------------------------- >>> class Foo: ... bar = None ... def __getattr__( self, attr ): ... return 'boo' ... >>> f = Foo() >>> print "bar: ",f.bar bar: None ------------------------------ 'bar' in class dictionary (not just in instance dictionary) also causes __getattr__ not to be called. BTW.. above in the doc, it says that __getattr__ called only if "normal methods" can't find attribute. So this would seem a documentation bug. However, right now at least, I would prefer if the instance dictionary alone were decisive. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1419989&group_id=5470 From noreply at sourceforge.net Tue Jan 31 14:12:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jan 2006 05:12:51 -0800 Subject: [ python-Bugs-1414673 ] Underspecified behaviour of string methods split, rsplit Message-ID: Bugs item #1414673, was opened at 2006-01-25 10:23 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1414673&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) >Summary: Underspecified behaviour of string methods split, rsplit Initial Comment: The documentation for the string methods split and rsplit do not address the case where sep=None and maxsplit=0. Should this strip off the leading and trailing whitespace, but not do any splits? Should it simply return the invocant string? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1414673&group_id=5470 From noreply at sourceforge.net Tue Jan 31 16:55:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jan 2006 07:55:52 -0800 Subject: [ python-Bugs-1414673 ] Underspecified behaviour of string methods split, rsplit Message-ID: Bugs item #1414673, was opened at 2006-01-25 10:23 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1414673&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) >Assigned to: Raymond Hettinger (rhettinger) Summary: Underspecified behaviour of string methods split, rsplit Initial Comment: The documentation for the string methods split and rsplit do not address the case where sep=None and maxsplit=0. Should this strip off the leading and trailing whitespace, but not do any splits? Should it simply return the invocant string? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1414673&group_id=5470 From noreply at sourceforge.net Tue Jan 31 21:00:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Jan 2006 12:00:11 -0800 Subject: [ python-Bugs-827963 ] Registry key CurrentVersion not set Message-ID: Bugs item #827963, was opened at 2003-10-22 04:54 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827963&group_id=5470 Please note that this 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: Fixed Priority: 6 Submitted By: Jimm Domingo (jimm_domingo) Assigned to: Martin v. L??wis (loewis) Summary: Registry key CurrentVersion not set Initial Comment: According to the documentation for Python's use of the Windows registry, the version number of most recently installed version is in the key HKEY_LOCAL_MACHINE\Software\Python\PythonCore\CurrentVersion. But this key does not exist on my system. My configuration: Python 2.2.3 (#42, May 30 2003, 18:12:08) on Windows XP Professional, Version 2002, SP1. FWIW, I downloaded most recent revision (1.133.4.4) of the Wise installation script (python20.wse) from CVS. I then opened it with an evaluation copy of Wise Installation System. I've never used that product, but it appears that the above key isn't assigned a value. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-01-31 21:00 Message: Logged In: YES user_id=21627 This is now fixed on the website. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-12-10 16:49 Message: Logged In: YES user_id=11105 I'm unassigning this, since I neither maintain the python.org web pages nor would I want to. I would suggest to either remove these pages completely, or mark them as hopefully outdated. ---------------------------------------------------------------------- Comment By: Jimm Domingo (jimm_domingo) Date: 2003-12-05 22:16 Message: Logged In: YES user_id=860120 The document "Python Registry" is at http://www.python.org/windows/python/registry.html The page "Python support for Windows" (http://www.python.org/windows/) has a link to that document, but it is classified as an old link. Seems to confirm your thinking that the documentation no longer describes the way things are done. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-12-05 21:52 Message: Logged In: YES user_id=11105 I think this is a documentation bug. Can you point me to where it is documented? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827963&group_id=5470