[ python-Bugs-1377858 ] segfaults when using __del__ and weakrefs
Bugs item #1377858, was opened at 2005-12-10 21:20 Message generated for change (Comment added) made by arigo 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.5 Status: Open Resolution: None Priority: 7 Submitted By: Carl Friedrich Bolz (cfbolz) Assigned to: Michael Hudson (mwh) 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: Armin Rigo (arigo) Date: 2006-08-12 11:31 Message: Logged In: YES user_id=4771 The clear_weakref(*list) only clears the first weakref to the object. You need a while loop in your patch. (attached proposed fix) Now we're left with fixing the same bug in old-style classes (surprize surprize), and turning the crasher into a test. -- Comment By: Brett Cannon (bcannon) Date: 2006-06-29 17:36 Message: Logged In: YES user_id=357491 So after staring at this crasher it seemed to me to be that clearing the new weakrefs w/o calling their finalizers after calling the object's finalizer was the best solution. I couldn't think of any other good way to communicate to the new weakrefs that the object they refer to was no longer viable memory without doing clear_weakref() work by hand. Attached is a patch to do this. Michael, can you have a look? -- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 19:29 Message: Logged In: YES user_id=1188172 Added to outstanding_crashes.py. -- 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 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1539295 ] Long command lines don't work on Windows
Bugs item #1539295, was opened at 2006-08-12 21:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Albert Strasheim (albertstrasheim) Assigned to: Nobody/Anonymous (nobody) Summary: Long command lines don't work on Windows Initial Comment: Windows has a 32k command line limit, described here: http://blogs.msdn.com/oldnewthing/archive/2003/12/10/56028.aspx The SciPy project is running into problems when using distutils to compile LAPACK from source, because the large number of source files results in a command line of more than 70,000 characters. Windows has a way of dealing with this problem, namely putting the command line arguments in a file and passing that file to executable with prepended with an @, i.e. you want to run something like lib.exe @tempdir\tempargs.lnk SCons takes care of this through it's TEMPFILE mechanism which uses the TempFileMunge class which can be perused here: http://scons.tigris.org/source/browse/scons/trunk/src/engine/SCons/Platform/__init__.py?rev=1582&view=markup I think this problem can easily be addressed in distutils by modifying the _spawn_nt method in spawn.py to switch to this temp file method when the command line length exceeds some threshold. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1539295 ] Long command lines don't work on Windows
Bugs item #1539295, was opened at 2006-08-12 12:28 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Albert Strasheim (albertstrasheim) Assigned to: Nobody/Anonymous (nobody) Summary: Long command lines don't work on Windows Initial Comment: Windows has a 32k command line limit, described here: http://blogs.msdn.com/oldnewthing/archive/2003/12/10/56028.aspx The SciPy project is running into problems when using distutils to compile LAPACK from source, because the large number of source files results in a command line of more than 70,000 characters. Windows has a way of dealing with this problem, namely putting the command line arguments in a file and passing that file to executable with prepended with an @, i.e. you want to run something like lib.exe @tempdir\tempargs.lnk SCons takes care of this through it's TEMPFILE mechanism which uses the TempFileMunge class which can be perused here: http://scons.tigris.org/source/browse/scons/trunk/src/engine/SCons/Platform/__init__.py?rev=1582&view=markup I think this problem can easily be addressed in distutils by modifying the _spawn_nt method in spawn.py to switch to this temp file method when the command line length exceeds some threshold. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-12 14:53 Message: Logged In: YES user_id=33168 Albert, could you try to work up a patch implementing this? It would be much more likely to get fixed that way. It should also work with older Windows (9x/ME). Cheers, n -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1539295 ] Long command lines don't work on Windows
Bugs item #1539295, was opened at 2006-08-12 21:28 Message generated for change (Comment added) made by albertstrasheim You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Albert Strasheim (albertstrasheim) Assigned to: Nobody/Anonymous (nobody) Summary: Long command lines don't work on Windows Initial Comment: Windows has a 32k command line limit, described here: http://blogs.msdn.com/oldnewthing/archive/2003/12/10/56028.aspx The SciPy project is running into problems when using distutils to compile LAPACK from source, because the large number of source files results in a command line of more than 70,000 characters. Windows has a way of dealing with this problem, namely putting the command line arguments in a file and passing that file to executable with prepended with an @, i.e. you want to run something like lib.exe @tempdir\tempargs.lnk SCons takes care of this through it's TEMPFILE mechanism which uses the TempFileMunge class which can be perused here: http://scons.tigris.org/source/browse/scons/trunk/src/engine/SCons/Platform/__init__.py?rev=1582&view=markup I think this problem can easily be addressed in distutils by modifying the _spawn_nt method in spawn.py to switch to this temp file method when the command line length exceeds some threshold. -- >Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-12 23:56 Message: Logged In: YES user_id=945096 Okay, I'll see what I can do. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-12 23:53 Message: Logged In: YES user_id=33168 Albert, could you try to work up a patch implementing this? It would be much more likely to get fixed that way. It should also work with older Windows (9x/ME). Cheers, n -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1539336 ] distutils example code missing imports
Bugs item #1539336, was opened at 2006-08-13 00: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=1539336&group_id=5470 Please note that this 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: Albert Strasheim (albertstrasheim) Assigned to: Nobody/Anonymous (nobody) Summary: distutils example code missing imports Initial Comment: The example code in the "Single extension module" section of "Distributing Python Modules" is missing some imports. Both examples should import Extension in addition to setup. Otherwise, the following error results when the examples are executed: NameError: name 'Extension' is not defined There might be similar issues elsewhere in the documentation. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539336&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1539295 ] Long command lines don't work on Windows
Bugs item #1539295, was opened at 2006-08-12 21:28 Message generated for change (Comment added) made by albertstrasheim You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Albert Strasheim (albertstrasheim) Assigned to: Nobody/Anonymous (nobody) Summary: Long command lines don't work on Windows Initial Comment: Windows has a 32k command line limit, described here: http://blogs.msdn.com/oldnewthing/archive/2003/12/10/56028.aspx The SciPy project is running into problems when using distutils to compile LAPACK from source, because the large number of source files results in a command line of more than 70,000 characters. Windows has a way of dealing with this problem, namely putting the command line arguments in a file and passing that file to executable with prepended with an @, i.e. you want to run something like lib.exe @tempdir\tempargs.lnk SCons takes care of this through it's TEMPFILE mechanism which uses the TempFileMunge class which can be perused here: http://scons.tigris.org/source/browse/scons/trunk/src/engine/SCons/Platform/__init__.py?rev=1582&view=markup I think this problem can easily be addressed in distutils by modifying the _spawn_nt method in spawn.py to switch to this temp file method when the command line length exceeds some threshold. -- >Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 02:03 Message: Logged In: YES user_id=945096 Attached a first try at a patch. Some things that could still be changed: - We might want to print a different log info message when using a temp file instead of calling the command directly - Restructure the code so that the spawnv call only appears in one place The setup.py I attached should allow anyone to duplicate this problem. -- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-12 23:56 Message: Logged In: YES user_id=945096 Okay, I'll see what I can do. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-12 23:53 Message: Logged In: YES user_id=33168 Albert, could you try to work up a patch implementing this? It would be much more likely to get fixed that way. It should also work with older Windows (9x/ME). Cheers, n -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1539295 ] Long command lines don't work on Windows
Bugs item #1539295, was opened at 2006-08-12 21:28 Message generated for change (Comment added) made by albertstrasheim You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Albert Strasheim (albertstrasheim) Assigned to: Nobody/Anonymous (nobody) Summary: Long command lines don't work on Windows Initial Comment: Windows has a 32k command line limit, described here: http://blogs.msdn.com/oldnewthing/archive/2003/12/10/56028.aspx The SciPy project is running into problems when using distutils to compile LAPACK from source, because the large number of source files results in a command line of more than 70,000 characters. Windows has a way of dealing with this problem, namely putting the command line arguments in a file and passing that file to executable with prepended with an @, i.e. you want to run something like lib.exe @tempdir\tempargs.lnk SCons takes care of this through it's TEMPFILE mechanism which uses the TempFileMunge class which can be perused here: http://scons.tigris.org/source/browse/scons/trunk/src/engine/SCons/Platform/__init__.py?rev=1582&view=markup I think this problem can easily be addressed in distutils by modifying the _spawn_nt method in spawn.py to switch to this temp file method when the command line length exceeds some threshold. -- >Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 02:09 Message: Logged In: YES user_id=945096 Looks like the max length on Windows 95 might be as low as 256 characters, but I'm not sure about this. It seems Windows 98 and Windows Me have a limit of 2048 characters. SCons assumes 2048 characters on any Windows system, so I did the same. -- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 02:03 Message: Logged In: YES user_id=945096 Attached a first try at a patch. Some things that could still be changed: - We might want to print a different log info message when using a temp file instead of calling the command directly - Restructure the code so that the spawnv call only appears in one place The setup.py I attached should allow anyone to duplicate this problem. -- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-12 23:56 Message: Logged In: YES user_id=945096 Okay, I'll see what I can do. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-12 23:53 Message: Logged In: YES user_id=33168 Albert, could you try to work up a patch implementing this? It would be much more likely to get fixed that way. It should also work with older Windows (9x/ME). Cheers, n -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1539295 ] Long command lines don't work on Windows
Bugs item #1539295, was opened at 2006-08-12 12:28 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Albert Strasheim (albertstrasheim) Assigned to: Nobody/Anonymous (nobody) Summary: Long command lines don't work on Windows Initial Comment: Windows has a 32k command line limit, described here: http://blogs.msdn.com/oldnewthing/archive/2003/12/10/56028.aspx The SciPy project is running into problems when using distutils to compile LAPACK from source, because the large number of source files results in a command line of more than 70,000 characters. Windows has a way of dealing with this problem, namely putting the command line arguments in a file and passing that file to executable with prepended with an @, i.e. you want to run something like lib.exe @tempdir\tempargs.lnk SCons takes care of this through it's TEMPFILE mechanism which uses the TempFileMunge class which can be perused here: http://scons.tigris.org/source/browse/scons/trunk/src/engine/SCons/Platform/__init__.py?rev=1582&view=markup I think this problem can easily be addressed in distutils by modifying the _spawn_nt method in spawn.py to switch to this temp file method when the command line length exceeds some threshold. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-12 17:16 Message: Logged In: YES user_id=33168 Thanks for the patch! It looks pretty good, but there are a few changes (and additions) I would like to see. I don't understand why you use 2k in the patch, but mention the limit is 32k. You should use mkstemp() instead of mktemp(). That will open the file for you, so you can just do os.write(fd, data). You will need to close the file. I would prefer to see a single os.spawnv() call. You would need tmp defined (but possibly None) and in the finally, you would have to check if tmp: os.remove(). It would also be nice to see test and doc updates. The tests are in Lib/distutils/tests. Thanks again for the patch. -- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-12 17:09 Message: Logged In: YES user_id=945096 Looks like the max length on Windows 95 might be as low as 256 characters, but I'm not sure about this. It seems Windows 98 and Windows Me have a limit of 2048 characters. SCons assumes 2048 characters on any Windows system, so I did the same. -- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-12 17:03 Message: Logged In: YES user_id=945096 Attached a first try at a patch. Some things that could still be changed: - We might want to print a different log info message when using a temp file instead of calling the command directly - Restructure the code so that the spawnv call only appears in one place The setup.py I attached should allow anyone to duplicate this problem. -- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-12 14:56 Message: Logged In: YES user_id=945096 Okay, I'll see what I can do. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-12 14:53 Message: Logged In: YES user_id=33168 Albert, could you try to work up a patch implementing this? It would be much more likely to get fixed that way. It should also work with older Windows (9x/ME). Cheers, n -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1539295 ] Long command lines don't work on Windows
Bugs item #1539295, was opened at 2006-08-12 12:28 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Albert Strasheim (albertstrasheim) Assigned to: Nobody/Anonymous (nobody) Summary: Long command lines don't work on Windows Initial Comment: Windows has a 32k command line limit, described here: http://blogs.msdn.com/oldnewthing/archive/2003/12/10/56028.aspx The SciPy project is running into problems when using distutils to compile LAPACK from source, because the large number of source files results in a command line of more than 70,000 characters. Windows has a way of dealing with this problem, namely putting the command line arguments in a file and passing that file to executable with prepended with an @, i.e. you want to run something like lib.exe @tempdir\tempargs.lnk SCons takes care of this through it's TEMPFILE mechanism which uses the TempFileMunge class which can be perused here: http://scons.tigris.org/source/browse/scons/trunk/src/engine/SCons/Platform/__init__.py?rev=1582&view=markup I think this problem can easily be addressed in distutils by modifying the _spawn_nt method in spawn.py to switch to this temp file method when the command line length exceeds some threshold. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-12 17:17 Message: Logged In: YES user_id=33168 Ah, our msgs crossed. That explains the 2k. It would be nice to add a comment about that. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-12 17:16 Message: Logged In: YES user_id=33168 Thanks for the patch! It looks pretty good, but there are a few changes (and additions) I would like to see. I don't understand why you use 2k in the patch, but mention the limit is 32k. You should use mkstemp() instead of mktemp(). That will open the file for you, so you can just do os.write(fd, data). You will need to close the file. I would prefer to see a single os.spawnv() call. You would need tmp defined (but possibly None) and in the finally, you would have to check if tmp: os.remove(). It would also be nice to see test and doc updates. The tests are in Lib/distutils/tests. Thanks again for the patch. -- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-12 17:09 Message: Logged In: YES user_id=945096 Looks like the max length on Windows 95 might be as low as 256 characters, but I'm not sure about this. It seems Windows 98 and Windows Me have a limit of 2048 characters. SCons assumes 2048 characters on any Windows system, so I did the same. -- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-12 17:03 Message: Logged In: YES user_id=945096 Attached a first try at a patch. Some things that could still be changed: - We might want to print a different log info message when using a temp file instead of calling the command directly - Restructure the code so that the spawnv call only appears in one place The setup.py I attached should allow anyone to duplicate this problem. -- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-12 14:56 Message: Logged In: YES user_id=945096 Okay, I'll see what I can do. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-12 14:53 Message: Logged In: YES user_id=33168 Albert, could you try to work up a patch implementing this? It would be much more likely to get fixed that way. It should also work with older Windows (9x/ME). Cheers, n -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1539336 ] distutils example code missing imports
Bugs item #1539336, was opened at 2006-08-12 15:30 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539336&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation >Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Albert Strasheim (albertstrasheim) >Assigned to: Neal Norwitz (nnorwitz) Summary: distutils example code missing imports Initial Comment: The example code in the "Single extension module" section of "Distributing Python Modules" is missing some imports. Both examples should import Extension in addition to setup. Otherwise, the following error results when the examples are executed: NameError: name 'Extension' is not defined There might be similar issues elsewhere in the documentation. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-12 17:21 Message: Logged In: YES user_id=33168 Thanks! Committed revision 51240. Let us know if you find other places in the doc that are wrong. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539336&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1539295 ] Long command lines don't work on Windows
Bugs item #1539295, was opened at 2006-08-12 21:28 Message generated for change (Comment added) made by albertstrasheim You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Albert Strasheim (albertstrasheim) Assigned to: Nobody/Anonymous (nobody) Summary: Long command lines don't work on Windows Initial Comment: Windows has a 32k command line limit, described here: http://blogs.msdn.com/oldnewthing/archive/2003/12/10/56028.aspx The SciPy project is running into problems when using distutils to compile LAPACK from source, because the large number of source files results in a command line of more than 70,000 characters. Windows has a way of dealing with this problem, namely putting the command line arguments in a file and passing that file to executable with prepended with an @, i.e. you want to run something like lib.exe @tempdir\tempargs.lnk SCons takes care of this through it's TEMPFILE mechanism which uses the TempFileMunge class which can be perused here: http://scons.tigris.org/source/browse/scons/trunk/src/engine/SCons/Platform/__init__.py?rev=1582&view=markup I think this problem can easily be addressed in distutils by modifying the _spawn_nt method in spawn.py to switch to this temp file method when the command line length exceeds some threshold. -- >Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 02:44 Message: Logged In: YES user_id=945096 Okay, I'm going to try to implement some of your suggestions. A comment at the top of spawn.py says: # This module should be kept compatible with Python 2.1. but mkstemp was only added in Python 2.3. Is this comment still valid? -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-13 02:17 Message: Logged In: YES user_id=33168 Ah, our msgs crossed. That explains the 2k. It would be nice to add a comment about that. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-13 02:16 Message: Logged In: YES user_id=33168 Thanks for the patch! It looks pretty good, but there are a few changes (and additions) I would like to see. I don't understand why you use 2k in the patch, but mention the limit is 32k. You should use mkstemp() instead of mktemp(). That will open the file for you, so you can just do os.write(fd, data). You will need to close the file. I would prefer to see a single os.spawnv() call. You would need tmp defined (but possibly None) and in the finally, you would have to check if tmp: os.remove(). It would also be nice to see test and doc updates. The tests are in Lib/distutils/tests. Thanks again for the patch. -- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 02:09 Message: Logged In: YES user_id=945096 Looks like the max length on Windows 95 might be as low as 256 characters, but I'm not sure about this. It seems Windows 98 and Windows Me have a limit of 2048 characters. SCons assumes 2048 characters on any Windows system, so I did the same. -- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 02:03 Message: Logged In: YES user_id=945096 Attached a first try at a patch. Some things that could still be changed: - We might want to print a different log info message when using a temp file instead of calling the command directly - Restructure the code so that the spawnv call only appears in one place The setup.py I attached should allow anyone to duplicate this problem. -- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-12 23:56 Message: Logged In: YES user_id=945096 Okay, I'll see what I can do. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-12 23:53 Message: Logged In: YES user_id=33168 Albert, could you try to work up a patch implementing this? It would be much more likely to get fixed that way. It should also work with older Windows (9x/ME). Cheers, n -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1539295 ] Long command lines don't work on Windows
Bugs item #1539295, was opened at 2006-08-12 21:28 Message generated for change (Comment added) made by albertstrasheim You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Albert Strasheim (albertstrasheim) Assigned to: Nobody/Anonymous (nobody) Summary: Long command lines don't work on Windows Initial Comment: Windows has a 32k command line limit, described here: http://blogs.msdn.com/oldnewthing/archive/2003/12/10/56028.aspx The SciPy project is running into problems when using distutils to compile LAPACK from source, because the large number of source files results in a command line of more than 70,000 characters. Windows has a way of dealing with this problem, namely putting the command line arguments in a file and passing that file to executable with prepended with an @, i.e. you want to run something like lib.exe @tempdir\tempargs.lnk SCons takes care of this through it's TEMPFILE mechanism which uses the TempFileMunge class which can be perused here: http://scons.tigris.org/source/browse/scons/trunk/src/engine/SCons/Platform/__init__.py?rev=1582&view=markup I think this problem can easily be addressed in distutils by modifying the _spawn_nt method in spawn.py to switch to this temp file method when the command line length exceeds some threshold. -- >Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 03:51 Message: Logged In: YES user_id=945096 New patch. Included a test case that fails without the changes and passes with the changes. Modified the code to incorporate some of nnorwitz's suggestions, except for the mkstemp change. The test case has a minor bug: the output of the build is still created relative to the the current working directory. I don't know distutils very well, so I'm not quite sure which option to mangle to fix this. -- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 02:44 Message: Logged In: YES user_id=945096 Okay, I'm going to try to implement some of your suggestions. A comment at the top of spawn.py says: # This module should be kept compatible with Python 2.1. but mkstemp was only added in Python 2.3. Is this comment still valid? -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-13 02:17 Message: Logged In: YES user_id=33168 Ah, our msgs crossed. That explains the 2k. It would be nice to add a comment about that. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-13 02:16 Message: Logged In: YES user_id=33168 Thanks for the patch! It looks pretty good, but there are a few changes (and additions) I would like to see. I don't understand why you use 2k in the patch, but mention the limit is 32k. You should use mkstemp() instead of mktemp(). That will open the file for you, so you can just do os.write(fd, data). You will need to close the file. I would prefer to see a single os.spawnv() call. You would need tmp defined (but possibly None) and in the finally, you would have to check if tmp: os.remove(). It would also be nice to see test and doc updates. The tests are in Lib/distutils/tests. Thanks again for the patch. -- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 02:09 Message: Logged In: YES user_id=945096 Looks like the max length on Windows 95 might be as low as 256 characters, but I'm not sure about this. It seems Windows 98 and Windows Me have a limit of 2048 characters. SCons assumes 2048 characters on any Windows system, so I did the same. -- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 02:03 Message: Logged In: YES user_id=945096 Attached a first try at a patch. Some things that could still be changed: - We might want to print a different log info message when using a temp file instead of calling the command directly - Restructure the code so that the spawnv call only appears in one place The setup.py I attached should allow anyone to duplicate this problem. -- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-12 23:56 Message: Logged In: YES user_id=945096 Okay, I'll see what I can do. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-12 23:53 Message: Logged In: YES user_id=
[ python-Bugs-1539295 ] Long command lines don't work on Windows
Bugs item #1539295, was opened at 2006-08-12 21:28 Message generated for change (Comment added) made by albertstrasheim You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Albert Strasheim (albertstrasheim) Assigned to: Nobody/Anonymous (nobody) Summary: Long command lines don't work on Windows Initial Comment: Windows has a 32k command line limit, described here: http://blogs.msdn.com/oldnewthing/archive/2003/12/10/56028.aspx The SciPy project is running into problems when using distutils to compile LAPACK from source, because the large number of source files results in a command line of more than 70,000 characters. Windows has a way of dealing with this problem, namely putting the command line arguments in a file and passing that file to executable with prepended with an @, i.e. you want to run something like lib.exe @tempdir\tempargs.lnk SCons takes care of this through it's TEMPFILE mechanism which uses the TempFileMunge class which can be perused here: http://scons.tigris.org/source/browse/scons/trunk/src/engine/SCons/Platform/__init__.py?rev=1582&view=markup I think this problem can easily be addressed in distutils by modifying the _spawn_nt method in spawn.py to switch to this temp file method when the command line length exceeds some threshold. -- >Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 04:16 Message: Logged In: YES user_id=945096 On further testing it seems this patch is a bit overzealous. The @ magic doesn't work for Windows commands in general. :-( -- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 03:51 Message: Logged In: YES user_id=945096 New patch. Included a test case that fails without the changes and passes with the changes. Modified the code to incorporate some of nnorwitz's suggestions, except for the mkstemp change. The test case has a minor bug: the output of the build is still created relative to the the current working directory. I don't know distutils very well, so I'm not quite sure which option to mangle to fix this. -- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 02:44 Message: Logged In: YES user_id=945096 Okay, I'm going to try to implement some of your suggestions. A comment at the top of spawn.py says: # This module should be kept compatible with Python 2.1. but mkstemp was only added in Python 2.3. Is this comment still valid? -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-13 02:17 Message: Logged In: YES user_id=33168 Ah, our msgs crossed. That explains the 2k. It would be nice to add a comment about that. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-13 02:16 Message: Logged In: YES user_id=33168 Thanks for the patch! It looks pretty good, but there are a few changes (and additions) I would like to see. I don't understand why you use 2k in the patch, but mention the limit is 32k. You should use mkstemp() instead of mktemp(). That will open the file for you, so you can just do os.write(fd, data). You will need to close the file. I would prefer to see a single os.spawnv() call. You would need tmp defined (but possibly None) and in the finally, you would have to check if tmp: os.remove(). It would also be nice to see test and doc updates. The tests are in Lib/distutils/tests. Thanks again for the patch. -- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 02:09 Message: Logged In: YES user_id=945096 Looks like the max length on Windows 95 might be as low as 256 characters, but I'm not sure about this. It seems Windows 98 and Windows Me have a limit of 2048 characters. SCons assumes 2048 characters on any Windows system, so I did the same. -- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 02:03 Message: Logged In: YES user_id=945096 Attached a first try at a patch. Some things that could still be changed: - We might want to print a different log info message when using a temp file instead of calling the command directly - Restructure the code so that the spawnv call only appears in one place The setup.py I attached should allow anyone to duplicate this problem. --
[ python-Bugs-1437785 ] Problems w/ expat 1.95.7 vs. Python 2.4
Bugs item #1437785, was opened at 2006-02-23 15:59 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437785&group_id=5470 Please note that this 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: Closed Resolution: Fixed Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Problems w/ expat 1.95.7 vs. Python 2.4 Initial Comment: This may apply to the trunk as well... Today I finished installing 2.4.2 and all our local libraries at work. Trying out the main application I use I discovered Python segfaulting when trying to import pyexpat. It turned out that during the import an earlier module (gtk.glade) also wanted libexpat. Apparently pyexpat was expecting to get Expat 1.95.8 (what's delivered with Python) but got 1.95.7 instead (what we had installed and what was already linked with all our other Expat-using code). The solution was rather simple. I just commented out those constants in the pyexpat initialization that were marked as 1.95.8. Fortunately there was a comment identifying the version dependency. Is there some way that Python's build process can detect the Expat version and conditionally include/exclude bits that are for later versions? -- >Comment By: SourceForge Robot (sf-robot) Date: 2006-08-12 19:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Georg Brandl (gbrandl) Date: 2006-07-29 03:41 Message: Logged In: YES user_id=849994 Should be fixed by patch #1295808. -- Comment By: Skip Montanaro (montanaro) Date: 2006-03-03 12:15 Message: Logged In: YES user_id=44345 Martin, I'm sorry. If I understood it better I'd explain it better. Tell me if this helps. We have expat 1.95.7 installed. We have C++ libraries that link with that version and are wrapped for use with Python using SWIG. Python 2.4 comes with 1.95.8. Apparently setup.py finds that and compiles pyexpat against it. In the pyexpat init function I see this block of constant initialization: /* Added in Expat 1.95.8. */ MYCONST(XML_ERROR_UNDECLARING_PREFIX); MYCONST(XML_ERROR_INCOMPLETE_PE); MYCONST(XML_ERROR_XML_DECL); MYCONST(XML_ERROR_TEXT_DECL); MYCONST(XML_ERROR_PUBLICID); MYCONST(XML_ERROR_SUSPENDED); MYCONST(XML_ERROR_NOT_SUSPENDED); MYCONST(XML_ERROR_ABORTED); MYCONST(XML_ERROR_FINISHED); MYCONST(XML_ERROR_SUSPEND_PE); If they are left in there, Python reliably segfaults at the first of those lines. When I exclude those lines, everything works fine. If I run ldd over pyexpat.so I don't see that libexpat is dynamically linked in: % ldd pyexpat.so libgcc_s.so.1 => /opt/lang/gcc-3.3.2/lib/libgcc_s.so.1 libc.so.1 => /lib/libc.so.1 libm.so.2 => /lib/libm.so.2 I thus have a statically linked version of libexpat 1.95.8 which appears to be exporting symbols: % nm -p pyexpat.so | egrep XML 042312 T XML_DefaultCurrent 042380 T XML_ErrorString 042428 T XML_ExpatVersion 042452 T XML_ExpatVersionInfo 039164 T XML_ExternalEntityParserCreate 042232 T XML_FreeContentModel 040580 T XML_GetBase 041584 T XML_GetBuffer ... Elsewhere I have a C++ library that is dynamically linked to 1.95.7, so I essentially have libexpat linked into the system twice. Does that seem like a reasonable description of our setup? If so, I can understand that trying to use (for example) XML_ERROR_UNDECLARING_PREFIX (which is new to 1.95.8) with symbols from libexpat 1.95.7 might create problems. I don't see how it could cause problems during constant initialization, but it does, quite reliably. You're much more savvy about these things than I am. Maybe you can see how this would happen. How do we tell Python's build process not to use the bundled 1.95.8? My local C++ gurus tell me they are not willing to rebuild everything with 1.95.8 just to make pyexpat happy. If we tell it that, then those constant initialization lines need to be conditionally exposed to the compiler so that it works to compile with libexpat 1.95.7. -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-03 09:44 Message: Logged In: YES user_id=21627 I don't understand the problem. The build process should have
[ python-Bugs-1246405 ] Segmentation fault when importing expat from xml.parser
Bugs item #1246405, was opened at 2005-07-27 16:07 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246405&group_id=5470 Please note that this 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: Closed Resolution: Fixed Priority: 5 Submitted By: Jean-Pierre (jean-pierre24) Assigned to: Nobody/Anonymous (nobody) Summary: Segmentation fault when importing expat from xml.parser Initial Comment: Hello, I have a strange segmentation fault when importing expat from xml.parsers in the following program (I removed all that is un-necessary to reproduce the bug, which is why the code may look odd). I've also posted this bug on wxPython bug lists because I'm not sure if it's related to Python or wxPython, but anyway the backtrace told me that the segmentation fault occurs when importing expat. import wx import wx.html class MainFrame(wx.Frame): def __init__(self, prnt): wx.Frame.__init__(self, parent=prnt) wx.html.HtmlWindow(wx.Window(self, -1), -1) print "debug 1" from xml.parsers import expat print "debug 2" class BoaApp(wx.App): def OnInit(self): wx.InitAllImageHandlers() MainFrame(None) return True app = BoaApp() The segmentation fault occurs between 'debug 1' and 'debug 2'. If I try to remove anything else, it doesn't happen. I have confirmed the bug on SunOS 5.8, on linux Red Hat Enterprise Server 3 and linux Advanced Server 3. I'm working with Python 2.4.1 and wxPython 2.6.1.0 Here is in attached file, the backtrace from gdb. Feel free to ask me any additional information... -- >Comment By: SourceForge Robot (sf-robot) Date: 2006-08-12 19:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Georg Brandl (gbrandl) Date: 2006-07-29 03:36 Message: Logged In: YES user_id=849994 Patch 1295808 should have fixed this. Can you try it with Python 2.5b2? -- Comment By: Bernhard Herzog (bernhard) Date: 2005-12-01 05:51 Message: Logged In: YES user_id=2369 Could this be the same problem as bug 1075984 ? URL: https://sourceforge.net/tracker/index.php?func=detail&aid=1075984&group_id=5470&atid=105470 -- Comment By: Jean-Pierre (jean-pierre24) Date: 2005-10-06 13:23 Message: Logged In: YES user_id=1247525 Yes I can try with different version of wx, but it will take time. Anyway for today here is in attachment the valgrind output on linux x86. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-04 20:34 Message: Logged In: YES user_id=33168 I don't have the problem with Python 2.3.4 and wx 2.5.5.1. Are you able to try different versions of wxPython? I notice that wx 2.6.2 is available. Are you able to run under valgrind or purify? If you run under valgrind, be sure to specify --suppressions=Misc/valgrind-python.supp The file is in the Python distribution. You can download it through SourceForge ViewCVS. -- Comment By: Jean-Pierre (jean-pierre24) Date: 2005-10-04 15:05 Message: Logged In: YES user_id=1247525 Link is : http://sourceforge.net/tracker/index.php?func=detail&aid=1246397&group_id=9863&atid=109863 Unfortunately, absolutely nothing has happened since I reported the bug. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-03 22:10 Message: Logged In: YES user_id=33168 Can you provide a link to the wx bug report? Has anything happend with it? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246405&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1075984 ] Memory fault pyexpat.so on SGI
Bugs item #1075984, was opened at 2004-11-30 05:13
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470
Please note that this 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: Closed
Resolution: Fixed
Priority: 5
Submitted By: Maik Hertha (mhertha)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Memory fault pyexpat.so on SGI
Initial Comment:
I build the latest RC1 of python 2.4.
System SGI Fuel IP35, Irix 6.5.26m
cc -version
MIPSpro Compilers: Version 7.3.1.3m
- make tests passes test_pyexpat without error
- running this code leads to a core dump
-- code ---
import xml.dom.minidom
doc = xml.dom.minidom.parseString(fstream)
<<< core dump >>>
--- runing python -v test.py
#
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
matches
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.py
import xml.dom.expatbuilder # precompiled from
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
import xml.parsers # directory
/opt/python24c1/lib/python2.4/xml/parsers
#
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
matches
/opt/python24c1/lib/python2.4/xml/parsers/__init__.py
import xml.parsers # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
# /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
matches /opt/python24c1/lib/python2.4/xml/parsers/expat.py
import xml.parsers.expat # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
dlopen("/opt/python24c1/lib/python2.4/lib-dynload/pyexpat.so",
2);
Memory fault(coredump)
- running this code from an interactive session leads
not to a coredump
I need some assistance howto provide further debug
information.
--maik./
--
>Comment By: SourceForge Robot (sf-robot)
Date: 2006-08-12 19:20
Message:
Logged In: YES
user_id=1312539
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-07-29 03:39
Message:
Logged In: YES
user_id=849994
This should be addressed by patch #1295808.
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-10-02 01:24
Message:
Logged In: YES
user_id=21627
I think the problem will occur whenever somebody loads
libexpat.so with dlopen and RTLD_GLOBAL. IMO, this should be
avoided. I can't see in which of these different reports
this really is the case, but in those cases, this much looks
like a third-party bug.
If you import pyexpat first, it looks fine, since it will
resolve the symbols against its own copy, without exporting
them. Then, the later usage of libexpat cannot mistakenly go
into pyexpat because Python loaded this with RTLD_LOCAL.
However, it still may crash later when symbols are resolved
lazily, as more expat symbols might be needed when using
pyexpat, so different symbols might go to different libraries.
Linking pyexpat with -Bsymbolic (where available) should
also solve the problem.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-29 23:01
Message:
Logged In: YES
user_id=33168
The problem seems to be related (same?) as bug #1295808.
Does the patch there fix these problems?
--
Comment By: Steve Juranich (sjuranic)
Date: 2005-07-19 09:22
Message:
Logged In: YES
user_id=1315245
FWIW, this same problem crops up when using Python & VTK
together (which also ships with its own version of expat).
bos's workaround will make things work, though.
--
Comment By: Bernhard Herzog (bernhard)
Date: 2005-03-29 10:11
Message:
Logged In: YES
user_id=2369
I ran into this problem as well on a debian GNU/Linux system
on x86 hardware. It occurs both with pygtk 2.4 and wxPython
2.5 both built against gtk 2.4.
bos' patch at least solves the immediate problem of the
segmentation fault. It may be a good idea to print a
warning message if some of the error codes cannot be
translated to strings, though.
--
Comment By: Bryan O'Sullivan (bos)
Date: 2005-02-04 15:16
Message:
Logged In: YES
user_id=28380
With the GNU linker, you can pass in -Bstatic to force it to resolve the
symbols in the local shared library, instead of globally. This also works on
Irix. I don't know about other Unixes.
---
[ python-Bugs-1465014 ] CSV regression in 2.5a1: multi-line cells
Bugs item #1465014, was opened at 2006-04-05 08:14 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Skip Montanaro (montanaro) Summary: CSV regression in 2.5a1: multi-line cells Initial Comment: Running the attached csv_test.py under Python 2.4.2 (Windows XP SP1) produces: >c:\apps\python24\python.exe ./csv_test.py ['one', '2', 'three (line 1)\n(line 2)'] Note that the third item in the row contains a newline between "(line 1)" and "(line 2)". With Python 2.5a1, I get: >c:\apps\python25\python.exe ./csv_test.py ['one', '2', 'three (line 1)(line 2)'] Notice the missing newline, which is significant. The CSV module under 2.5a1 seems to lose data. -- >Comment By: SourceForge Robot (sf-robot) Date: 2006-08-12 19:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Andrew McNamara (andrewmcnamara) Date: 2006-07-30 21:14 Message: Logged In: YES user_id=698599 Yep, your changes are reasonable. I considered adding an example, but couldn't think of anything that illustrated the point without confusing the reader further. -- Comment By: Skip Montanaro (montanaro) Date: 2006-07-30 20:13 Message: Logged In: YES user_id=44345 I'll see your 50993 and raise you a 50998. Just minor tweaks. Hopefully we can close this puppy, though a small example to make the idea concrete might be worthwhile. -- Comment By: Andrew McNamara (andrewmcnamara) Date: 2006-07-30 19:41 Message: Logged In: YES user_id=698599 I've changed the comment again in changeset 50993 - hopefully this attempt describes the difference more fully. Let me know what you think. -- Comment By: Skip Montanaro (montanaro) Date: 2006-07-29 13:07 Message: Logged In: YES user_id=44345 I checked in a change to libcsv.tex (revision 50953). It adds a versionchanged bit to the reader doc that explains why the behavior changed in 2.5. Andrew & Andrew, please check my work. Sorry for the delay taking care of this. Skip -- Comment By: A.M. Kuchling (akuchling) Date: 2006-07-29 10:24 Message: Logged In: YES user_id=11375 I looked at this bug report, but I have no idea of exactly what behaviour has changed or what needs to be described. -- Comment By: Andrew McNamara (andrewmcnamara) Date: 2006-06-22 20:34 Message: Logged In: YES user_id=698599 Yep, your point about adding a comment to the documentation is fair. Skip, do you want to take my words and massage them into a form suitable for the docs? -- Comment By: David Goodger (goodger) Date: 2006-06-22 20:13 Message: Logged In: YES user_id=7733 I didn't realize that the previous behavior was buggy; I thought that the current behavior was a side-effect. The 2.5 behavior did cause a small problem in Docutils, but it's already been fixed. I just wanted to ensure that no regression was creeping in to 2.5. Thanks for the explanation! Perhaps it could be added to the docs in some form? Marking the bug report closed. -- Comment By: Andrew McNamara (andrewmcnamara) Date: 2006-06-22 17:27 Message: Logged In: YES user_id=698599 The previous behaviour caused considerable problems, particularly on platforms that did not use the unix line- ending conventions, or with files that originated on those platforms - users were finding mysterious newlines where they didn't expect them. Quoted fields exist to allow characters that would otherwise be considered part of the syntax to appear within the field. So yes, quoted fields are a special case, and necessarily so. The current behaviour puts the control back in the hands of the user of the module: if literal newlines are important within a field, they need to read their file in a way that preserves the newlines. The old behaviour would introduce spurious chara
