From noreply@sourceforge.net Mon Jan 1 18:03:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Jan 2001 10:03:24 -0800 Subject: [Python-bugs-list] [Bug #125610] SuppReq: please elaborate on your email notif. requests Message-ID: Bug #125610, was updated on 2000-Dec-13 05:34 Here is a current snapshot of the bug. Project: Python Category: None Status: Closed Resolution: None Bug Group: Not a Bug Priority: 5 Submitted by: pfalcon Assigned to : gvanrossum Summary: SuppReq: please elaborate on your email notif. requests Details: We've got the task "Python requests" http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=22577&group_id=1&group_project_id=2 . I believe bigdisk knows what that means but I think I could do that faster, so I'd like to have information from the original source. Please give specific examples how you want it to be. Thanks. Follow-Ups: Date: 2001-Jan-01 10:03 By: gvanrossum Comment: Thanks. The line wrapping looks great! - Change trace: I'd like to see the *event* that triggered the mail somehow indicated. I don[t care in what form you do that. I agree that the whole change history is the wrong thing to carry in the email. - Specific#: I also want this for Patches (and a text search for patches would be great too of course). ------------------------------------------------------- Date: 2000-Dec-30 08:30 By: pfalcon Comment: I just wanted to let you know that these recommendation are being worked on. Email wrapping went live with pre-Xmas sync, and patch for clickable submitter/assignee names in all tools has been submitted. I'll do changes highlighting after holidays. I think that carrying along all the change trace (as on the web) will be not exactly what most people would want, so I have an idea to make just latest changes highlighted (specifically, quoting corresponding lines in email). If it won't be what you want, please tell me. I totally agree about querying bugs by specific #. I consider fully obvious and intuitive to use search box for that - after all, that's also *search*. And searching stuff is in my scope, so I'll go for that too ;-) . Happy New Year! ------------------------------------------------------- Date: 2000-Dec-18 14:39 By: gvanrossum Comment: Closing this now -- send mail to guido@python.org if you need more help. ;-) ------------------------------------------------------- Date: 2000-Dec-13 08:27 By: gvanrossum Comment: One more thing: it would be really handy if there was a box *somewhere* (maybe in the left margin?) where you could type a bug_id or patch_id and click OK to go directly to the details page of that item. We all need this regularly, and we all use the hack of editing the URL in "Location" field of the browser. There's *got* to be a better way. :-) ------------------------------------------------------- Date: 2000-Dec-13 06:20 By: gvanrossum Comment: OK, I'll clarify. Note that this applies both to the patch and the bugs products. 1. Word wrap: the comments entered in the database for bugs & patches are often entered with a single very long line per paragraph. When the notification email is sent out, most Unix mail readers don't wrap words correctly. The request is to break any line that is longer than 79 characters in shorter pieces, the way e.g. ESC-q does in Emacs, or the fmt(1) program. 2. clickable submitter name: in the patch or bug details page, the submitter ("Submitted By" field) should be a hyperlink to the developer profile for that user (except if it is Nobody, of course). 3. mention what changed in the email: it would be nice if at the top of the notification email it said what caused the mail to be sent, e.g. "status changed from XXX to YYY" or "assiged to ZZZ" or "new comment added by XXX" or "new patch uploaded" or "priority changed to QQQ". If more than one field changed they should all be summarized. Hope this helps! Thanks for doing this. We love our SourceForge! ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=125610&group_id=5470 From noreply@sourceforge.net Mon Jan 1 18:08:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Jan 2001 10:08:11 -0800 Subject: [Python-bugs-list] [Bug #126706] many std modules assume string.letters is [a-zA-Z] Message-ID: Bug #126706, was updated on 2000-Dec-23 06:19 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : nobody Summary: many std modules assume string.letters is [a-zA-Z] Details: there are many modules in the standard library that use string.letters to mean A-Za-z, but that assumption is incorrect when locales are in use. also the readline library seems to cause the locale to be set according to the current environment variables, even if i don't call locale.*: % python2.0 -c 'import string; print string.letters' abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ % python2.0 Python 2.0 (#3, Oct 19 2000, 01:42:41) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Type "copyright", "credits" or "license" for more information. >>> print string.letters abcdefghijklmnopqrstuvwxyzµßàáâãäåæçèéêëìíîïðñòóôõöøùúûüýþÿABCDEFGHIJKLMNOPQRSTUVWXYZÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖØÙÚÛÜÝÞ >>> here's what grep says on the standard library. most of these uses seem incorrect to me: % grep string.letters **/*.py Cookie.py:_LegalChars = string.letters + string.digits + "!#$%&'*+-.^_`|~"cmd.py:IDENTCHARS = string.letters + string.digits + '_' dospath.py: varchars = string.letters + string.digits + '_-' lib-old/codehack.py:identchars = string.letters + string.digits + '_' # Identifier characters ntpath.py: varchars = string.letters + string.digits + '_-' nturl2path.py: if len(comp) != 2 or comp[0][-1] not in string.letters: pipes.py:_safechars = string.letters + string.digits + '!@%_-+=:,./' # Safe unquoted pre.py: alphanum=string.letters+'_'+string.digits tokenize.py: namechars, numchars = string.letters + '_', string.digits urlparse.py:scheme_chars = string.letters + string.digits + '+-.' Follow-Ups: Date: 2001-Jan-01 10:08 By: lemburg Comment: The comment about readline calling setlocale() is unfortunately true (and causes some very subtle bugs in user code...). About the addition of more constants: I would rather like to see a database for these things which uses function calls much like the Unicode database (unicodedata). Since locales sometime matter, I think there should be an option to the functions which enables locale support (much like as for REs) on request. Default should be no locale support, since this is what most code expects anyway. ------------------------------------------------------- Date: 2000-Dec-30 19:36 By: akuchling Comment: The set of all letters, though, will be commonly used, though maybe we need an alphanumeric constant for A-Za-z0-9 + underscore. I like the .ascii_letters suggestion. ------------------------------------------------------- Date: 2000-Dec-30 18:26 By: fdrake Comment: Andrew, does it make sense to introduce new constants in string for this? It seems that each instance is referring to slightly different specifications or standards (documented or not), so perhaps the constants should be defined locally within each of the modules. This also avoids unnecessary dependencies. ------------------------------------------------------- Date: 2000-Dec-26 12:18 By: nobody Comment: string.ascii_letters etc is more precise than alphabet, imho. -- erno@iki.fi ------------------------------------------------------- Date: 2000-Dec-26 08:15 By: akuchling Comment: The docs for the string module say that, for example, string.lowercase is " A string containing all the characters that are considered lowercase letters." This implies that the strings are locale-aware; code that uses string.lowercase to mean only a-z is therefore in error. (.digits is not locale-aware.) Solution: I'd suggest adding new, not locale-aware, constants. string.alphabet, string.lower_alphabet, string.upper_alphabet, maybe? Code should then be changed to use these new constants. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=126706&group_id=5470 From noreply@sourceforge.net Tue Jan 2 04:37:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Jan 2001 20:37:07 -0800 Subject: [Python-bugs-list] [Bug #127259] New re breaks on some '*?' matches Message-ID: Bug #127259, was updated on 2001-Jan-01 20:37 Here is a current snapshot of the bug. Project: Python Category: Regular Expressions Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : nobody Summary: New re breaks on some '*?' matches Details: New python library: Python 2.0 (#2, Nov 29 2000, 07:33:50) [GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import re >>> re.match("a[ ]*?\ (\d+)", "a 10") >>> re.match("a[ ]*?\ (\d+)", "a 10") Old python library: Python 1.5.2 (#1, Aug 25 2000, 09:33:37) [GCC 2.96 20000731 (experimental)] on linux-i386 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import re >>> re.match("a[ ]*?\ (\d+)", "a 10") >>> re.match("a[ ]*?\ (\d+)", "a 10") >>> I see no reason why the second line should not match. (IE. the old regular expression library seems correct to me.) Ok, "so don't do that" - well I encountered it in code that autogenerates regular expressions, so it isn't so easy to always avoid. Besides, it doesn't look correct to me. Thanks, -Kevin (kevoc@bellatlantic.net) For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127259&group_id=5470 From noreply@sourceforge.net Tue Jan 2 05:20:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Jan 2001 21:20:20 -0800 Subject: [Python-bugs-list] [Bug #127259] New re breaks on some '*?' matches Message-ID: Bug #127259, was updated on 2001-Jan-01 20:37 Here is a current snapshot of the bug. Project: Python Category: Regular Expressions Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : effbot Summary: New re breaks on some '*?' matches Details: New python library: Python 2.0 (#2, Nov 29 2000, 07:33:50) [GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import re >>> re.match("a[ ]*?\ (\d+)", "a 10") >>> re.match("a[ ]*?\ (\d+)", "a 10") Old python library: Python 1.5.2 (#1, Aug 25 2000, 09:33:37) [GCC 2.96 20000731 (experimental)] on linux-i386 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import re >>> re.match("a[ ]*?\ (\d+)", "a 10") >>> re.match("a[ ]*?\ (\d+)", "a 10") >>> I see no reason why the second line should not match. (IE. the old regular expression library seems correct to me.) Ok, "so don't do that" - well I encountered it in code that autogenerates regular expressions, so it isn't so easy to always avoid. Besides, it doesn't look correct to me. Thanks, -Kevin (kevoc@bellatlantic.net) Follow-Ups: Date: 2001-Jan-01 21:20 By: tim_one Comment: Reproduced and assigned to /F. Agree it's a bug. Also agree you shouldn't do that . SourceForge's treatment of whitespace is maddening. Note that there *should* be 3 blanks in "a 10" (first example) but 4 in "a 10" (second, failing example). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127259&group_id=5470 From noreply@sourceforge.net Tue Jan 2 10:53:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jan 2001 02:53:06 -0800 Subject: [Python-bugs-list] [Bug #127271] parser module tuple2ast cannot handle node type 280 Message-ID: Bug #127271, was updated on 2001-Jan-02 02:53 Here is a current snapshot of the bug. Project: Python Category: Parser/Compiler Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: pearu Assigned to : nobody Summary: parser module tuple2ast cannot handle node type 280 Details: The following Python session illustrates the bug: >>> import parser >>> parser.tuple2ast((parser.suite('import sys,math')).totuple()) Traceback (most recent call last): File "", line 1, in ? parser.ParserError: Expected node type 280, got 279. >>> parser.tuple2ast((parser.suite('import sys\nimport math')).totuple()) For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127271&group_id=5470 From noreply@sourceforge.net Tue Jan 2 11:13:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jan 2001 03:13:54 -0800 Subject: [Python-bugs-list] [Bug #127273] Documentation of 'long' function is wrong Message-ID: Bug #127273, was updated on 2001-Jan-02 03:13 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: jribbens Assigned to : nobody Summary: Documentation of 'long' function is wrong Details: It appears that in Python 2.0, the built-in function 'long' has been improved to allow a radix parameter. This is not listed in the documentation (Library Reference). It is quite important that it is, because with the string.atol function being deprecated I don't think there is any other way to parse a hex string. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127273&group_id=5470 From noreply@sourceforge.net Tue Jan 2 13:23:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jan 2001 05:23:54 -0800 Subject: [Python-bugs-list] [Bug #127259] New re breaks on some '*?' matches Message-ID: Bug #127259, was updated on 2001-Jan-01 20:37 Here is a current snapshot of the bug. Project: Python Category: Regular Expressions Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : effbot Summary: New re breaks on some '*?' matches Details: New python library: Python 2.0 (#2, Nov 29 2000, 07:33:50) [GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import re >>> re.match("a[ ]*?\ (\d+)", "a 10") >>> re.match("a[ ]*?\ (\d+)", "a 10") Old python library: Python 1.5.2 (#1, Aug 25 2000, 09:33:37) [GCC 2.96 20000731 (experimental)] on linux-i386 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import re >>> re.match("a[ ]*?\ (\d+)", "a 10") >>> re.match("a[ ]*?\ (\d+)", "a 10") >>> I see no reason why the second line should not match. (IE. the old regular expression library seems correct to me.) Ok, "so don't do that" - well I encountered it in code that autogenerates regular expressions, so it isn't so easy to always avoid. Besides, it doesn't look correct to me. Thanks, -Kevin (kevoc@bellatlantic.net) Follow-Ups: Date: 2001-Jan-02 05:23 By: gvanrossum Comment: Also note that if you increase the number of spaces between 'a' and '10', sre gives a match for an odd number of spaces only. ------------------------------------------------------- Date: 2001-Jan-01 21:20 By: tim_one Comment: Reproduced and assigned to /F. Agree it's a bug. Also agree you shouldn't do that . SourceForge's treatment of whitespace is maddening. Note that there *should* be 3 blanks in "a 10" (first example) but 4 in "a 10" (second, failing example). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127259&group_id=5470 From noreply@sourceforge.net Tue Jan 2 13:58:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jan 2001 05:58:16 -0800 Subject: [Python-bugs-list] [Bug #127271] parser module tuple2ast cannot handle node type 280 Message-ID: Bug #127271, was updated on 2001-Jan-02 02:53 Here is a current snapshot of the bug. Project: Python Category: Parser/Compiler Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: pearu Assigned to : fdrake Summary: parser module tuple2ast cannot handle node type 280 Details: The following Python session illustrates the bug: >>> import parser >>> parser.tuple2ast((parser.suite('import sys,math')).totuple()) Traceback (most recent call last): File "", line 1, in ? parser.ParserError: Expected node type 280, got 279. >>> parser.tuple2ast((parser.suite('import sys\nimport math')).totuple()) For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127271&group_id=5470 From noreply@sourceforge.net Tue Jan 2 13:58:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jan 2001 05:58:54 -0800 Subject: [Python-bugs-list] [Bug #127273] Documentation of 'long' function is wrong Message-ID: Bug #127273, was updated on 2001-Jan-02 03:13 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: jribbens Assigned to : fdrake Summary: Documentation of 'long' function is wrong Details: It appears that in Python 2.0, the built-in function 'long' has been improved to allow a radix parameter. This is not listed in the documentation (Library Reference). It is quite important that it is, because with the string.atol function being deprecated I don't think there is any other way to parse a hex string. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127273&group_id=5470 From noreply@sourceforge.net Tue Jan 2 16:00:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jan 2001 08:00:44 -0800 Subject: [Python-bugs-list] [Bug #126345] Modules are not garbage collected Message-ID: Bug #126345, was updated on 2000-Dec-19 07:28 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: loewis Assigned to : nascheme Summary: Modules are not garbage collected Details: Module objects currently don't participate in garbage collection. That is a problem for applications using the new or imp modules to create modules on-the-fly, such as the rexec module. Follow-Ups: Date: 2001-Jan-02 08:00 By: nascheme Comment: Fixed by patch #102939 (moduleobject.c r2.31). ------------------------------------------------------- Date: 2000-Dec-19 08:50 By: gvanrossum Comment: Neil promised to do this over the holidays. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=126345&group_id=5470 From noreply@sourceforge.net Tue Jan 2 16:01:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jan 2001 08:01:10 -0800 Subject: [Python-bugs-list] [Bug #126345] Modules are not garbage collected Message-ID: Bug #126345, was updated on 2000-Dec-19 07:28 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: loewis Assigned to : nascheme Summary: Modules are not garbage collected Details: Module objects currently don't participate in garbage collection. That is a problem for applications using the new or imp modules to create modules on-the-fly, such as the rexec module. Follow-Ups: Date: 2001-Jan-02 08:00 By: nascheme Comment: Fixed by patch #102939 (moduleobject.c r2.31). ------------------------------------------------------- Date: 2000-Dec-19 08:50 By: gvanrossum Comment: Neil promised to do this over the holidays. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=126345&group_id=5470 From noreply@sourceforge.net Tue Jan 2 16:27:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jan 2001 08:27:29 -0800 Subject: [Python-bugs-list] [Bug #127273] Documentation of 'long' function is wrong Message-ID: Bug #127273, was updated on 2001-Jan-02 03:13 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: jribbens Assigned to : fdrake Summary: Documentation of 'long' function is wrong Details: It appears that in Python 2.0, the built-in function 'long' has been improved to allow a radix parameter. This is not listed in the documentation (Library Reference). It is quite important that it is, because with the string.atol function being deprecated I don't think there is any other way to parse a hex string. Follow-Ups: Date: 2001-Jan-02 08:27 By: tim_one Comment: Fred, I see that the current CVS version already documents the radix argument to long(). But both it and the docs for int() say """ If the argument is a string, it must contain a possibly signed decimal number ... """ That's inaccurate now (since the radix argument was added -- it was the truth before the radix argument was allowed). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127273&group_id=5470 From noreply@sourceforge.net Tue Jan 2 16:32:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jan 2001 08:32:28 -0800 Subject: [Python-bugs-list] [Bug #127098] Explanation of try/else in Lang Ref is flawed Message-ID: Bug #127098, was updated on 2000-Dec-29 12:33 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: tim_one Assigned to : fdrake Summary: Explanation of try/else in Lang Ref is flawed Details: Suggested replacement: """ The optional 'else' clause is executed when the 'try' clause terminates by any means other than an exception or executing a 'return', 'continue' or 'break' statement. Exceptions in the 'else' clause are not handled by the prereceding 'except' clauses. """ See Python-Dev for discussion. Follow-Ups: Date: 2001-Jan-02 08:32 By: tim_one Comment: Reopened and reassigned to Fred. Guido agreed to a different wording, and here's my guess at appropriate LaTex: """ The optional \keyword{else} clause is executed if and when control flows off the end of the \keyword{try} clause.\foonote{Currenty, control "flows off the end" except in case of exception, or executing a \keyword{return}, \keyword{continue} or \keyword{break} statement.} Exceptions in the \keyword{else} clause are not handled by the preceding \keyword{except} clauses. """ ------------------------------------------------------- Date: 2000-Dec-31 14:54 By: twouters Comment: Fixed in revision 1.21 of Doc/ref/ref7.tex. ------------------------------------------------------- Date: 2000-Dec-29 12:36 By: tim_one Comment: Except I should have spelled "preceding" correctly. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127098&group_id=5470 From noreply@sourceforge.net Tue Jan 2 17:10:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jan 2001 09:10:41 -0800 Subject: [Python-bugs-list] [Bug #126564] Default of static linking 'bsddb' breaks 3rd party modules Message-ID: Bug #126564, was updated on 2000-Dec-20 22:25 Here is a current snapshot of the bug. Project: Python Category: Build Status: Closed Resolution: Fixed Bug Group: Platform-specific Priority: 5 Submitted by: nobody Assigned to : montanaro Summary: Default of static linking 'bsddb' breaks 3rd party modules Details: Python 2.0 builds the 'bsddb' module into the python interpreter *static* by default. When built this way on systems such as debian potato linux and some versions of redhat linux (to name a few) it links statically with an early BerkeleyDB 2.1.x. This causes problems to the current and under-development bsddb 3.x third party modules. They import but the functions they call are from the wrong library so they often coredump or return unexpected error codes. See the py-bsddb project on sourceforge. Also see http://electricrain.com/greg/python/ for the current stable py-bsddb3 module. Short term solution: Make the default build method for this module *shared* instead of static. Long term solution: the py-bsddb project should be able to replace the old bsddb module in the distribution. Follow-Ups: Date: 2001-Jan-02 09:10 By: montanaro Comment: Made the suggested change to Modules/Setup.config.in - bsddb is now built shared by default. Nothing was done to address the proposed long-term sol'n. ------------------------------------------------------- Date: 2000-Dec-31 10:42 By: montanaro Comment: It's easy enough for me (or someone else) to change "#*shared*" to "*shared*" in Setup.config.in, but how do we know that either won't fix the problem or won't cause other people to have problems? Also, it would be really helpful if people logged in before submitting bugs so the people who try to fix the bugs could correspond with them about the problems they report... Skip ------------------------------------------------------- Date: 2000-Dec-30 18:20 By: fdrake Comment: Lots of the recent work on this is Skip's effort, so he can probably handle this more quickly than the rest of us. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=126564&group_id=5470 From noreply@sourceforge.net Tue Jan 2 17:13:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jan 2001 09:13:20 -0800 Subject: [Python-bugs-list] [Bug #117464] clash with BSD db when building Message-ID: Bug #117464, was updated on 2000-Oct-23 00:29 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: fleury Assigned to : twouters Summary: clash with BSD db when building Details: On RH7.0, beside the LONG_BIT issue, I came across a db.h missmatch. The preprocessor directive values used in bsddbmodule.c correspond to the /usr/include/db1/db.h file, but on my system, /usr/include/db.h points to db3/db.h which does not define the same set of values, and does not compile. Compiling with the old file works, but obviously it does not link... configure (with no options) ran trouble free. The system is: RedHat 7.0 gcc version 2.96 20000731 (yes with the LONG_BIT problem) Python 2.0 final release Regards, Pascal Follow-Ups: Date: 2001-Jan-02 09:13 By: montanaro Comment: Reassigned to Thomas Wouters because I think he has RH7.0. I can't test this directly and haven't had time to investigate. My apologies for waiting so long to slough this off to someone else. ------------------------------------------------------- Date: 2000-Nov-06 08:40 By: montanaro Comment: This is going to require a bit of effort. My current scheme for detecting whether bsddb can be built/linked or not relies on the presence or absence of db.h and/or db_185.h. If db_185.h is present, libdb v.2 is assumed. If only db.h is present, libdb v.1 is assumed. Now Sleepycat has libdb v.3, and on RH7 it appears you can have all three versions installed at once. I don't yet know if bsddbmodule.c can be built/linked with v.3 (seems likely, since db_185.h still existts), but even if it can, configure will have to grovel around in db.h looking for DB_VERSION_MAJOR. If it doesn't exist, we have v.1. If it does exist, its value will determine what version > 1 we have. I imagine for an autoconf whiz this will be a simple task, but it's more of a challenge than I have time for at the moment. Anyone want to take this on? ------------------------------------------------------- Date: 2000-Oct-23 18:13 By: fleury Comment: Well, I also tried at home, where I have a vanilla RH7.0 and it compiles perfectly. The reported bug was on a RH6.2->RH7.0 upgraded machine. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=117464&group_id=5470 From noreply@sourceforge.net Tue Jan 2 17:56:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jan 2001 09:56:18 -0800 Subject: [Python-bugs-list] [Bug #127259] New re breaks on some '*?' matches Message-ID: Bug #127259, was updated on 2001-Jan-01 20:37 Here is a current snapshot of the bug. Project: Python Category: Regular Expressions Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : effbot Summary: New re breaks on some '*?' matches Details: New python library: Python 2.0 (#2, Nov 29 2000, 07:33:50) [GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import re >>> re.match("a[ ]*?\ (\d+)", "a 10") >>> re.match("a[ ]*?\ (\d+)", "a 10") Old python library: Python 1.5.2 (#1, Aug 25 2000, 09:33:37) [GCC 2.96 20000731 (experimental)] on linux-i386 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import re >>> re.match("a[ ]*?\ (\d+)", "a 10") >>> re.match("a[ ]*?\ (\d+)", "a 10") >>> I see no reason why the second line should not match. (IE. the old regular expression library seems correct to me.) Ok, "so don't do that" - well I encountered it in code that autogenerates regular expressions, so it isn't so easy to always avoid. Besides, it doesn't look correct to me. Thanks, -Kevin (kevoc@bellatlantic.net) Follow-Ups: Date: 2001-Jan-02 09:56 By: pearu Comment: Here is another example where new re produces different (incorrect) result compared to Python 1.5.2 re module: Python 1.5.2: >>>re.match(r'(?ms).*?}\s*\Z(?P.*)','{}\012}\012').groupdict() {'rest': ''} Python 2.0: >>>re.match(r'(?ms).*?}\s*\Z(?P.*)','{}\012}\012').groupdict() {'rest': '\012}\012'} which deviates from the definition of \Z: \Z Matches only at the end of the string. Here group 'rest' is used only for illustration, it should always be empty string. tim.one has suspected that this bug could be related to `*?' part. Though it seems to me that \Z meaning is violated here more. Thanks, Pearu ------------------------------------------------------- Date: 2001-Jan-02 05:23 By: gvanrossum Comment: Also note that if you increase the number of spaces between 'a' and '10', sre gives a match for an odd number of spaces only. ------------------------------------------------------- Date: 2001-Jan-01 21:20 By: tim_one Comment: Reproduced and assigned to /F. Agree it's a bug. Also agree you shouldn't do that . SourceForge's treatment of whitespace is maddening. Note that there *should* be 3 blanks in "a 10" (first example) but 4 in "a 10" (second, failing example). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127259&group_id=5470 From noreply@sourceforge.net Tue Jan 2 21:33:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jan 2001 13:33:20 -0800 Subject: [Python-bugs-list] [Bug #126850] file.seek() docs should mention append mode Message-ID: Bug #126850, was updated on 2000-Dec-26 12:06 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : fdrake Summary: file.seek() docs should mention append mode Details: f.seek() does nothing for files opened in 'a' mode (at least on linux). it is mentioned in passing in open() docs, but it should be mentioned in the seek() docs also. Follow-Ups: Date: 2001-Jan-02 13:33 By: fdrake Comment: Now fixed in my working sources, but checkin is blocked on a stale CVS read-lock: http://sourceforge.net/support/?func=detailsupport&support_id=110927&group_id=1 I will close this bug when I can complete the checkin. ------------------------------------------------------- Date: 2000-Dec-26 19:25 By: tim_one Comment: Assigned to Fred. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=126850&group_id=5470 From noreply@sourceforge.net Tue Jan 2 22:09:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jan 2001 14:09:54 -0800 Subject: [Python-bugs-list] [Bug #127151] mkhowto --iconserver doesn't do anything Message-ID: Bug #127151, was updated on 2000-Dec-30 19:35 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: akuchling Assigned to : fdrake Summary: mkhowto --iconserver doesn't do anything Details: The --iconserver option to mkhowto doesn't seem to work. The init file contains a $ICONSERVER='whatever' line, but LaTeX2HTML (the correct version, 99.2b8) seems to just be ignoring the setting. Follow-Ups: Date: 2001-Jan-02 14:09 By: fdrake Comment: This is due to agressive caching of the tags for the icons; fixed in Doc/perl/l2hinit.perl revision 1.51. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127151&group_id=5470 From noreply@sourceforge.net Tue Jan 2 23:39:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jan 2001 15:39:21 -0800 Subject: [Python-bugs-list] [Bug #127259] New re breaks on some '*?' matches Message-ID: Bug #127259, was updated on 2001-Jan-01 20:37 Here is a current snapshot of the bug. Project: Python Category: Regular Expressions Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : effbot Summary: New re breaks on some '*?' matches Details: New python library: Python 2.0 (#2, Nov 29 2000, 07:33:50) [GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import re >>> re.match("a[ ]*?\ (\d+)", "a 10") >>> re.match("a[ ]*?\ (\d+)", "a 10") Old python library: Python 1.5.2 (#1, Aug 25 2000, 09:33:37) [GCC 2.96 20000731 (experimental)] on linux-i386 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import re >>> re.match("a[ ]*?\ (\d+)", "a 10") >>> re.match("a[ ]*?\ (\d+)", "a 10") >>> I see no reason why the second line should not match. (IE. the old regular expression library seems correct to me.) Ok, "so don't do that" - well I encountered it in code that autogenerates regular expressions, so it isn't so easy to always avoid. Besides, it doesn't look correct to me. Thanks, -Kevin (kevoc@bellatlantic.net) Follow-Ups: Date: 2001-Jan-02 15:39 By: nobody Comment: Two bugs in one: Kevin's problem was that SRE didn't always reset the internal string pointer after a failed minimizing tail match. Pearu's problem was that the meaning of \Z was (incorrectly) changed by (?m) -- in other words, \Z behaved like $. Both bugs have been fixed on my box; I'll check them in as soon as I've fixed my CVS install... ------------------------------------------------------- Date: 2001-Jan-02 09:56 By: pearu Comment: Here is another example where new re produces different (incorrect) result compared to Python 1.5.2 re module: Python 1.5.2: >>>re.match(r'(?ms).*?}\s*\Z(?P.*)','{}\012}\012').groupdict() {'rest': ''} Python 2.0: >>>re.match(r'(?ms).*?}\s*\Z(?P.*)','{}\012}\012').groupdict() {'rest': '\012}\012'} which deviates from the definition of \Z: \Z Matches only at the end of the string. Here group 'rest' is used only for illustration, it should always be empty string. tim.one has suspected that this bug could be related to `*?' part. Though it seems to me that \Z meaning is violated here more. Thanks, Pearu ------------------------------------------------------- Date: 2001-Jan-02 05:23 By: gvanrossum Comment: Also note that if you increase the number of spaces between 'a' and '10', sre gives a match for an odd number of spaces only. ------------------------------------------------------- Date: 2001-Jan-01 21:20 By: tim_one Comment: Reproduced and assigned to /F. Agree it's a bug. Also agree you shouldn't do that . SourceForge's treatment of whitespace is maddening. Note that there *should* be 3 blanks in "a 10" (first example) but 4 in "a 10" (second, failing example). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127259&group_id=5470 From noreply@sourceforge.net Tue Jan 2 23:51:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jan 2001 15:51:49 -0800 Subject: [Python-bugs-list] [Bug #125531] sre Scanner.scan typo (?) Message-ID: Bug #125531, was updated on 2000-Dec-12 11:20 Here is a current snapshot of the bug. Project: Python Category: Regular Expressions Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : effbot Summary: sre Scanner.scan typo (?) Details: I believe there's a small glitch in the Scanner.scan method in the sre module (up through ver. 1.25). Here's what the scan method does when it finds a match: if callable(action): self.match = match action = action(self, m.group()) the local variable match in the above is a reference to the match routine from the internal scanner object in the C DLL. I think the intention of the above was probably to set self.match to m -- the Match object returned from the successful search. Follow-Ups: Date: 2001-Jan-02 15:51 By: nobody Comment: The Scanner class is experimental, and wasn't really meant to be in 2.0. I plan to fix all bugs in 2.1 -- but it's up to the python-dev team to decide if it should an official part of Python's RE package. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=125531&group_id=5470 From noreply@sourceforge.net Wed Jan 3 02:14:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jan 2001 18:14:09 -0800 Subject: [Python-bugs-list] [Bug #127361] httplib problem with '100 Continue' Message-ID: Bug #127361, was updated on 2001-Jan-02 18:14 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: dougfort Assigned to : nobody Summary: httplib problem with '100 Continue' Details: I believe there is a bug in httplib IIS 4 and 5 are subject to send an unsolicited result code of '100 Continue' with a couple of headers and a blank line before sending '302 Object Moved'. The 100 response is totally worthless and should be ignored. Unfortunately, httplib.HTTPConnection is unwilling to go back and read more headers when it already has a response object. I was able to get past this with the following kludge: while 1: response = self._client.getresponse() if response.status != 100: break # 2000-12-30 djf -- drop bogus 100 response # by kludging httplib self._client._HTTPConnection__state = httplib._CS_REQ_SENT self._client._HTTPConnection__response = None For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127361&group_id=5470 From noreply@sourceforge.net Wed Jan 3 07:52:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jan 2001 23:52:30 -0800 Subject: [Python-bugs-list] [Bug #127377] bsddb set_location doc clarification Message-ID: Bug #127377, was updated on 2001-Jan-02 23:52 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : nobody Summary: bsddb set_location doc clarification Details: it seems that you can do >>> import bsddb >>> x = bsddb.btopen('/tmp/test.db', 'c') >>> x['foo'] = '42' >>> x['foa'] = '42' >>> x['fox'] = '42' >>> x.set_location('fob') ('foo', '42') ie, set_location returns the *next* matching item from the btree db if no exact match is found. i'm assuming this is intended. this is very useful behaviour, for example when you want to look for keys with a certain prefix, but it is not mentioned in the docs. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127377&group_id=5470 From noreply@sourceforge.net Wed Jan 3 11:50:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Jan 2001 03:50:57 -0800 Subject: [Python-bugs-list] [Bug #127361] httplib problem with '100 Continue' Message-ID: Bug #127361, was updated on 2001-Jan-02 18:14 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: dougfort Assigned to : jhylton Summary: httplib problem with '100 Continue' Details: I believe there is a bug in httplib IIS 4 and 5 are subject to send an unsolicited result code of '100 Continue' with a couple of headers and a blank line before sending '302 Object Moved'. The 100 response is totally worthless and should be ignored. Unfortunately, httplib.HTTPConnection is unwilling to go back and read more headers when it already has a response object. I was able to get past this with the following kludge: while 1: response = self._client.getresponse() if response.status != 100: break # 2000-12-30 djf -- drop bogus 100 response # by kludging httplib self._client._HTTPConnection__state = httplib._CS_REQ_SENT self._client._HTTPConnection__response = None For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127361&group_id=5470 From noreply@sourceforge.net Wed Jan 3 12:02:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Jan 2001 04:02:13 -0800 Subject: [Python-bugs-list] [Bug #127377] bsddb set_location doc clarification Message-ID: Bug #127377, was updated on 2001-Jan-02 23:52 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : fdrake Summary: bsddb set_location doc clarification Details: it seems that you can do >>> import bsddb >>> x = bsddb.btopen('/tmp/test.db', 'c') >>> x['foo'] = '42' >>> x['foa'] = '42' >>> x['fox'] = '42' >>> x.set_location('fob') ('foo', '42') ie, set_location returns the *next* matching item from the btree db if no exact match is found. i'm assuming this is intended. this is very useful behaviour, for example when you want to look for keys with a certain prefix, but it is not mentioned in the docs. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127377&group_id=5470 From noreply@sourceforge.net Wed Jan 3 15:51:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Jan 2001 07:51:01 -0800 Subject: [Python-bugs-list] [Bug #127361] httplib problem with '100 Continue' Message-ID: Bug #127361, was updated on 2001-Jan-02 18:14 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: dougfort Assigned to : gstein Summary: httplib problem with '100 Continue' Details: I believe there is a bug in httplib IIS 4 and 5 are subject to send an unsolicited result code of '100 Continue' with a couple of headers and a blank line before sending '302 Object Moved'. The 100 response is totally worthless and should be ignored. Unfortunately, httplib.HTTPConnection is unwilling to go back and read more headers when it already has a response object. I was able to get past this with the following kludge: while 1: response = self._client.getresponse() if response.status != 100: break # 2000-12-30 djf -- drop bogus 100 response # by kludging httplib self._client._HTTPConnection__state = httplib._CS_REQ_SENT self._client._HTTPConnection__response = None For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127361&group_id=5470 From noreply@sourceforge.net Wed Jan 3 21:27:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Jan 2001 13:27:08 -0800 Subject: [Python-bugs-list] [Bug #116285] Unicode encoders don't report errors properly Message-ID: Bug #116285, was updated on 2000-Oct-06 17:32 Here is a current snapshot of the bug. Project: Python Category: Unicode Status: Closed Resolution: Remind Bug Group: None Priority: 3 Submitted by: loewis Assigned to : lemburg Summary: Unicode encoders don't report errors properly Details: In current CVS, u"\366".encode("koi8-r") gives '\366'. This is incorrect - koi8-r does not support LATIN SMALL LETTER O WITH DIAERESIS, so it should raise a UnicodeError instead. Follow-Ups: Date: 2001-Jan-03 13:27 By: lemburg Comment: Patch checked in. ------------------------------------------------------- Date: 2000-Dec-22 06:06 By: loewis Comment: A fix for that bug is in http://sourceforge.net/patch/?func=detailpatch&patch_id=103002&group_id=5470 Set group back to None since we are in the 2.1 cycle now. ------------------------------------------------------- Date: 2000-Oct-12 13:26 By: lemburg Comment: Reopened so that the bug doesn't get forgotten in 2.1. Instead of closing the bug, I will set the priority to 3 which should signal "not vital for the Python 2.0 release". ------------------------------------------------------- Date: 2000-Oct-12 11:24 By: lemburg Comment: Closed for 2.0. This request should be reopened for the 2.1 cycle. As Martin pointed out in private mail, the situation with correct error handling is not all that bad: the encoders default to latin-1 mappings (ie. 1-1) when converting Unicode to the encoding in case no mapping is given for the character. The fix would be to add explicit encoding mappings for all supplied standard codecs which map all Latin-1 characters which do not have a corresponding character in the encoding to None. This will then cause the codec to raise an error saying that the mapping is undefined. ------------------------------------------------------- Date: 2000-Oct-09 01:14 By: lemburg Comment: Note that this is due to the way the character mapping codec works: if the dictionary doesn't include a mapping for a certain character it simply copies that character without raising an error. All standard codecs in Python 2.0 which use the generic character codec only contain explicit mappings from the encoding to Unicode (for the decoding part). When encoding from Unicode to the encoding, the decoding map is simply reversed. To produce correct error output in all possible cases, the reverse mapping would have to include all Unicode characters which cannot be mapped to a encoding character (and map these to None). This is not feasable, so the "bug" is hard to fix... certainly not for Python 2.0. I'm setting the bug report to "Feature Request" meaning that it should be reopened for the 2.1 cycle. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=116285&group_id=5470 From noreply@sourceforge.net Wed Jan 3 21:37:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Jan 2001 13:37:27 -0800 Subject: [Python-bugs-list] [Bug #119960] Problems with Tcl/Tk and non-ASCII text entry Message-ID: Bug #119960, was updated on 2000-Oct-31 13:38 Here is a current snapshot of the bug. Project: Python Category: Unicode Status: Open Resolution: None Bug Group: None Priority: 3 Submitted by: kirill_simonov Assigned to : lemburg Summary: Problems with Tcl/Tk and non-ASCII text entry Details: Win98, Python2.0final. 1. I can't write cyrillic letters in IDLE editor. I tried to figure, what's happened and found that Tcl has command 'encoding'. I typed in IDLE shell: >>> from Tkinter import * >>> root = Tk() >>> root.tk.call("encoding", "names") 'utf-8 identity unicode' >>> root.tk.call("encoding", "system") 'identity' But Tcl had numerous encodings in 'tcl\tcl8.3\encodings' including 'cp1251'! Then I installed Tk separately and removed tcl83.dll and tk83.dll from DLLs: >>> from Tkinter import * >>> root = Tk() >>> root.tk.call("encoding", "names") 'cp860 cp861 [.........] cp857 unicode' >>> root.tk.call("encoding", "system") 'cp1251' So, when tcl/tk dlls in Python\DLLs directory, TCL can't load all it's encodings. But this is not the end. I typed in IDLE shell: >>> print "hello " # all chars looks correctly. and got: Exception in Tkinter callback Traceback (most recent call last): File "c:\python20\lib\lib-tk\Tkinter.py", line 1287, in __call__ return apply(self.func, args) File "C:\PYTHON20\Tools\idle\PyShell.py", line 579, in enter_callback self.runit() File "C:\PYTHON20\Tools\idle\PyShell.py", line 598, in runit more = self.interp.runsource(line) File "C:\PYTHON20\Tools\idle\PyShell.py", line 183, in runsource return InteractiveInterpreter.runsource(self, source, filename) File "c:\python20\lib\code.py", line 61, in runsource code = compile_command(source, filename, symbol) File "c:\python20\lib\codeop.py", line 61, in compile_command code = compile(source, filename, symbol) UnicodeError: ASCII encoding error: ordinal not in range(128) print "[the same characters]" Then, when I pressed Enter again, i got the same error message. I stopped this by pressing C-Break. [1/2 hour later] I fix this by editing site.py: if 1: # was: if 0 # Enable to support locale aware default string encodings. I typed again: >>> print "hello " and got: >>> print unicode("hello ") [2 hours later] Looking sources of _tkinter.c: static Tcl_Obj* AsObj(PyObject *value) { if type(value) is StringType: return Tcl_NewStringObj(value) elif type(value) is UnicodeType: ... ... } But I read in that all Tcl functions require all strings to be passed in UTF-8. So, this code must look like: if type(value) is StringType: if TCL_Version >= 8.1: return Tcl_NewStringObj() else: return Tcl_NewStringObj(value) And when I typed: >>> print unicode("hello ").encode('utf-8') i got: hello This is the end. P.S. Sorry for my bad english, but I really want to use IDLE and Tkinter in our school, so I can't wait for somebody other writing bug report. Follow-Ups: Date: 2001-Jan-03 13:37 By: lemburg Comment: I've changed the subject line to better reflect the cause of the error: 1. The Tcl version shipped with Python 2.0 apparently doesn't include the Tcl codec libs, but these seem to be needed by Tcl to allow entry of characters in non-ASCII environments. 2. Python's print statement should allow Unicode to be passed through to sys.stdout. 3. _tkinter should recode all 8-bit strings into Unicode under the assumption that the 8-bit strings use sys.getdefaultencoding() as encoding. ------------------------------------------------------- Date: 2000-Nov-12 04:17 By: kirill_simonov Comment: No, you are wrong! Entry and Text widget depends on TCL system encoding. If TCL can't find cyrillic encoding (cp1251) then I can't enter cyrillic characters. ------------------------------------------------------- Date: 2000-Nov-12 03:30 By: loewis Comment: It should be no problem that Tcl can't find its encodings. When used with Tkinter, Tcl can only expect Unicode strings, or strings in sys.getdefaultencoding() (i.e. 'ascii'). Therefore, Tk never needs any other encoding. If you want to make use of the Tcl system encoding (which is apparently not supported in Tkinter), you probably need to set the TCL_LIBRARY environment variable. ------------------------------------------------------- Date: 2000-Nov-10 10:53 By: kirill_simonov Comment: Yes, this is a solution. But don't forget that TCL can't load it's encodings at startup. Look at FixTk.py: import sys, os, _tkinter [...] os.environ["TCL_LIBRARY"] = v But 'import _tkinter' loads _tkinter.pyd; _tkinter.pyd loads tcl83.dll; tcl83.dll tryes to load it's encodings at startup and fails, becourse TCL_LIBRARY is not defined! I can fix this: #import sys, os, _tkinter import sys, os #ver = str(_tkinter.TCL_VERSION) ver = "8.3" [...] ------------------------------------------------------- Date: 2000-Nov-09 02:00 By: lemburg Comment: Ok, as we've found out in discussions on python-dev, the cause for the problem is (partially) the fact that "print obj" does an implicit str(obj), so any Unicode object printed will turn out as default encoded string no matter how hard we try. To fix this, we'll need to tweak the current "print" mechanism a bit to allow Unicode to pass through to the receveiving end (sys.stdout in this case). About the problem that Tcl/tk needs UTF-8 strings: we could have _tkinter.c recode the strings for you in case sys.getdefaultencoding() returns anything other than 'ascii' or 'utf-8'. That way you can use a different default encoding in Python while Tcl/tk will always get a true UTF-8 string. Would this be a solution ? ------------------------------------------------------- Date: 2000-Nov-03 12:49 By: gvanrossum Comment: Assigned to Marc-Andre, since I have no idea what to do about this... :-( ------------------------------------------------------- Date: 2000-Nov-01 13:16 By: kirill_simonov Comment: 1. print unicode("") in IDLE don't work! The mechanics (I think) is a) print unicode_string encodes unicode string to normal string using default encoding and pass it to sys.stdout. b) sys.stdout intercepted by IDLE. IDLE sent this string to Tkinter. c) Tkinter pass this string (not unicode but cp1251!) to TCL but TCL waits for UTF-8 string!!! d) I see messy characters on screen. 2. You breaks compability! In 1.5 I can write Button(root, text="") and this works. Writing unicode("<>", 'cp1251') is UGLY and ANNOYING! TCL requires string in utf-8. All pythonian strings is sys.getdefaultencoding() encoding. So, we have to recode all strings to utf-8. 3. TCL in DLLs can't found it's encodings in tcl\tk8.3\encodings! I don't no why. So, I can't write in Tkinter.Text in russian. ------------------------------------------------------- Date: 2000-Nov-01 12:47 By: lemburg Comment: AFAIK, the _tkinter.c code automatically converts Unicode to UTF-8 and then passes this to Tcl/Tk. So basically the folloing should get you correct results... print unicode("hello ", "cp1251") Alternatively, you can set your default encoding to "cp1251" in the way your describe and then write: print unicode("hello ") I am not too familiar with Tcl/Tk, so I can't judge whether trying to recode normal 8-bit into UTF-8 is a good idea in general for the _tkinter.c interface. It would easily be possible using: utf8 = string.encode('utf-8') since 8-bit support the .encode() method too. ------------------------------------------------------- Date: 2000-Nov-01 08:00 By: jhylton Comment: I am not entirely sure what the bug is, though I agree that it can be confusing to deal with Unicode strings. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=119960&group_id=5470 From noreply@sourceforge.net Wed Jan 3 21:41:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Jan 2001 13:41:57 -0800 Subject: [Python-bugs-list] [Bug #123642] Add site-codecs package to enable drop-in codec support Message-ID: Bug #123642, was updated on 2000-Nov-27 15:09 Here is a current snapshot of the bug. Project: Python Category: Unicode Status: Closed Resolution: None Bug Group: Feature Request Priority: 5 Submitted by: lemburg Assigned to : lemburg Summary: Add site-codecs package to enable drop-in codec support Details: (This report is just meant as reminder, so this feature request does get forgotten.) There were numerous requests for a better drop-in support for codecs on the i18n-sig list without having to register the codecs at startup. Since adding non-core modules to the Lib/encodings directory is not a good strategy, I proposed to add a new reserved package "sitecodecs" which can then be used by codec package writer to place their codecs. The encodings/__init__.py will then also look in that new package for codecs it cannot find in its own directory. That way, the new codecs won't have to register themselves and are available as soon as the codec modules can be found in the site-codecs package. The "sitecodecs" package should probably live in site-packages... perhaps the installation process should provide a default subdir for this ?! Follow-Ups: Date: 2001-Jan-03 13:41 By: lemburg Comment: Instead of adding site-codecs to the encodings codec search function import path, codecs should be addressed by providing their fully qualified package name, e.g. mycodecs.mycodec_123. The standard encoding search function will then find the codecs by importing them from the codec package and this provide the requested drop-in support for new codecs. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=123642&group_id=5470 From noreply@sourceforge.net Wed Jan 3 22:08:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Jan 2001 14:08:19 -0800 Subject: [Python-bugs-list] [Bug #123625] "authinfo" belongs before "mode reader" in nntplib.py Message-ID: Bug #123625, was updated on 2000-Nov-27 12:20 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: mogul Assigned to : twouters Summary: "authinfo" belongs before "mode reader" in nntplib.py Details: On some secure news servers (Netcape Collabra in this case), a client cannot even set "mode reader" before providing authentication information. If you have Mailman attempt to gate news from such a server, it will error with an entry such as this in the logs: Nov 27 11:01:44 2000 gate_news(9768): Traceback (innermost last): Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/cron/gate_news", line 222, in ? Nov 27 11:01:44 2000 gate_news(9768): main() Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/cron/gate_news", line 203, in main Nov 27 11:01:44 2000 gate_news(9768): process_lists(lock) Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/cron/gate_news", line 148, in process_lists Nov 27 11:01:44 2000 gate_news(9768): conn, first, last = open_newsgroup(mlist) Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/cron/gate_news", line 75, in open_newsgroup Nov 27 11:01:44 2000 gate_news(9768): password=mm_cfg.NNTP_PASSWORD) Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/Mailman/pythonlib/nntplib.py", line 117, in __init__ Nov 27 11:01:44 2000 gate_news(9768): self.welcome = self.shortcmd('mode reader') Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/Mailman/pythonlib/nntplib.py", line 210, in shortcmd Nov 27 11:01:44 2000 gate_news(9768): return self.getresp() Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/Mailman/pythonlib/nntplib.py", line 184, in getresp Nov 27 11:01:44 2000 gate_news(9768): raise NNTPTemporaryError(resp) Nov 27 11:01:44 2000 gate_news(9768): Mailman.pythonlib.nntplib . NNTPTemporaryError : 480 Authentication required for command My solution: Move these lines... if readermode: try: self.welcome = self.shortcmd('mode reader') except NNTPPermanentError: # error 500, probably 'not implemented' pass to the end of NNTP's constructor, in other words, after the authinfo exchange is done. Bret Follow-Ups: Date: 2001-Jan-03 14:08 By: gvanrossum Comment: Thomas, you seem to be the author of the readermode code. I was going to just check in the suggested change, but when I read the CVS logs, it mentioned that "mode reader" was sent before authentication, so perhaps there's a reason. If you agree with the suggestion here, please go ahead and check it in -- no need to go through the patch manager. ------------------------------------------------------- Date: 2001-Jan-02 22:30 By: bwarsaw Comment: This is more accurately a bug in Python's nntplib.py ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=123625&group_id=5470 From noreply@sourceforge.net Wed Jan 3 23:52:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Jan 2001 15:52:51 -0800 Subject: [Python-bugs-list] [Bug #123625] "authinfo" belongs before "mode reader" in nntplib.py Message-ID: Bug #123625, was updated on 2000-Nov-27 12:20 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: mogul Assigned to : twouters Summary: "authinfo" belongs before "mode reader" in nntplib.py Details: On some secure news servers (Netcape Collabra in this case), a client cannot even set "mode reader" before providing authentication information. If you have Mailman attempt to gate news from such a server, it will error with an entry such as this in the logs: Nov 27 11:01:44 2000 gate_news(9768): Traceback (innermost last): Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/cron/gate_news", line 222, in ? Nov 27 11:01:44 2000 gate_news(9768): main() Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/cron/gate_news", line 203, in main Nov 27 11:01:44 2000 gate_news(9768): process_lists(lock) Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/cron/gate_news", line 148, in process_lists Nov 27 11:01:44 2000 gate_news(9768): conn, first, last = open_newsgroup(mlist) Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/cron/gate_news", line 75, in open_newsgroup Nov 27 11:01:44 2000 gate_news(9768): password=mm_cfg.NNTP_PASSWORD) Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/Mailman/pythonlib/nntplib.py", line 117, in __init__ Nov 27 11:01:44 2000 gate_news(9768): self.welcome = self.shortcmd('mode reader') Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/Mailman/pythonlib/nntplib.py", line 210, in shortcmd Nov 27 11:01:44 2000 gate_news(9768): return self.getresp() Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/Mailman/pythonlib/nntplib.py", line 184, in getresp Nov 27 11:01:44 2000 gate_news(9768): raise NNTPTemporaryError(resp) Nov 27 11:01:44 2000 gate_news(9768): Mailman.pythonlib.nntplib . NNTPTemporaryError : 480 Authentication required for command My solution: Move these lines... if readermode: try: self.welcome = self.shortcmd('mode reader') except NNTPPermanentError: # error 500, probably 'not implemented' pass to the end of NNTP's constructor, in other words, after the authinfo exchange is done. Bret Follow-Ups: Date: 2001-Jan-03 15:52 By: twouters Comment: It's not so simple :-( I already forgot all this stuff again, but here's what I remember: The reader-mode isn't covered by the RFC on NNTP (which is pretty old) but is basically yet another addition by INN (IIRC, that is). We had one particular setup where readmode really was necessary before anything else, including, IIRC, authinfo. That was because the nnrpd that could handle all that wasn't spawned until you gave the 'mode reader' command, and it couldn't pass that info. However, I need to doublecheck to be sure. I think we dropped most of that intricate setup when we built our new set of top-of-the-line newsservers using Diablo rather than INN. I'll consult with a couple of local news guru's tomorrow, see if I'm not remembering wrong. If I'm not, we may have to do some dancing around by sending readermode, catching autherror, and re-sending after authinfo in that case. ------------------------------------------------------- Date: 2001-Jan-03 14:08 By: gvanrossum Comment: Thomas, you seem to be the author of the readermode code. I was going to just check in the suggested change, but when I read the CVS logs, it mentioned that "mode reader" was sent before authentication, so perhaps there's a reason. If you agree with the suggestion here, please go ahead and check it in -- no need to go through the patch manager. ------------------------------------------------------- Date: 2001-Jan-02 22:30 By: bwarsaw Comment: This is more accurately a bug in Python's nntplib.py ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=123625&group_id=5470 From noreply@sourceforge.net Thu Jan 4 01:22:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Jan 2001 17:22:45 -0800 Subject: [Python-bugs-list] [Bug #127470] Memory leak in bdb Message-ID: Bug #127470, was updated on 2001-Jan-03 17:22 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: tlau Assigned to : nobody Summary: Memory leak in bdb Details: This program quickly grows to upwards of 70M on Linux with Python 2.0: import bdb for memory_leak in xrange(10000000): b = bdb.Bdb() b.run('i=0', {}, {}) Yet factoring the bdb.Bdb() instantiation outside the loop removes the memory leak. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127470&group_id=5470 From noreply@sourceforge.net Thu Jan 4 02:31:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Jan 2001 18:31:17 -0800 Subject: [Python-bugs-list] [Bug #127470] Memory leak in bdb Message-ID: Bug #127470, was updated on 2001-Jan-03 17:22 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: tlau Assigned to : bwarsaw Summary: Memory leak in bdb Details: This program quickly grows to upwards of 70M on Linux with Python 2.0: import bdb for memory_leak in xrange(10000000): b = bdb.Bdb() b.run('i=0', {}, {}) Yet factoring the bdb.Bdb() instantiation outside the loop removes the memory leak. Follow-Ups: Date: 2001-Jan-03 18:31 By: gvanrossum Comment: Perhaps something in the trace code? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127470&group_id=5470 From noreply@sourceforge.net Thu Jan 4 05:09:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Jan 2001 21:09:59 -0800 Subject: [Python-bugs-list] [Bug #127273] Documentation of 'long' function is wrong Message-ID: Bug #127273, was updated on 2001-Jan-02 03:13 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: jribbens Assigned to : fdrake Summary: Documentation of 'long' function is wrong Details: It appears that in Python 2.0, the built-in function 'long' has been improved to allow a radix parameter. This is not listed in the documentation (Library Reference). It is quite important that it is, because with the string.atol function being deprecated I don't think there is any other way to parse a hex string. Follow-Ups: Date: 2001-Jan-03 21:09 By: fdrake Comment: Fixed in Doc/lib/libfuncs.tex revision 1.73. ------------------------------------------------------- Date: 2001-Jan-02 11:38 By: fdrake Comment: Fixed in my working sources, but checkin is held up by a stale CVS read-lock: http://sourceforge.net/support/?func=detailsupport&support_id=110927&group_id=1 I'll close this bug when I can check in the changes. ------------------------------------------------------- Date: 2001-Jan-02 08:27 By: tim_one Comment: Fred, I see that the current CVS version already documents the radix argument to long(). But both it and the docs for int() say """ If the argument is a string, it must contain a possibly signed decimal number ... """ That's inaccurate now (since the radix argument was added -- it was the truth before the radix argument was allowed). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127273&group_id=5470 From noreply@sourceforge.net Thu Jan 4 05:17:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Jan 2001 21:17:24 -0800 Subject: [Python-bugs-list] [Bug #126850] file.seek() docs should mention append mode Message-ID: Bug #126850, was updated on 2000-Dec-26 12:06 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: nobody Assigned to : fdrake Summary: file.seek() docs should mention append mode Details: f.seek() does nothing for files opened in 'a' mode (at least on linux). it is mentioned in passing in open() docs, but it should be mentioned in the seek() docs also. Follow-Ups: Date: 2001-Jan-03 21:17 By: fdrake Comment: Updated seek() documentation in Doc/lib/libstdtypes.tex revision 1.46. ------------------------------------------------------- Date: 2001-Jan-02 13:33 By: fdrake Comment: Now fixed in my working sources, but checkin is blocked on a stale CVS read-lock: http://sourceforge.net/support/?func=detailsupport&support_id=110927&group_id=1 I will close this bug when I can complete the checkin. ------------------------------------------------------- Date: 2000-Dec-26 19:25 By: tim_one Comment: Assigned to Fred. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=126850&group_id=5470 From noreply@sourceforge.net Thu Jan 4 05:13:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Jan 2001 21:13:25 -0800 Subject: [Python-bugs-list] [Bug #127055] bisect module needs updated docs Message-ID: Bug #127055, was updated on 2000-Dec-28 20:30 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Closed Resolution: Fixed Bug Group: Feature Request Priority: 5 Submitted by: tim_one Assigned to : fdrake Summary: bisect module needs updated docs Details: I'd just take the docstrings out of {bisect,insort}_{left,right} and LaTex'ize them, but am not sure how. Would also mention that "insort" and "bisect" are aliases for insort_right and bisect_right, for backward compatibility. Yell at me if I can be of real help! Follow-Ups: Date: 2001-Jan-03 21:13 By: fdrake Comment: Documentation updated in Doc/lib/libbisect.tex revision 1.8. ------------------------------------------------------- Date: 2001-Jan-02 12:02 By: fdrake Comment: Updated in my working sources, but blocked on a stale CVS read-lock: http://sourceforge.net/support/?func=detailsupport&support_id=110927&group_id=1 I'll close this bug report when I've made the checkin. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127055&group_id=5470 From noreply@sourceforge.net Thu Jan 4 06:00:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Jan 2001 22:00:18 -0800 Subject: [Python-bugs-list] [Bug #127483] repr and str return different results for a some floats Message-ID: Bug #127483, was updated on 2001-Jan-03 22:00 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : nobody Summary: repr and str return different results for a some floats Details: I was getting some strange result when converting between strings and floats for doing calculations and discovered that it was happening when executing the following code. def test_float( a_float ) : print a_float, str( a_float ), repr( a_float ) if __name__ == '__main__' : test_float( 0.01 ) test_float( 0.02 ) test_float( 0.03 ) test_float( 0.04 ) test_float( 0.05 ) test_float( 0.06 ) test_float( 0.07 ) RESULTS 0.01 0.01 0.01 0.02 0.02 0.02 0.03 0.03 0.029999999999999999 0.04 0.04 0.040000000000000001 0.05 0.05 0.050000000000000003 0.06 0.06 0.059999999999999998 0.07 0.07 0.070000000000000007 For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127483&group_id=5470 From noreply@sourceforge.net Thu Jan 4 06:25:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Jan 2001 22:25:53 -0800 Subject: [Python-bugs-list] [Bug #127483] repr and str return different results for a some floats Message-ID: Bug #127483, was updated on 2001-Jan-03 22:00 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Closed Resolution: Invalid Bug Group: Feature Request Priority: 5 Submitted by: nobody Assigned to : nobody Summary: repr and str return different results for a some floats Details: I was getting some strange result when converting between strings and floats for doing calculations and discovered that it was happening when executing the following code. def test_float( a_float ) : print a_float, str( a_float ), repr( a_float ) if __name__ == '__main__' : test_float( 0.01 ) test_float( 0.02 ) test_float( 0.03 ) test_float( 0.04 ) test_float( 0.05 ) test_float( 0.06 ) test_float( 0.07 ) RESULTS 0.01 0.01 0.01 0.02 0.02 0.02 0.03 0.03 0.029999999999999999 0.04 0.04 0.040000000000000001 0.05 0.05 0.050000000000000003 0.06 0.06 0.059999999999999998 0.07 0.07 0.070000000000000007 Follow-Ups: Date: 2001-Jan-03 22:25 By: tim_one Comment: This is not a bug. Binary floating point cannot represent decimal fractions exactly, so some rounding always occurs (even in Python 1.5.2). What changed is that Python 2.0 shows more precision than before in certain circumstances (repr() and the interactive prompt). You can use str() or print to get the old, rounded output: >>> print 0.1+0.1 0.2 >>> Follow the link for a detailed example: http://www.python.org/cgi-bin/moinmoin/RepresentationError ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127483&group_id=5470 From noreply@sourceforge.net Thu Jan 4 14:18:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 06:18:31 -0800 Subject: [Python-bugs-list] [Bug #122715] __rcmp__() description Message-ID: Bug #122715, was updated on 2000-Nov-17 12:08 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Closed Resolution: Invalid Bug Group: None Priority: 5 Submitted by: fdrake Assigned to : jhylton Summary: __rcmp__() description Details: The description of the __rcmp__() method in the Python Reference Manual is clearly wrong; can you please correct it, including information about when it is called? I've received another request for this, and don't see it in the bug database. [Assigned to Jeremy because Guido says he went through and figured it out at one point.] Follow-Ups: Date: 2001-Jan-04 06:18 By: jhylton Comment: the recent changes for coercion and comparison render this request obsolete ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=122715&group_id=5470 From noreply@sourceforge.net Thu Jan 4 14:42:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 06:42:51 -0800 Subject: [Python-bugs-list] [Bug #122715] __rcmp__() description Message-ID: Bug #122715, was updated on 2000-Nov-17 12:08 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: Invalid Bug Group: None Priority: 5 Submitted by: fdrake Assigned to : fdrake Summary: __rcmp__() description Details: The description of the __rcmp__() method in the Python Reference Manual is clearly wrong; can you please correct it, including information about when it is called? I've received another request for this, and don't see it in the bug database. [Assigned to Jeremy because Guido says he went through and figured it out at one point.] Follow-Ups: Date: 2001-Jan-04 06:42 By: gvanrossum Comment: Reopened and given to Fred. Since __rcmp__ is now no longer supported at all, it should be removed from ref3.tex. ------------------------------------------------------- Date: 2001-Jan-04 06:18 By: jhylton Comment: the recent changes for coercion and comparison render this request obsolete ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=122715&group_id=5470 From noreply@sourceforge.net Thu Jan 4 15:13:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 07:13:13 -0800 Subject: [Python-bugs-list] [Bug #122715] __rcmp__() description Message-ID: Bug #122715, was updated on 2000-Nov-17 12:08 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Closed Resolution: Invalid Bug Group: None Priority: 5 Submitted by: fdrake Assigned to : fdrake Summary: __rcmp__() description Details: The description of the __rcmp__() method in the Python Reference Manual is clearly wrong; can you please correct it, including information about when it is called? I've received another request for this, and don't see it in the bug database. [Assigned to Jeremy because Guido says he went through and figured it out at one point.] Follow-Ups: Date: 2001-Jan-04 07:13 By: fdrake Comment: Documentation updated to indicate that __rcmp__() is no longer supported as of Python 2.1. We still need to maintain the entry since we want people reading existing code to be able to find out that it is an unsupported method. ------------------------------------------------------- Date: 2001-Jan-04 06:42 By: gvanrossum Comment: Reopened and given to Fred. Since __rcmp__ is now no longer supported at all, it should be removed from ref3.tex. ------------------------------------------------------- Date: 2001-Jan-04 06:18 By: jhylton Comment: the recent changes for coercion and comparison render this request obsolete ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=122715&group_id=5470 From noreply@sourceforge.net Thu Jan 4 15:17:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 07:17:00 -0800 Subject: [Python-bugs-list] [Bug #127151] mkhowto --iconserver doesn't do anything Message-ID: Bug #127151, was updated on 2000-Dec-30 19:35 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: akuchling Assigned to : fdrake Summary: mkhowto --iconserver doesn't do anything Details: The --iconserver option to mkhowto doesn't seem to work. The init file contains a $ICONSERVER='whatever' line, but LaTeX2HTML (the correct version, 99.2b8) seems to just be ignoring the setting. Follow-Ups: Date: 2001-Jan-04 07:17 By: fdrake Comment: Fixed the fix in Doc/perl/l2hinit.perl revision 1.52. See the check comment for details. ------------------------------------------------------- Date: 2001-Jan-03 07:33 By: akuchling Comment: Fix confirmed; thanks, Fred! ------------------------------------------------------- Date: 2001-Jan-02 14:09 By: fdrake Comment: This is due to agressive caching of the tags for the icons; fixed in Doc/perl/l2hinit.perl revision 1.51. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127151&group_id=5470 From noreply@sourceforge.net Thu Jan 4 15:54:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 07:54:45 -0800 Subject: [Python-bugs-list] [Bug #116678] minidom doesn't raise exception for illegal children Message-ID: Bug #116678, was updated on 2000-Oct-11 19:30 Here is a current snapshot of the bug. Project: Python Category: XML Status: Open Resolution: None Bug Group: None Priority: 6 Submitted by: akuchling Assigned to : akuchling Summary: minidom doesn't raise exception for illegal children Details: Some types of DOM node such as Text can't have children. minidom doesn't check for this at all: from xml.dom import minidom doc = minidom.Document() text = doc.createTextNode('lorem ipsum') elem = doc.createElement('leaf') text.appendChild( elem ) print text.toxml() This outputs just 'lorem ipsum', but elem really is a child of text; Text.toxml() just isn't recursing because it doesn't expect to do so. Follow-Ups: Date: 2001-Jan-04 07:54 By: fdrake Comment: Andrew, didn't you mostly fix this? If you're done, please close the bug report. (One thing to check: it doesn't look like NamedNodeMap.setNamedItem() and .setNamedItemNS() check that the inserted node is an ATTRIBUTE_NODE; if not, HierarchyRequestErr should be raised.) Thanks for working on this! ------------------------------------------------------- Date: 2000-Dec-12 13:08 By: gvanrossum Comment: Reassigning to Fred so he can pressure Paul into doing something about this. ------------------------------------------------------- Date: 2000-Nov-23 08:07 By: akuchling Comment: Patch #102485 has been submitted to fix this. ------------------------------------------------------- Date: 2000-Nov-21 14:33 By: fdrake Comment: Oops, should re-categorize this as "XML" while I'm at it. ------------------------------------------------------- Date: 2000-Nov-21 14:33 By: fdrake Comment: >From the documentation, I'd expect the Pythonic "moral equivalents" to be raised, which would be a ValueError in the case of illegal node types. I'll even go so far as to say that ValueError should be raised when a second documentElement is appended, instead of a TypeError, to be more consistent with usage else where in the standard library: Pythonic style is to raise a ValueError when the type of a value is right (in this case, a DOM Node), but the specific value is not acceptable, either because it is illegal or because it cannot be accepted given existing state (like already having a documentElement). ------------------------------------------------------- Date: 2000-Oct-15 07:06 By: loewis Comment: I believe this is not a bug, but an intended deviation from the DOM spec. minidom (as the proposed documentation in patch 101821 explains) does not support the IDL exceptions of module DOM, so it cannot report errors about improper usage. ------------------------------------------------------- Date: 2000-Oct-12 20:02 By: fdrake Comment: This is a bug with detecting an improper use. It should be fixed, but need not be for Python 2.0. Correct use will not produce erroneous behavior. Reducing priority by one. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=116678&group_id=5470 From noreply@sourceforge.net Thu Jan 4 19:06:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 11:06:25 -0800 Subject: [Python-bugs-list] [Bug #127562] variable return from urllib.FancyURLopener.http_error_401 Message-ID: Bug #127562, was updated on 2001-Jan-04 11:06 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: montanaro Assigned to : nobody Summary: variable return from urllib.FancyURLopener.http_error_401 Details: The block structure in urllib.FancyURLopener.http_error_401 suggests that there are cases where it can return None or the result of retrying basic http/https authentication. It seems to me that either you should assume that the response headers will always have valid contents (a www-authenticate of the proper format) or do something in the case where they don't (perhaps raise an exception). I suspect all you'd be doing is protecting the application against a broken server, but I think those cases should still be handled. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127562&group_id=5470 From noreply@sourceforge.net Fri Jan 5 05:59:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 21:59:53 -0800 Subject: [Python-bugs-list] [Bug #110832] urljoin() bug with odd no of '..' (PR#194) Message-ID: Bug #110832, was updated on 2000-Aug-01 14:13 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Closed Resolution: Fixed Bug Group: None Priority: 6 Submitted by: nobody Assigned to : fdrake Summary: urljoin() bug with odd no of '..' (PR#194) Details: Jitterbug-Id: 194 Submitted-By: DrMalte@ddd.de Date: Sun, 30 Jan 2000 19:40:45 -0500 (EST) Version: 1.5.2 and 1.4 OS: Linux While playing with linbot I noticed some failed requests to 'http://xxx.xxx.xx/../img/xxx.gif' for a document in the root directory containing . The Reason is in urlparse.urljoin() urljoin() fails to remove an odd number of '../' from the path. Demonstration: from urlparse import urljoin print urljoin( 'http://127.0.0.1/', '../imgs/logo.gif' ) # gives 'http://127.0.0.1/../imgs/logo.gif' # should give 'http://127.0.0.1/imgs/logo.gif' print urljoin( 'http://127.0.0.1/', '../../imgs/logo.gif' ) # gives 'http://127.0.0.1/imgs/logo.gif' # works # '../../imgs/logo.gif' gives 'http://127.0.0.1/../imgs/logo.gif' and so on The patch for 1.5.2 ( I'm not sure if it works generally, but tests with linbot looked good) *** /usr/local/lib/python1.5/urlparse.py Sat Jun 26 19:11:59 1999 --- urlparse.py Mon Jan 31 01:31:45 2000 *************** *** 170,175 **** --- 170,180 ---- segments[-1] = '' elif len(segments) >= 2 and segments[-1] == '..': segments[-2:] = [''] + + if segments[0] == '': + while segments[1] == '..': # remove all leading '..' + del segments[1] + return urlunparse((scheme, netloc, joinfields(segments, '/'), params, query, fragment)) ==================================================================== Audit trail: Mon Feb 07 12:35:35 2000 guido changed notes Mon Feb 07 12:35:35 2000 guido moved from incoming to request Follow-Ups: Date: 2001-Jan-04 21:59 By: fdrake Comment: Lib/urlparse.py revision 1.27 conforms to all recommended practices from RFC 1808 which don't conflict with RFC 1630. Test cases have been added to ensure we don't lose this attribute. ------------------------------------------------------- Date: 2000-Dec-19 08:41 By: fdrake Comment: Ok, confirmed. Reopening the bug until I get a chance to look at the proposed patch and can update the test suite. ------------------------------------------------------- Date: 2000-Dec-19 08:38 By: gvanrossum Comment: OK, reopened. ------------------------------------------------------- Date: 2000-Dec-19 08:30 By: doerwalter Comment: Section 5.2 of RFC 1808 states that in the context of the base URL <> = URLs that have more .. than the base has directory names, should be resolved in the following way: ../../../g = ../../../../g = i.e. they should be preserved, which urljoin does in the first example gives in the bug report: print urljoin( 'http://127.0.0.1/', '../imgs/logo.gif' ) http://127.0.0.1/../imgs/logo.gif but not in the second example: print urljoin( 'http://127.0.0.1/', '../../imgs/logo.gif' ) http://127.0.0.1/imgs/logo.gif where the result should have been http://127.0.0.1/../../imgs/logo.gif ------------------------------------------------------- Date: 2000-Aug-23 21:22 By: fdrake Comment: RFC 1808 gives examples of this form in section 5.2, "Abnormal Examples," and gives the current behavior as the desired treatment, stating that all parsers (urljoin() counts given the RFC's terminology) should treat the abnormal examples consistently. ------------------------------------------------------- Date: 2000-Aug-13 01:36 By: moshez Comment: OK, Jeremy -- this one is yours. Either notabug it, or check in the relevant patch (101064 -- assigned to you) ------------------------------------------------------- Date: 2000-Aug-01 14:13 By: nobody Comment: Patch being considered. ------------------------------------------------------- Date: 2000-Aug-01 14:13 By: nobody Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] urljoin() bug with odd no of '..' (PR#194) Date: Mon, 31 Jan 2000 12:28:55 -0500 Thanks for your bug report and fix. I agree with your diagnosis. Would you please be so kind as to resend your patch with the legal disclaimer from http://www.python.org/1.5/bugrelease.html --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110832&group_id=5470 From noreply@sourceforge.net Fri Jan 5 06:44:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jan 2001 22:44:43 -0800 Subject: [Python-bugs-list] [Bug #127377] bsddb set_location doc clarification Message-ID: Bug #127377, was updated on 2001-Jan-02 23:52 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: nobody Assigned to : fdrake Summary: bsddb set_location doc clarification Details: it seems that you can do >>> import bsddb >>> x = bsddb.btopen('/tmp/test.db', 'c') >>> x['foo'] = '42' >>> x['foa'] = '42' >>> x['fox'] = '42' >>> x.set_location('fob') ('foo', '42') ie, set_location returns the *next* matching item from the btree db if no exact match is found. i'm assuming this is intended. this is very useful behaviour, for example when you want to look for keys with a certain prefix, but it is not mentioned in the docs. Follow-Ups: Date: 2001-Jan-04 22:44 By: fdrake Comment: Updated explanation in Doc/lib/libbsddb.tex revision 1.6. (Good catch, thanks!) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127377&group_id=5470 From noreply@sourceforge.net Fri Jan 5 15:36:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 05 Jan 2001 07:36:33 -0800 Subject: [Python-bugs-list] [Bug #121654] sre regex () groups have strong memory Message-ID: Bug #121654, was updated on 2000-Nov-05 00:17 Here is a current snapshot of the bug. Project: Python Category: Regular Expressions Status: Open Resolution: Fixed Bug Group: None Priority: 5 Submitted by: david_alessio Assigned to : effbot Summary: sre regex () groups have strong memory Details: The new re module (sre) has a problem with () grouping. It seems () groups sometimes "remember" the previous match. Try the following: #!/usr/bin/python """ This module parses a CSV string and produces a list whose elements are the Comma-Seperated Values. myCSV uses Python's regular expression matching. The search pattern uses three groups of (). findall() returns a list of tuples containing three elements--the results of the search groups. The lambda function returns the correct element of the three. For more info on regular expressions see: Mastering Regular Expressions Jeffrey E. F. Friedl O'Reilly Press ###################################################################### Created: 23-Mar-2000 Author: David S. Alessio Last Modified: $Modtime:$ Last Modified by: $Author:$ Revision: $Revision:$ Revision History: $Log:$ ###################################################################### """ import re class myCSV: def __init__(self): self.srchPat = '"([^"\\\\]*(\\\\.[^"\\\\]*)*)",?|([^,]+),?|,' self.srchProg = re.compile(self.srchPat) def __str2num(self, str): try: num = int(str) except: try: num = long(str) except: try: num = float(str) except: num = str return num def __pick_best_value(self, t): value = t[0] or t[2] return self.__str2num(value) def csv2list(self, str): # print self.srchProg.findall(str) return map(lambda t: t[0] or t[2], self.srchProg.findall(str)) def csv2numlist(self, str): return map(self.__pick_best_value, self.srchProg.findall(str)) def test(self): str = '1,2,3,"ab\\"c","de,f",name,"123",,,"xyz","","zzz"' tstnumlst = [1,2,3,'ab\\"c','de,f','name',123,'','','xyz','','zzz'] list = self.csv2list(str) numlst = self.csv2numlist(str) print str print list print numlst print tstnumlst #""" if tstnumlst != numlst: print "\nERROR:" if len(numlst) > len(tstnumlst): print 'NumList Too Long!!!' elif len(numlst) < len(tstnumlst): print 'NumList Too Short!!!' else: print ' Expected Got' for i in xrange(len(tstnumlst)): mark = '' if tstnumlst[i] != numlst[i]: mark = ' <===' print 'L[%2d]: %10s %10s %s' % (i, tstnumlst[i], numlst[i], mark) else: print 'OK' #""" if __name__ == '__main__': from sys import argv if len(argv) == 1: print 'Compiling CSV' x = myCSV(); print 'Testing...' x.test() elif len(argv) == 2: fin = open(argv[1]) x = myCSV(); while 1: str = fin.readline() if not str: break csv = x.csv2numlist(str[:-1]) print csv else: print 'Usage: %s [file.csv]' % argv[0] Follow-Ups: Date: 2001-Jan-05 07:36 By: effbot Comment: Fixed but not closed? Might mean that it's fixed locally, but not in the CVS repository. I'll investigate. /F ------------------------------------------------------- Date: 2000-Nov-09 11:54 By: effbot Comment: same as #117612 ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=121654&group_id=5470 From noreply@sourceforge.net Fri Jan 5 20:30:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 05 Jan 2001 12:30:57 -0800 Subject: [Python-bugs-list] [Bug #127699] Memory leaks using imp.load_module Message-ID: Bug #127699, was updated on 2001-Jan-05 12:30 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: cgw Assigned to : nobody Summary: Memory leaks using imp.load_module Details: #!/usr/bin/env python import os import sys import imp print os.getpid() sys.path.append("/tmp") count = 0 while (count<1000): modname = "testmod%s" % count count = count + 1 filename = '/tmp/' + modname + '.py' f = open(filename, 'w') for x in range(10000): f.write('x%s=%s\n'%(x,x)) f.close() modinfo = imp.find_module(modname) print 'loading', modname m = apply(imp.load_module, ('testmod',) + modinfo) ## run "watch -n 1 ps up ## where is the pid printed out by this program For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127699&group_id=5470 From noreply@sourceforge.net Sat Jan 6 03:56:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 05 Jan 2001 19:56:47 -0800 Subject: [Python-bugs-list] [Bug #127718] binascii_a2b_uu '@' is 0? trailing garbage bug. Message-ID: Bug #127718, was updated on 2001-Jan-05 19:56 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: donut Assigned to : nobody Summary: binascii_a2b_uu '@' is 0? trailing garbage bug. Details: I first came upon the problem that binascii.a2b_uu does not handle correctly uuencoded files that end with `. After investigation of the uuencode standard and the binascii.c module, I believe I have found the reason: The binascii module source says that some uuencoders use '@' as zero instead of space, but (at least in ascii): >>> ord('@')-32 32 The only thing I can think of is that perhaps this comment was written by someone using a different charset where ord('@') is 96 rather than 64 as in ascii. I believe this is confirmed by the comment and the following code: /* Check the character for legality ** The 64 in stead of the expected 63 is because ** there are a few uuencodes out there that use ** '@' as zero instead of space. */ if ( this_ch < ' ' || this_ch > (' ' + 64)) { this comment certainly seems to indicate that the author is expecting ' '+64 to be '@'. But in ascii this is actually '`'. While this isn't a problem in this portion of the code since it is calculated numerically, later on we have: /* Extra '@' may be written as padding in some cases */ if ( this_ch != ' ' && this_ch != '@' && this_ch != '\n' && this_ch != '\r' ) { PyErr_SetString(Error, "Trailing garbage"); In this case, I believe the '@' should really be '`', or preferably ' '+64, to avoid any more charset confusion. Of course, I could have missed something and '@', really is correct.. in that case '`' should be added since I see many uuencoders using that instead of space.. but I really believe that this is what the code was originally trying to do anyway. (especially since it does do this in the illegal char detection code.) For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127718&group_id=5470 From noreply@sourceforge.net Sat Jan 6 04:27:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 05 Jan 2001 20:27:25 -0800 Subject: [Python-bugs-list] [Bug #127718] binascii_a2b_uu '@' is 0? trailing garbage bug. Message-ID: Bug #127718, was updated on 2001-Jan-05 19:56 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: donut Assigned to : nobody Summary: binascii_a2b_uu '@' is 0? trailing garbage bug. Details: I first came upon the problem that binascii.a2b_uu does not handle correctly uuencoded files that end with `. After investigation of the uuencode standard and the binascii.c module, I believe I have found the reason: The binascii module source says that some uuencoders use '@' as zero instead of space, but (at least in ascii): >>> ord('@')-32 32 The only thing I can think of is that perhaps this comment was written by someone using a different charset where ord('@') is 96 rather than 64 as in ascii. I believe this is confirmed by the comment and the following code: /* Check the character for legality ** The 64 in stead of the expected 63 is because ** there are a few uuencodes out there that use ** '@' as zero instead of space. */ if ( this_ch < ' ' || this_ch > (' ' + 64)) { this comment certainly seems to indicate that the author is expecting ' '+64 to be '@'. But in ascii this is actually '`'. While this isn't a problem in this portion of the code since it is calculated numerically, later on we have: /* Extra '@' may be written as padding in some cases */ if ( this_ch != ' ' && this_ch != '@' && this_ch != '\n' && this_ch != '\r' ) { PyErr_SetString(Error, "Trailing garbage"); In this case, I believe the '@' should really be '`', or preferably ' '+64, to avoid any more charset confusion. Of course, I could have missed something and '@', really is correct.. in that case '`' should be added since I see many uuencoders using that instead of space.. but I really believe that this is what the code was originally trying to do anyway. (especially since it does do this in the illegal char detection code.) Follow-Ups: Date: 2001-Jan-05 20:27 By: donut Comment: Just another note: If this is fixed, then the workaround in uu.py could possibly be removed.. Assuming it doesn't workaround any other problems too. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127718&group_id=5470 From noreply@sourceforge.net Sat Jan 6 05:16:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 05 Jan 2001 21:16:44 -0800 Subject: [Python-bugs-list] [Bug #127722] getpythonregpath fails Message-ID: Bug #127722, was updated on 2001-Jan-05 21:16 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: effbiae Assigned to : nobody Summary: getpythonregpath fails Details: Hi, I'm on Win95 (regrettably). I found that while experimenting with embedding Python in C, I initialized the interpreter, and got the message: 'import site' failed; use -v for traceback If I putenv("PYTHONHOME=C:\python20"), this disappears. Also, if I put the executable in C:\python20, the problem disappears. Please excuse any stupidity that follows as I am a newby to the windows registy. in the file: Pc\getpathp.c in the function: static char * getpythonregpath(HKEY keyBase, int skipcore) in the call: rc = RegQueryInfoKey(newKey, NULL, NULL, NULL, &numKeys, NULL, NULL, NULL, NULL, &dataSize, NULL, NULL); numKeys is being set to 0 because in my installation of Python 2.0, the registry key: HKEY_LOCAL_MACHINE\\Software\\Python\\PythonCore\\PythonPath\ has no subkeys. It has the 'default' (?) value: C:\Python20\Lib\plat-win;C:\Python20\Lib;C:\Python20\DLLs;C:\Python20\Lib\lib-tk (I do not have HKEY_CURRENT_USER\\Software\\Python\\PythonCore\\PythonPath -- in fact I do not have HKEY_CURRENT_USER\\Software\\Python) Anyway, it looks like the code assumes 'numKeys > 0', which is not the case at my run-time. It appears that the the registry editing part of the installation program may have changed recently, and this file has not been updated accordingly. Also, the doco for the Python/C API says that the PATH environment variable may be examined to locate the python executable, but it appears that in the Win version of Python2.0, PATH is ignored. Is there a reason why PATH is not examined in the Win version? For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127722&group_id=5470 From noreply@sourceforge.net Sat Jan 6 20:04:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 06 Jan 2001 12:04:07 -0800 Subject: [Python-bugs-list] [Bug #127361] httplib problem with '100 Continue' Message-ID: Bug #127361, was updated on 2001-Jan-02 18:14 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: dougfort Assigned to : gstein Summary: httplib problem with '100 Continue' Details: I believe there is a bug in httplib IIS 4 and 5 are subject to send an unsolicited result code of '100 Continue' with a couple of headers and a blank line before sending '302 Object Moved'. The 100 response is totally worthless and should be ignored. Unfortunately, httplib.HTTPConnection is unwilling to go back and read more headers when it already has a response object. I was able to get past this with the following kludge: while 1: response = self._client.getresponse() if response.status != 100: break # 2000-12-30 djf -- drop bogus 100 response # by kludging httplib self._client._HTTPConnection__state = httplib._CS_REQ_SENT self._client._HTTPConnection__response = None Follow-Ups: Date: 2001-Jan-06 12:04 By: gstein Comment: Agreed -- this is a problem in httplib. I was hoping to get the "chewing up" of 100 (Continue) responses into httplib before the 2.0 release. It should be possible to do this in HTTPResponse.begin() ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127361&group_id=5470 From noreply@sourceforge.net Sat Jan 6 20:14:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 06 Jan 2001 12:14:23 -0800 Subject: [Python-bugs-list] [Bug #127361] httplib problem with '100 Continue' Message-ID: Bug #127361, was updated on 2001-Jan-02 18:14 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: dougfort Assigned to : gstein Summary: httplib problem with '100 Continue' Details: I believe there is a bug in httplib IIS 4 and 5 are subject to send an unsolicited result code of '100 Continue' with a couple of headers and a blank line before sending '302 Object Moved'. The 100 response is totally worthless and should be ignored. Unfortunately, httplib.HTTPConnection is unwilling to go back and read more headers when it already has a response object. I was able to get past this with the following kludge: while 1: response = self._client.getresponse() if response.status != 100: break # 2000-12-30 djf -- drop bogus 100 response # by kludging httplib self._client._HTTPConnection__state = httplib._CS_REQ_SENT self._client._HTTPConnection__response = None Follow-Ups: Date: 2001-Jan-06 12:14 By: dougfort Comment: I'm not sure httplib should know anything about the actual status. Right now it is elegantly decoupled from the content it handles. Perhaps just a 'discardresponse()' function. BTW, I've had very good results with the HTTP 1.1 functionality in general. This is a small nit. ------------------------------------------------------- Date: 2001-Jan-06 12:04 By: gstein Comment: Agreed -- this is a problem in httplib. I was hoping to get the "chewing up" of 100 (Continue) responses into httplib before the 2.0 release. It should be possible to do this in HTTPResponse.begin() ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127361&group_id=5470 From noreply@sourceforge.net Sat Jan 6 21:28:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 06 Jan 2001 13:28:53 -0800 Subject: [Python-bugs-list] [Bug #127718] binascii_a2b_uu '@' is 0? trailing garbage bug. Message-ID: Bug #127718, was updated on 2001-Jan-05 19:56 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: donut Assigned to : nobody Summary: binascii_a2b_uu '@' is 0? trailing garbage bug. Details: I first came upon the problem that binascii.a2b_uu does not handle correctly uuencoded files that end with `. After investigation of the uuencode standard and the binascii.c module, I believe I have found the reason: The binascii module source says that some uuencoders use '@' as zero instead of space, but (at least in ascii): >>> ord('@')-32 32 The only thing I can think of is that perhaps this comment was written by someone using a different charset where ord('@') is 96 rather than 64 as in ascii. I believe this is confirmed by the comment and the following code: /* Check the character for legality ** The 64 in stead of the expected 63 is because ** there are a few uuencodes out there that use ** '@' as zero instead of space. */ if ( this_ch < ' ' || this_ch > (' ' + 64)) { this comment certainly seems to indicate that the author is expecting ' '+64 to be '@'. But in ascii this is actually '`'. While this isn't a problem in this portion of the code since it is calculated numerically, later on we have: /* Extra '@' may be written as padding in some cases */ if ( this_ch != ' ' && this_ch != '@' && this_ch != '\n' && this_ch != '\r' ) { PyErr_SetString(Error, "Trailing garbage"); In this case, I believe the '@' should really be '`', or preferably ' '+64, to avoid any more charset confusion. Of course, I could have missed something and '@', really is correct.. in that case '`' should be added since I see many uuencoders using that instead of space.. but I really believe that this is what the code was originally trying to do anyway. (especially since it does do this in the illegal char detection code.) Follow-Ups: Date: 2001-Jan-06 13:28 By: jackjansen Comment: If I remember correctly the original comment (and code) is mine, and this fix sounds plausible. The only thing that worries me slightly is that this seems to have gone unnoticed for so many years... ------------------------------------------------------- Date: 2001-Jan-05 20:27 By: donut Comment: Just another note: If this is fixed, then the workaround in uu.py could possibly be removed.. Assuming it doesn't workaround any other problems too. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127718&group_id=5470 From noreply@sourceforge.net Sat Jan 6 22:55:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 06 Jan 2001 14:55:56 -0800 Subject: [Python-bugs-list] [Bug #127718] binascii_a2b_uu '@' is 0? trailing garbage bug. Message-ID: Bug #127718, was updated on 2001-Jan-05 19:56 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: donut Assigned to : nobody Summary: binascii_a2b_uu '@' is 0? trailing garbage bug. Details: I first came upon the problem that binascii.a2b_uu does not handle correctly uuencoded files that end with `. After investigation of the uuencode standard and the binascii.c module, I believe I have found the reason: The binascii module source says that some uuencoders use '@' as zero instead of space, but (at least in ascii): >>> ord('@')-32 32 The only thing I can think of is that perhaps this comment was written by someone using a different charset where ord('@') is 96 rather than 64 as in ascii. I believe this is confirmed by the comment and the following code: /* Check the character for legality ** The 64 in stead of the expected 63 is because ** there are a few uuencodes out there that use ** '@' as zero instead of space. */ if ( this_ch < ' ' || this_ch > (' ' + 64)) { this comment certainly seems to indicate that the author is expecting ' '+64 to be '@'. But in ascii this is actually '`'. While this isn't a problem in this portion of the code since it is calculated numerically, later on we have: /* Extra '@' may be written as padding in some cases */ if ( this_ch != ' ' && this_ch != '@' && this_ch != '\n' && this_ch != '\r' ) { PyErr_SetString(Error, "Trailing garbage"); In this case, I believe the '@' should really be '`', or preferably ' '+64, to avoid any more charset confusion. Of course, I could have missed something and '@', really is correct.. in that case '`' should be added since I see many uuencoders using that instead of space.. but I really believe that this is what the code was originally trying to do anyway. (especially since it does do this in the illegal char detection code.) Follow-Ups: Date: 2001-Jan-06 14:55 By: donut Comment: That is worrisome, but it could just be that few people use binascii directly, and thus the workaround in uu.py hides the problem from most people that might notice it. Perhaps those that did notice merely took the same workaround out of uu.py and put it into their code (as I did originally, before it bugged me enough to look into the problem deeper). ------------------------------------------------------- Date: 2001-Jan-06 13:28 By: jackjansen Comment: If I remember correctly the original comment (and code) is mine, and this fix sounds plausible. The only thing that worries me slightly is that this seems to have gone unnoticed for so many years... ------------------------------------------------------- Date: 2001-Jan-05 20:27 By: donut Comment: Just another note: If this is fixed, then the workaround in uu.py could possibly be removed.. Assuming it doesn't workaround any other problems too. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127718&group_id=5470 From noreply@sourceforge.net Sat Jan 6 23:40:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 06 Jan 2001 15:40:14 -0800 Subject: [Python-bugs-list] [Bug #127718] binascii_a2b_uu '@' is 0? trailing garbage bug. Message-ID: Bug #127718, was updated on 2001-Jan-05 19:56 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: donut Assigned to : nobody Summary: binascii_a2b_uu '@' is 0? trailing garbage bug. Details: I first came upon the problem that binascii.a2b_uu does not handle correctly uuencoded files that end with `. After investigation of the uuencode standard and the binascii.c module, I believe I have found the reason: The binascii module source says that some uuencoders use '@' as zero instead of space, but (at least in ascii): >>> ord('@')-32 32 The only thing I can think of is that perhaps this comment was written by someone using a different charset where ord('@') is 96 rather than 64 as in ascii. I believe this is confirmed by the comment and the following code: /* Check the character for legality ** The 64 in stead of the expected 63 is because ** there are a few uuencodes out there that use ** '@' as zero instead of space. */ if ( this_ch < ' ' || this_ch > (' ' + 64)) { this comment certainly seems to indicate that the author is expecting ' '+64 to be '@'. But in ascii this is actually '`'. While this isn't a problem in this portion of the code since it is calculated numerically, later on we have: /* Extra '@' may be written as padding in some cases */ if ( this_ch != ' ' && this_ch != '@' && this_ch != '\n' && this_ch != '\r' ) { PyErr_SetString(Error, "Trailing garbage"); In this case, I believe the '@' should really be '`', or preferably ' '+64, to avoid any more charset confusion. Of course, I could have missed something and '@', really is correct.. in that case '`' should be added since I see many uuencoders using that instead of space.. but I really believe that this is what the code was originally trying to do anyway. (especially since it does do this in the illegal char detection code.) Follow-Ups: Date: 2001-Jan-06 15:40 By: donut Comment: That is worrisome, but it could just be that few people use binascii directly, and thus the workaround in uu.py hides the problem from most people that might notice it. Perhaps those that did notice merely took the same workaround out of uu.py and put it into their code (as I did originally, before it bugged me enough to look into the problem deeper). ------------------------------------------------------- Date: 2001-Jan-06 14:55 By: donut Comment: That is worrisome, but it could just be that few people use binascii directly, and thus the workaround in uu.py hides the problem from most people that might notice it. Perhaps those that did notice merely took the same workaround out of uu.py and put it into their code (as I did originally, before it bugged me enough to look into the problem deeper). ------------------------------------------------------- Date: 2001-Jan-06 13:28 By: jackjansen Comment: If I remember correctly the original comment (and code) is mine, and this fix sounds plausible. The only thing that worries me slightly is that this seems to have gone unnoticed for so many years... ------------------------------------------------------- Date: 2001-Jan-05 20:27 By: donut Comment: Just another note: If this is fixed, then the workaround in uu.py could possibly be removed.. Assuming it doesn't workaround any other problems too. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127718&group_id=5470 From noreply@sourceforge.net Sun Jan 7 06:03:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 06 Jan 2001 22:03:03 -0800 Subject: [Python-bugs-list] [Bug #127271] parser module tuple2ast cannot handle node type 280 Message-ID: Bug #127271, was updated on 2001-Jan-02 02:53 Here is a current snapshot of the bug. Project: Python Category: Parser/Compiler Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: pearu Assigned to : fdrake Summary: parser module tuple2ast cannot handle node type 280 Details: The following Python session illustrates the bug: >>> import parser >>> parser.tuple2ast((parser.suite('import sys,math')).totuple()) Traceback (most recent call last): File "", line 1, in ? parser.ParserError: Expected node type 280, got 279. >>> parser.tuple2ast((parser.suite('import sys\nimport math')).totuple()) Follow-Ups: Date: 2001-Jan-06 22:03 By: fdrake Comment: Fixed in Modules/parsermodule.c revision 2.60. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127271&group_id=5470 From noreply@sourceforge.net Sun Jan 7 23:31:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 07 Jan 2001 15:31:15 -0800 Subject: [Python-bugs-list] [Bug #127562] variable return from urllib.FancyURLopener.http_error_401 Message-ID: Bug #127562, was updated on 2001-Jan-04 11:06 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: montanaro Assigned to : jhylton Summary: variable return from urllib.FancyURLopener.http_error_401 Details: The block structure in urllib.FancyURLopener.http_error_401 suggests that there are cases where it can return None or the result of retrying basic http/https authentication. It seems to me that either you should assume that the response headers will always have valid contents (a www-authenticate of the proper format) or do something in the case where they don't (perhaps raise an exception). I suspect all you'd be doing is protecting the application against a broken server, but I think those cases should still be handled. Follow-Ups: Date: 2001-Jan-07 15:31 By: fdrake Comment: Assigned to Jeremy since he likes to play with urllib. ;-) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127562&group_id=5470 From noreply@sourceforge.net Sun Jan 7 23:32:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 07 Jan 2001 15:32:49 -0800 Subject: [Python-bugs-list] [Bug #127699] Memory leaks using imp.load_module Message-ID: Bug #127699, was updated on 2001-Jan-05 12:30 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: cgw Assigned to : bwarsaw Summary: Memory leaks using imp.load_module Details: #!/usr/bin/env python import os import sys import imp print os.getpid() sys.path.append("/tmp") count = 0 while (count<1000): modname = "testmod%s" % count count = count + 1 filename = '/tmp/' + modname + '.py' f = open(filename, 'w') for x in range(10000): f.write('x%s=%s\n'%(x,x)) f.close() modinfo = imp.find_module(modname) print 'loading', modname m = apply(imp.load_module, ('testmod',) + modinfo) ## run "watch -n 1 ps up ## where is the pid printed out by this program Follow-Ups: Date: 2001-Jan-07 15:32 By: fdrake Comment: Assigned to Barry since he's the memory leak expert (& has the right tools). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127699&group_id=5470 From noreply@sourceforge.net Sun Jan 7 23:48:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 07 Jan 2001 15:48:20 -0800 Subject: [Python-bugs-list] [Bug #127722] getpythonregpath fails Message-ID: Bug #127722, was updated on 2001-Jan-05 21:16 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: effbiae Assigned to : tim_one Summary: getpythonregpath fails Details: Hi, I'm on Win95 (regrettably). I found that while experimenting with embedding Python in C, I initialized the interpreter, and got the message: 'import site' failed; use -v for traceback If I putenv("PYTHONHOME=C:\python20"), this disappears. Also, if I put the executable in C:\python20, the problem disappears. Please excuse any stupidity that follows as I am a newby to the windows registy. in the file: Pc\getpathp.c in the function: static char * getpythonregpath(HKEY keyBase, int skipcore) in the call: rc = RegQueryInfoKey(newKey, NULL, NULL, NULL, &numKeys, NULL, NULL, NULL, NULL, &dataSize, NULL, NULL); numKeys is being set to 0 because in my installation of Python 2.0, the registry key: HKEY_LOCAL_MACHINE\\Software\\Python\\PythonCore\\PythonPath\ has no subkeys. It has the 'default' (?) value: C:\Python20\Lib\plat-win;C:\Python20\Lib;C:\Python20\DLLs;C:\Python20\Lib\lib-tk (I do not have HKEY_CURRENT_USER\\Software\\Python\\PythonCore\\PythonPath -- in fact I do not have HKEY_CURRENT_USER\\Software\\Python) Anyway, it looks like the code assumes 'numKeys > 0', which is not the case at my run-time. It appears that the the registry editing part of the installation program may have changed recently, and this file has not been updated accordingly. Also, the doco for the Python/C API says that the PATH environment variable may be examined to locate the python executable, but it appears that in the Win version of Python2.0, PATH is ignored. Is there a reason why PATH is not examined in the Win version? Follow-Ups: Date: 2001-Jan-07 15:48 By: fdrake Comment: Assigned to Tim since this is on Windows. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127722&group_id=5470 From noreply@sourceforge.net Mon Jan 8 03:48:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 07 Jan 2001 19:48:21 -0800 Subject: [Python-bugs-list] [Bug #123616] Tools/compiler needs documentation. Message-ID: Bug #123616, was updated on 2000-Nov-27 10:33 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Submitted by: fdrake Assigned to : jhylton Summary: Tools/compiler needs documentation. Details: The compiler package is not documented; this needs to be done before tools are likely to be written on top of it. Follow-Ups: Date: 2001-Jan-07 19:48 By: fdrake Comment: Jeremy -- is there anything that can be done to make it easier for you to get this done? I think these should really be documented and moved into the library. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=123616&group_id=5470 From noreply@sourceforge.net Mon Jan 8 03:52:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 07 Jan 2001 19:52:53 -0800 Subject: [Python-bugs-list] [Bug #127992] This line used to work: sd.connect (routerlanip, 80) Message-ID: Bug #127992, was updated on 2001-Jan-07 19:52 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: b-52 Assigned to : nobody Summary: This line used to work: sd.connect (routerlanip, 80) Details: This line used to work under 1.6: sd.connect (routerlanip, 80) Now it returns the following error: Traceback (most recent call last): File "linksysdynhostsync.py", line 89, in ? sd.connect (routerlanip, 80) File "", line 1, in connect TypeError: connect requires exactly 1 argument; 2 given The "sd" object is opened as follows: sd = socket.socket (socket.AF_INET, socket.SOCK_STREAM) The variable "routerlanip" is set to an IP address e.g. 10.0.0.1 HELP For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127992&group_id=5470 From noreply@sourceforge.net Mon Jan 8 03:56:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 07 Jan 2001 19:56:15 -0800 Subject: [Python-bugs-list] [Bug #116388] cStringIO rejects Unicode strings Message-ID: Bug #116388, was updated on 2000-Oct-08 17:42 Here is a current snapshot of the bug. Project: Python Category: Unicode Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Submitted by: prescod Assigned to : fdrake Summary: cStringIO rejects Unicode strings Details: >>> import cStringIO >>> s=cStringIO.StringIO(u"abcdefgh") Traceback (innermost last): File "", line 1, in ? s=cStringIO.StringIO(u"abcdefgh") TypeError: expected string, unicode found Follow-Ups: Date: 2001-Jan-07 19:56 By: fdrake Comment: Ok, ok, ok... I've sent a prod to appropriate people. This *should* be interesting to have done. ------------------------------------------------------- Date: 2000-Dec-12 13:00 By: gvanrossum Comment: Assigned to Fred -- maybe you can prod Jim into looking into this. ------------------------------------------------------- Date: 2000-Oct-09 01:34 By: lemburg Comment: I've marked this as feature request since making the standard lib Unicode compatible is a post-2.0 project (probably a good one for 2.1). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=116388&group_id=5470 From noreply@sourceforge.net Mon Jan 8 04:05:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 07 Jan 2001 20:05:28 -0800 Subject: [Python-bugs-list] [Bug #126866] (xml.dom.minidom.Document()).toxml() breakable Message-ID: Bug #126866, was updated on 2000-Dec-26 15:36 Here is a current snapshot of the bug. Project: Python Category: XML Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: iainlamb Assigned to : fdrake Summary: (xml.dom.minidom.Document()).toxml() breakable Details: Consider this code: from xml.dom.minidom import Document import sys e = Exception() try: raise e except: type = sys.exc_info()[0] d = Document() node = d.createTextNode(type) d.appendChild(node) print d.toxml() It's derived from a case where I inadvertently passed a non-string object (I was trying to represent the exception type) into createTextNode(). Run it and you'll get: Traceback (most recent call last): File "", line 11, in ? File "c:\python\lib\xml\dom\minidom.py", line 83, in toxml self.writexml(writer) File "c:\python\lib\xml\dom\minidom.py", line 461, in writexml node.writexml(writer) File "c:\python\lib\xml\dom\minidom.py", line 400, in writexml _write_data(writer, self.data) File "c:\python\lib\xml\dom\minidom.py", line 153, in _write_data data = string.replace(data, "&", "&") File "c:\python\lib\string.py", line 363, in replace return s.replace(old, new, maxsplit) AttributeError: replace I suggest you convert the text node's contents to a string before making the call to string.replace() in minidom.py Thanks for a cool dom implementation! - Iain Lamb Follow-Ups: Date: 2001-Jan-07 20:05 By: fdrake Comment: Fixed in Lib/xml/dom/minidom.py revision 1.19. If the parameter is not an 8-bit or Unicode string, TypeError is raised. ------------------------------------------------------- Date: 2000-Dec-30 18:18 By: fdrake Comment: This will be fairly easy to fix; look for me to check it in early next week (when I'm near a real workstation!). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=126866&group_id=5470 From noreply@sourceforge.net Mon Jan 8 05:37:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 07 Jan 2001 21:37:45 -0800 Subject: [Python-bugs-list] [Bug #127722] getpythonregpath fails Message-ID: Bug #127722, was updated on 2001-Jan-05 21:16 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: effbiae Assigned to : mhammond Summary: getpythonregpath fails Details: Hi, I'm on Win95 (regrettably). I found that while experimenting with embedding Python in C, I initialized the interpreter, and got the message: 'import site' failed; use -v for traceback If I putenv("PYTHONHOME=C:\python20"), this disappears. Also, if I put the executable in C:\python20, the problem disappears. Please excuse any stupidity that follows as I am a newby to the windows registy. in the file: Pc\getpathp.c in the function: static char * getpythonregpath(HKEY keyBase, int skipcore) in the call: rc = RegQueryInfoKey(newKey, NULL, NULL, NULL, &numKeys, NULL, NULL, NULL, NULL, &dataSize, NULL, NULL); numKeys is being set to 0 because in my installation of Python 2.0, the registry key: HKEY_LOCAL_MACHINE\\Software\\Python\\PythonCore\\PythonPath\ has no subkeys. It has the 'default' (?) value: C:\Python20\Lib\plat-win;C:\Python20\Lib;C:\Python20\DLLs;C:\Python20\Lib\lib-tk (I do not have HKEY_CURRENT_USER\\Software\\Python\\PythonCore\\PythonPath -- in fact I do not have HKEY_CURRENT_USER\\Software\\Python) Anyway, it looks like the code assumes 'numKeys > 0', which is not the case at my run-time. It appears that the the registry editing part of the installation program may have changed recently, and this file has not been updated accordingly. Also, the doco for the Python/C API says that the PATH environment variable may be examined to locate the python executable, but it appears that in the Win version of Python2.0, PATH is ignored. Is there a reason why PATH is not examined in the Win version? Follow-Ups: Date: 2001-Jan-07 21:37 By: tim_one Comment: Assigned to MarkH cuz he might actually think he knows what the code is doing Bug #127992, was updated on 2001-Jan-07 19:52 Here is a current snapshot of the bug. Project: Python Category: Extension Modules Status: Closed Resolution: Invalid Bug Group: Not a Bug Priority: 5 Submitted by: b-52 Assigned to : nobody Summary: This line used to work: sd.connect (routerlanip, 80) Details: This line used to work under 1.6: sd.connect (routerlanip, 80) Now it returns the following error: Traceback (most recent call last): File "linksysdynhostsync.py", line 89, in ? sd.connect (routerlanip, 80) File "", line 1, in connect TypeError: connect requires exactly 1 argument; 2 given The "sd" object is opened as follows: sd = socket.socket (socket.AF_INET, socket.SOCK_STREAM) The variable "routerlanip" is set to an IP address e.g. 10.0.0.1 HELP Follow-Ups: Date: 2001-Jan-08 05:33 By: gvanrossum Comment: connect() was always documented as having a single 'address' argument, but the implementation was lax and allowed s.connect(host, port) instead of s.connect((host, port)). This was fixed in 2.0, just as list.append(a,b,c) is no longer allowed and must now be written as list.append((a,b,c)). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127992&group_id=5470 From noreply@sourceforge.net Mon Jan 8 14:35:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 08 Jan 2001 06:35:45 -0800 Subject: [Python-bugs-list] [Bug #128037] problems using the shelve module Message-ID: Bug #128037, was updated on 2001-Jan-08 06:35 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: rosleff Assigned to : nobody Summary: problems using the shelve module Details: I'm running Python 1.5.2 (#4, Jan 12 2000, 22:14:11) [GCC 2.95 19990728 (release)] on irix646. While using the shelve module the following error message occurs: >>> import shelve >>> class someClass: ... def __init__(self): ... self = [13, 17] ... >>> object = someClass() >>> dbase = shelve.open('testshelve') >>> dbase['key'] = object Traceback (innermost last): File "", line 1, in ? File "/usr/local/lib/python1.5/shelve.py", line 71, in __setitem__ self.dict[key] = f.getvalue() File "/usr/local/lib/python1.5/dumbdbm.py", line 111, in __setitem__ (pos, siz) = self._addval(val) File "/usr/local/lib/python1.5/dumbdbm.py", line 87, in _addval f.write('\0'*(npos-pos)) TypeError: can't multiply sequence with non-int For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128037&group_id=5470 From noreply@sourceforge.net Mon Jan 8 14:49:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 08 Jan 2001 06:49:47 -0800 Subject: [Python-bugs-list] [Bug #128037] problems using the shelve module Message-ID: Bug #128037, was updated on 2001-Jan-08 06:35 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: rosleff Assigned to : nobody Summary: problems using the shelve module Details: I'm running Python 1.5.2 (#4, Jan 12 2000, 22:14:11) [GCC 2.95 19990728 (release)] on irix646. While using the shelve module the following error message occurs: >>> import shelve >>> class someClass: ... def __init__(self): ... self = [13, 17] ... >>> object = someClass() >>> dbase = shelve.open('testshelve') >>> dbase['key'] = object Traceback (innermost last): File "", line 1, in ? File "/usr/local/lib/python1.5/shelve.py", line 71, in __setitem__ self.dict[key] = f.getvalue() File "/usr/local/lib/python1.5/dumbdbm.py", line 111, in __setitem__ (pos, siz) = self._addval(val) File "/usr/local/lib/python1.5/dumbdbm.py", line 87, in _addval f.write('\0'*(npos-pos)) TypeError: can't multiply sequence with non-int Follow-Ups: Date: 2001-Jan-08 06:49 By: gvanrossum Comment: This is fixed in 2.0. If you want to fix it yourself in 1.5.2, change the line "pos = f.tell()" to " pos = int(f.tell())" in method _addval() in dumdbm.py. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128037&group_id=5470 From noreply@sourceforge.net Mon Jan 8 15:00:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 08 Jan 2001 07:00:48 -0800 Subject: [Python-bugs-list] [Bug #128040] memory leak when using win32 extension for Python Message-ID: Bug #128040, was updated on 2001-Jan-08 07:00 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: pbmtl Assigned to : nobody Summary: memory leak when using win32 extension for Python Details: I run script that use the win32 extension embedded in a server. When I call the Py_Finalize method, the memory is not free completely. Each time I run a script, my server uses more and more memory. I think the Patch #101713 talk about this problem. It seems that python have problem handling multiple Py_Initialize and Py_Finalise when extension are used. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128040&group_id=5470 From noreply@sourceforge.net Mon Jan 8 16:08:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 08 Jan 2001 08:08:08 -0800 Subject: [Python-bugs-list] [Bug #126863] getopt long option handling broken Message-ID: Bug #126863, was updated on 2000-Dec-26 15:00 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: nobody Assigned to : fdrake Summary: getopt long option handling broken Details: This problem is still present in the CVS version. [Forwarded from the Debian bug tracking system, Bug#80243] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=80243&repeatmerged=yes Sender: Matt Kraai Package: python-base Version: 1.5.2-10 If a long option which takes an argument is a prefix of a longer option, and if the first new character of the longer option is less than '=' in ascii, getopt returns an incorrect message that the prefix is not unique. For example, Script started on Thu Dec 21 14:19:44 2000 kraai@opensource:~$ python Python 1.5.2 (#0, Apr 3 2000, 14:46:48) [GCC 2.95.2 20000313 (Debian GNU/Linux)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import getopt >>> getopt.getopt(["--foo", "bar"], "", ["foo=", "foobar"]) ([('--foo', 'bar')], []) >>> getopt.getopt(["--foo", "bar"], "", ["foo=", "foo-bar"]) Traceback (innermost last): File "", line 1, in ? File "/usr/lib/python1.5/getopt.py", line 58, in getopt opts, args = do_longs(opts, args[0][2:], longopts, args[1:]) File "/usr/lib/python1.5/getopt.py", line 71, in do_longs has_arg, opt = long_has_args(opt, longopts) File "/usr/lib/python1.5/getopt.py", line 93, in long_has_args raise error, 'option --%s not a unique prefix' % opt getopt.error: option --foo not a unique prefix >>> kraai@opensource:~$ Script done on Thu Dec 21 14:20:02 2000 The problem is that the trailing '=' causes the foo-bar option to precede the foo one, whereas the code assumes that the shortest option is first. The appended patch fixes this by sorting based on the option itself, not including the extra '='. I assume there is a better way to do this. --- getopt.py.orig Mon Apr 3 06:49:15 2000 +++ getopt.py Thu Dec 21 13:31:21 2000 @@ -49,7 +49,7 @@ longopts = [longopts] else: longopts = list(longopts) - longopts.sort() + longopts.sort(longopt_compare) while args and args[0][:1] == '-' and args[0] != '-': if args[0] == '--': args = args[1:] @@ -115,6 +115,18 @@ if opt == shortopts[i] != ':': return shortopts[i+1:i+2] == ':' raise error, 'option -%s not recognized' % opt + +def longopt_compare(opt1, opt2): + if opt1[-1] == '=': + opt1 = opt1[:-1] + if opt2[-1] == '=': + opt2 = opt2[:-1] + if opt1 < opt2: + return -1 + elif opt1 == opt2: + return 0 + else: + return 1 if __name__ == '__main__': import sys Matt Follow-Ups: Date: 2001-Jan-08 08:07 By: fdrake Comment: Documentation updated in Doc/lib/libgetopt.tex revision 1.16. ------------------------------------------------------- Date: 2000-Dec-27 03:47 By: flight Comment: Ooops, forgot to login before sending this bug. In case of questions, please ask me ------------------------------------------------------- Date: 2000-Dec-27 00:08 By: tim_one Comment: Assigned to Fred and changed category to Doc: Fred, the getopt docs don't say anything now about accepting a unique prefix for long option names. The logic error here is fixed in CVS now, getopt.py rev 1.12 and test_getopt.py rev 1.3. Function long_has_args was excruciating, so rewrote it. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=126863&group_id=5470 From noreply@sourceforge.net Mon Jan 8 17:42:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 08 Jan 2001 09:42:40 -0800 Subject: [Python-bugs-list] [Bug #128053] Minor bug in posixmodule.c Message-ID: Bug #128053, was updated on 2001-Jan-08 09:42 Here is a current snapshot of the bug. Project: Python Category: Extension Modules Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: nobody Assigned to : nobody Summary: Minor bug in posixmodule.c Details: I just pulled down the 2.0 "final", and had to fix the following in Modules/posixmodule.c, breifly someone has HAVE_TEMPNAM twice instead of HAVE_TMPFILE and HAVE_TMPNAM... *** posixmodule.c.orig Mon Jan 8 11:28:43 2001 --- posixmodule.c Mon Jan 8 11:28:55 2001 *************** *** 5348,5354 **** #ifdef HAVE_STATVFS {"statvfs", posix_statvfs, METH_VARARGS, posix_statvfs__doc__}, #endif ! #ifdef HAVE_TMPNAM {"tmpfile", posix_tmpfile, METH_VARARGS, posix_tmpfile__doc__}, #endif #ifdef HAVE_TEMPNAM --- 5348,5354 ---- #ifdef HAVE_STATVFS {"statvfs", posix_statvfs, METH_VARARGS, posix_statvfs__doc__}, #endif ! #ifdef HAVE_TMPFILE {"tmpfile", posix_tmpfile, METH_VARARGS, posix_tmpfile__doc__}, #endif #ifdef HAVE_TEMPNAM For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128053&group_id=5470 From noreply@sourceforge.net Mon Jan 8 17:53:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 08 Jan 2001 09:53:27 -0800 Subject: [Python-bugs-list] [Bug #128053] Minor bug in posixmodule.c Message-ID: Bug #128053, was updated on 2001-Jan-08 09:42 Here is a current snapshot of the bug. Project: Python Category: Extension Modules Status: Closed Resolution: Fixed Bug Group: Platform-specific Priority: 5 Submitted by: nobody Assigned to : gvanrossum Summary: Minor bug in posixmodule.c Details: I just pulled down the 2.0 "final", and had to fix the following in Modules/posixmodule.c, breifly someone has HAVE_TEMPNAM twice instead of HAVE_TMPFILE and HAVE_TMPNAM... *** posixmodule.c.orig Mon Jan 8 11:28:43 2001 --- posixmodule.c Mon Jan 8 11:28:55 2001 *************** *** 5348,5354 **** #ifdef HAVE_STATVFS {"statvfs", posix_statvfs, METH_VARARGS, posix_statvfs__doc__}, #endif ! #ifdef HAVE_TMPNAM {"tmpfile", posix_tmpfile, METH_VARARGS, posix_tmpfile__doc__}, #endif #ifdef HAVE_TEMPNAM --- 5348,5354 ---- #ifdef HAVE_STATVFS {"statvfs", posix_statvfs, METH_VARARGS, posix_statvfs__doc__}, #endif ! #ifdef HAVE_TMPFILE {"tmpfile", posix_tmpfile, METH_VARARGS, posix_tmpfile__doc__}, #endif #ifdef HAVE_TEMPNAM Follow-Ups: Date: 2001-Jan-08 09:53 By: gvanrossum Comment: Thanks! Fixed now in CVS. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128053&group_id=5470 From noreply@sourceforge.net Mon Jan 8 20:09:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 08 Jan 2001 12:09:34 -0800 Subject: [Python-bugs-list] [Bug #128079] memory leak in pyexpat parser Message-ID: Bug #128079, was updated on 2001-Jan-08 12:09 Here is a current snapshot of the bug. Project: Python Category: XML Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : nobody Summary: memory leak in pyexpat parser Details: Hi, I am having a problem with memroy when I am running a python program which has a code similar to this. from xml.dom import minidom while 1: doc = minidom.parse('text.xml') print doc del doc The memory size keeps incrementing as the loop is executed.This is the text.xml file 50008 10 10 10 10 I am trying to delete it manually even then the memory size is increasing. Please I need some help . Thanks kishore For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128079&group_id=5470 From noreply@sourceforge.net Mon Jan 8 20:35:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 08 Jan 2001 12:35:39 -0800 Subject: [Python-bugs-list] [Bug #128079] memory leak in pyexpat parser Message-ID: Bug #128079, was updated on 2001-Jan-08 12:09 Here is a current snapshot of the bug. Project: Python Category: XML Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : fdrake Summary: memory leak in pyexpat parser Details: Hi, I am having a problem with memroy when I am running a python program which has a code similar to this. from xml.dom import minidom while 1: doc = minidom.parse('text.xml') print doc del doc The memory size keeps incrementing as the loop is executed.This is the text.xml file 50008 10 10 10 10 I am trying to delete it manually even then the memory size is increasing. Please I need some help . Thanks kishore For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128079&group_id=5470 From noreply@sourceforge.net Tue Jan 9 01:43:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 08 Jan 2001 17:43:41 -0800 Subject: [Python-bugs-list] [Bug #128119] Building under FreeBSD 2.2.1 fails due to unresolved _TELL64 Message-ID: Bug #128119, was updated on 2001-Jan-08 17:43 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: jh1 Assigned to : nobody Summary: Building under FreeBSD 2.2.1 fails due to unresolved _TELL64 Details: fileobject.c:274: Undefined symbol `_TELL64' referenced from text segment % uname -sr FreeBSD 2.2.1-RELEASE % ./configure; make [...] gcc -g -O2 -Wall -Wstrict-prototypes -I./../Include -I.. -DHAVE_CONFIG_H -c fileobject.c fileobject.c: In function `_portable_fseek': fileobject.c:274: warning: implicit declaration of function `TELL64' [...] cd Modules; make OPT="-g -O2 -Wall -Wstrict-prototypes" VERSION="2.0" prefix="/usr/local" exec_prefix="/usr/local" LIBRARY=../libpython2.0.a link gcc python.o ../libpython2.0.a -lutil -lm -o python fileobject.c:274: Undefined symbol `_TELL64' referenced from text segment It compiles cleanly if I use ``gcc -D__NetBSD__'', or, better, if I apply: diff -u Objects/fileobject.c{~,} --- Objects/fileobject.c~ Mon Oct 16 14:49:24 2000 +++ Objects/fileobject.c Mon Jan 8 17:41:49 2001 @@ -58,7 +58,7 @@ /* define the appropriate 64-bit capable tell() function */ #if defined(MS_WIN64) #define TELL64 _telli64 -#elif defined(__NetBSD__) || defined(__OpenBSD__) +#elif defined(__NetBSD__) || defined(__OpenBSD__) || defined(__FreeBSD__) /* NOTE: this is only used on older NetBSD prior to f*o() funcions */ #define TELL64(fd) lseek((fd),0,SEEK_CUR) For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128119&group_id=5470 From noreply@sourceforge.net Tue Jan 9 01:57:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 08 Jan 2001 17:57:24 -0800 Subject: [Python-bugs-list] [Bug #126851] ftplib.py should default to passive mode Message-ID: Bug #126851, was updated on 2000-Dec-26 12:07 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: Feature Request Priority: 4 Submitted by: flight Assigned to : gvanrossum Summary: ftplib.py should default to passive mode Details: For the Debian package, there has been the request that the ftplib module should by default use passive FTP. Any comments [Forwarded from the Debian bug tracking system, bug#71823] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=71823&repeatmerged=yes Sender: Mike Fisk Package: python-base Version: 1.5.2-10 This is an upstream bug that has existed for quite a while (probably forever). With many systems living behind firewalls (including their own ipchains filters), passive FTP should be the default for FTP clients. It always has been for Netscape and there hasn't been much uproar about that being bad. Python's ftplib.py supports passive mode, but defaults to non-passive mode. ftplib.py is used by other Debian packages such as the downloader in xanim-modules. The result, when living behind many firewalls, is that you can't download anything using ftplib.py or urllib.py. The patch to fix this is trivial: --- /usr/lib/python1.5/ftplib.py Sat Sep 16 14:31:35 2000 +++ /tmp/ftplib.py Sat Sep 16 14:31:24 2000 @@ -112,7 +112,7 @@ - port: port to connect to (integer, default previous port)''' if host: self.host = host if port: self.port = port - self.passiveserver = 0 + self.passiveserver = 1 self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.sock.connect(self.host, self.port) self.file = self.sock.makefile('rb') -- Mike Fisk, RADIANT Team, Network Engineering Group, Los Alamos National Lab See http://home.lanl.gov/mfisk/ for contact information Follow-Ups: Date: 2001-Jan-08 17:57 By: gvanrossum Comment: Thomas Wouters raised the concern that passive mode makes it impossible to access servers that are inside a firewall. I'm not sure that this is a showstopper (does anybody do that?) but I'd like to stay on the careful side. Thomas noted that ftplib is used for more diverse tasks than Netscape. Would it be sufficient to make a change to urllib that changes the connection to passive mode in its ftpwrapper class? That would solve the problem for urllib (most comparable to Netscape) without breaking any code that directly uses ftplib. ------------------------------------------------------- Date: 2000-Dec-27 15:16 By: gvanrossum Comment: Hmm... I like the proposed patch. I don't know about ftp'ing into a firewall -- why would that be common? Typically ftp servers live outside firewalls because ftp is considered insecure... ------------------------------------------------------- Date: 2000-Dec-27 14:13 By: twouters Comment: For what it's worth, I mildly agree that passive mode should be the default. However, it does have potential for breaking stuff: using passive-ftp *into* a firewall, instead of out of one, doesn't work. And I'm pretty sure that Python's ftplib is used much more often in that manner than is Netscape or whatever other ftp client defaults to passive. It's probably not much, but I think it's enough to think twice about changing the default ;P ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=126851&group_id=5470 From noreply@sourceforge.net Tue Jan 9 02:00:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 08 Jan 2001 18:00:36 -0800 Subject: [Python-bugs-list] [Bug #128119] Building under FreeBSD 2.2.1 fails due to unresolved _TELL64 Message-ID: Bug #128119, was updated on 2001-Jan-08 17:43 Here is a current snapshot of the bug. Project: Python Category: Build Status: Closed Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: jh1 Assigned to : gvanrossum Summary: Building under FreeBSD 2.2.1 fails due to unresolved _TELL64 Details: fileobject.c:274: Undefined symbol `_TELL64' referenced from text segment % uname -sr FreeBSD 2.2.1-RELEASE % ./configure; make [...] gcc -g -O2 -Wall -Wstrict-prototypes -I./../Include -I.. -DHAVE_CONFIG_H -c fileobject.c fileobject.c: In function `_portable_fseek': fileobject.c:274: warning: implicit declaration of function `TELL64' [...] cd Modules; make OPT="-g -O2 -Wall -Wstrict-prototypes" VERSION="2.0" prefix="/usr/local" exec_prefix="/usr/local" LIBRARY=../libpython2.0.a link gcc python.o ../libpython2.0.a -lutil -lm -o python fileobject.c:274: Undefined symbol `_TELL64' referenced from text segment It compiles cleanly if I use ``gcc -D__NetBSD__'', or, better, if I apply: diff -u Objects/fileobject.c{~,} --- Objects/fileobject.c~ Mon Oct 16 14:49:24 2000 +++ Objects/fileobject.c Mon Jan 8 17:41:49 2001 @@ -58,7 +58,7 @@ /* define the appropriate 64-bit capable tell() function */ #if defined(MS_WIN64) #define TELL64 _telli64 -#elif defined(__NetBSD__) || defined(__OpenBSD__) +#elif defined(__NetBSD__) || defined(__OpenBSD__) || defined(__FreeBSD__) /* NOTE: this is only used on older NetBSD prior to f*o() funcions */ #define TELL64(fd) lseek((fd),0,SEEK_CUR) Follow-Ups: Date: 2001-Jan-08 18:00 By: gvanrossum Comment: Thanks. Change checked into the CVS tree as 2.103. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128119&group_id=5470 From noreply@sourceforge.net Tue Jan 9 02:02:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 08 Jan 2001 18:02:12 -0800 Subject: [Python-bugs-list] [Bug #128040] memory leak when using win32 extension for Python Message-ID: Bug #128040, was updated on 2001-Jan-08 07:00 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: pbmtl Assigned to : tim_one Summary: memory leak when using win32 extension for Python Details: I run script that use the win32 extension embedded in a server. When I call the Py_Finalize method, the memory is not free completely. Each time I run a script, my server uses more and more memory. I think the Patch #101713 talk about this problem. It seems that python have problem handling multiple Py_Initialize and Py_Finalise when extension are used. Follow-Ups: Date: 2001-Jan-08 18:02 By: gvanrossum Comment: Assigned to Tim. First task would be to request needed infromation from submitter. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128040&group_id=5470 From noreply@sourceforge.net Tue Jan 9 02:12:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 08 Jan 2001 18:12:17 -0800 Subject: [Python-bugs-list] [Bug #127718] binascii_a2b_uu '@' is 0? trailing garbage bug. Message-ID: Bug #127718, was updated on 2001-Jan-05 19:56 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Closed Resolution: None Bug Group: None Priority: 5 Submitted by: donut Assigned to : gvanrossum Summary: binascii_a2b_uu '@' is 0? trailing garbage bug. Details: I first came upon the problem that binascii.a2b_uu does not handle correctly uuencoded files that end with `. After investigation of the uuencode standard and the binascii.c module, I believe I have found the reason: The binascii module source says that some uuencoders use '@' as zero instead of space, but (at least in ascii): >>> ord('@')-32 32 The only thing I can think of is that perhaps this comment was written by someone using a different charset where ord('@') is 96 rather than 64 as in ascii. I believe this is confirmed by the comment and the following code: /* Check the character for legality ** The 64 in stead of the expected 63 is because ** there are a few uuencodes out there that use ** '@' as zero instead of space. */ if ( this_ch < ' ' || this_ch > (' ' + 64)) { this comment certainly seems to indicate that the author is expecting ' '+64 to be '@'. But in ascii this is actually '`'. While this isn't a problem in this portion of the code since it is calculated numerically, later on we have: /* Extra '@' may be written as padding in some cases */ if ( this_ch != ' ' && this_ch != '@' && this_ch != '\n' && this_ch != '\r' ) { PyErr_SetString(Error, "Trailing garbage"); In this case, I believe the '@' should really be '`', or preferably ' '+64, to avoid any more charset confusion. Of course, I could have missed something and '@', really is correct.. in that case '`' should be added since I see many uuencoders using that instead of space.. but I really believe that this is what the code was originally trying to do anyway. (especially since it does do this in the illegal char detection code.) Follow-Ups: Date: 2001-Jan-08 18:12 By: gvanrossum Comment: A plausible theory. I've applied the suggested changes (changed '@' into '`' or ' '+64). (It could be that, rather than a different charset, the author of the comment was confused because '@' is the value *after space is subtracted*. Oh well.) Checked into CVS as binascii.c 2.28. ------------------------------------------------------- Date: 2001-Jan-06 15:40 By: donut Comment: That is worrisome, but it could just be that few people use binascii directly, and thus the workaround in uu.py hides the problem from most people that might notice it. Perhaps those that did notice merely took the same workaround out of uu.py and put it into their code (as I did originally, before it bugged me enough to look into the problem deeper). ------------------------------------------------------- Date: 2001-Jan-06 14:55 By: donut Comment: That is worrisome, but it could just be that few people use binascii directly, and thus the workaround in uu.py hides the problem from most people that might notice it. Perhaps those that did notice merely took the same workaround out of uu.py and put it into their code (as I did originally, before it bugged me enough to look into the problem deeper). ------------------------------------------------------- Date: 2001-Jan-06 13:28 By: jackjansen Comment: If I remember correctly the original comment (and code) is mine, and this fix sounds plausible. The only thing that worries me slightly is that this seems to have gone unnoticed for so many years... ------------------------------------------------------- Date: 2001-Jan-05 20:27 By: donut Comment: Just another note: If this is fixed, then the workaround in uu.py could possibly be removed.. Assuming it doesn't workaround any other problems too. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127718&group_id=5470 From noreply@sourceforge.net Tue Jan 9 03:04:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 08 Jan 2001 19:04:01 -0800 Subject: [Python-bugs-list] [Bug #125452] shlex.shlex hangs when parsing an unclosed quoted string Message-ID: Bug #125452, was updated on 2000-Dec-11 23:12 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: nobody Assigned to : esr Summary: shlex.shlex hangs when parsing an unclosed quoted string Details: import StringIO import shlex s = shlex.shlex(StringIO.StringIO("hello 'world")) you'll see that get_token doesn't test for EOF when it's in the ' state. Just adding that test should fix the problem. Follow-Ups: Date: 2001-Jan-08 19:04 By: akuchling Comment: Fixed by patch #102953. ------------------------------------------------------- Date: 2000-Dec-19 17:00 By: akuchling Comment: Patch #102953 has been submitted to fix this. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=125452&group_id=5470 From noreply@sourceforge.net Tue Jan 9 14:33:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Jan 2001 06:33:52 -0800 Subject: [Python-bugs-list] [Bug #128164] time.localtime(-5.0) -> IOError (errno=22) Message-ID: Bug #128164, was updated on 2001-Jan-09 06:33 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: digulla Assigned to : nobody Summary: time.localtime(-5.0) -> IOError (errno=22) Details: Try this: import time time.localtime (-5.0) This returns (1969, 12, 31, 23, 59, 55, 2, 365, 0) on Unix and throws an IOError on Windows. Positive values do work. NOTE: If your TZ is != GMT/UTC, then you may have to use larger negative values. Try until you get a year < 1970. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128164&group_id=5470 From noreply@sourceforge.net Tue Jan 9 14:39:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Jan 2001 06:39:23 -0800 Subject: [Python-bugs-list] [Bug #128164] time.localtime(-5.0) -> IOError (errno=22) Message-ID: Bug #128164, was updated on 2001-Jan-09 06:33 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Closed Resolution: Invalid Bug Group: Platform-specific Priority: 5 Submitted by: digulla Assigned to : gvanrossum Summary: time.localtime(-5.0) -> IOError (errno=22) Details: Try this: import time time.localtime (-5.0) This returns (1969, 12, 31, 23, 59, 55, 2, 365, 0) on Unix and throws an IOError on Windows. Positive values do work. NOTE: If your TZ is != GMT/UTC, then you may have to use larger negative values. Try until you get a year < 1970. Follow-Ups: Date: 2001-Jan-09 06:39 By: gvanrossum Comment: Doesn't look like a bug to me. The time module only deals in times since 1/1/1970. What it does for negative values is undefined. (Why does it bother you?) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128164&group_id=5470 From noreply@sourceforge.net Tue Jan 9 14:46:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Jan 2001 06:46:07 -0800 Subject: [Python-bugs-list] [Bug #126706] many std modules assume string.letters is [a-zA-Z] Message-ID: Bug #126706, was updated on 2000-Dec-23 06:19 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : nobody Summary: many std modules assume string.letters is [a-zA-Z] Details: there are many modules in the standard library that use string.letters to mean A-Za-z, but that assumption is incorrect when locales are in use. also the readline library seems to cause the locale to be set according to the current environment variables, even if i don't call locale.*: % python2.0 -c 'import string; print string.letters' abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ % python2.0 Python 2.0 (#3, Oct 19 2000, 01:42:41) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Type "copyright", "credits" or "license" for more information. >>> print string.letters abcdefghijklmnopqrstuvwxyzµßàáâãäåæçèéêëìíîïðñòóôõöøùúûüýþÿABCDEFGHIJKLMNOPQRSTUVWXYZÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖØÙÚÛÜÝÞ >>> here's what grep says on the standard library. most of these uses seem incorrect to me: % grep string.letters **/*.py Cookie.py:_LegalChars = string.letters + string.digits + "!#$%&'*+-.^_`|~"cmd.py:IDENTCHARS = string.letters + string.digits + '_' dospath.py: varchars = string.letters + string.digits + '_-' lib-old/codehack.py:identchars = string.letters + string.digits + '_' # Identifier characters ntpath.py: varchars = string.letters + string.digits + '_-' nturl2path.py: if len(comp) != 2 or comp[0][-1] not in string.letters: pipes.py:_safechars = string.letters + string.digits + '!@%_-+=:,./' # Safe unquoted pre.py: alphanum=string.letters+'_'+string.digits tokenize.py: namechars, numchars = string.letters + '_', string.digits urlparse.py:scheme_chars = string.letters + string.digits + '+-.' Follow-Ups: Date: 2001-Jan-09 06:46 By: gvanrossum Comment: I agree that the string module should be extended with additional variables ascii_letters (and ascii_lowercase and ascii_uppercase and ascii_whitespace). ------------------------------------------------------- Date: 2001-Jan-01 10:08 By: lemburg Comment: The comment about readline calling setlocale() is unfortunately true (and causes some very subtle bugs in user code...). About the addition of more constants: I would rather like to see a database for these things which uses function calls much like the Unicode database (unicodedata). Since locales sometime matter, I think there should be an option to the functions which enables locale support (much like as for REs) on request. Default should be no locale support, since this is what most code expects anyway. ------------------------------------------------------- Date: 2000-Dec-30 19:36 By: akuchling Comment: The set of all letters, though, will be commonly used, though maybe we need an alphanumeric constant for A-Za-z0-9 + underscore. I like the .ascii_letters suggestion. ------------------------------------------------------- Date: 2000-Dec-30 18:26 By: fdrake Comment: Andrew, does it make sense to introduce new constants in string for this? It seems that each instance is referring to slightly different specifications or standards (documented or not), so perhaps the constants should be defined locally within each of the modules. This also avoids unnecessary dependencies. ------------------------------------------------------- Date: 2000-Dec-26 12:18 By: nobody Comment: string.ascii_letters etc is more precise than alphabet, imho. -- erno@iki.fi ------------------------------------------------------- Date: 2000-Dec-26 08:15 By: akuchling Comment: The docs for the string module say that, for example, string.lowercase is " A string containing all the characters that are considered lowercase letters." This implies that the strings are locale-aware; code that uses string.lowercase to mean only a-z is therefore in error. (.digits is not locale-aware.) Solution: I'd suggest adding new, not locale-aware, constants. string.alphabet, string.lower_alphabet, string.upper_alphabet, maybe? Code should then be changed to use these new constants. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=126706&group_id=5470 From noreply@sourceforge.net Tue Jan 9 20:44:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Jan 2001 12:44:31 -0800 Subject: [Python-bugs-list] [Bug #125489] fpectl module is undocumented Message-ID: Bug #125489, was updated on 2000-Dec-12 08:02 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Closed Resolution: Fixed Bug Group: Feature Request Priority: 2 Submitted by: fdrake Assigned to : fdrake Summary: fpectl module is undocumented Details: Lee Busby's fpectl module is undocumented. I'm going to send him an email (using what may be an old email address) to see if he'd like to document this module. Assigned to me to make sure something happens with this. Follow-Ups: Date: 2001-Jan-09 12:44 By: fdrake Comment: Checked in documentation written by Lee Busby as Doc/lib/libfpectl.tex. Thanks, Lee! ------------------------------------------------------- Date: 2000-Dec-13 09:32 By: fdrake Comment: Received response from Lee -- he should be able to get to it in the next month. Once I have his text I'll add it to the documentation and build some docstrings as well. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=125489&group_id=5470 From noreply@sourceforge.net Tue Jan 9 21:10:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Jan 2001 13:10:16 -0800 Subject: [Python-bugs-list] [Bug #128210] Threads using same stream blow up (Windows) Message-ID: Bug #128210, was updated on 2001-Jan-09 13:10 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: 3rd Party Priority: 1 Submitted by: tim_one Assigned to : nobody Summary: Threads using same stream blow up (Windows) Details: Blows up under released Windows 2.0 and CVS Pythons (so it's not due to anything new): import thread def read(f): import time time.sleep(.01) n = 0 while n < 1000000: x = f.readline() n += len(x) print "r", print "read " + `n` m.release() m = thread.allocate_lock() f = open("ga", "w+") print "opened" m.acquire() thread.start_new_thread(read, (f,)) n = 0 x = "x" * 113 + "\n" while n < 1000000: f.write(x) print "w", n += len(x) m.acquire() print "done" Typical run: C:\Python20>\code\python\dist\src\pcbuild\python temp.py opened w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r r w r w r w r w r w r and then it dies in msvcrt.dll with a bad pointer. Also dies under the debugger (yay!) ... always dies like so: + We (Python) call the MS fwrite, from fileobject.c file_write. + MS fwrite succeeds with its _lock_str(stream) call. + MS fwrite then calls MS _fwrite_lk. + MS _fwrite_lk calls memcpy, which blows up for a non-obvious reason. Looks like the stream's _cnt member has gone mildly negative, which _fwrite_lk casts to unsigned and so treats like a giant positive count, and so memcpy eventually runs off the end of the process address space. Only thing I can conclude from this is that MS's internal stream-locking implementation is buggy. At least on W98SE. Other flavors of Windows? Other platforms? Note that I don't claim the program above is *sensible*, just that it shouldn't blow up. Alas, short of adding a separate mutex in Python file objects-- or writing our own stdio --I don't believe I can fix this. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128210&group_id=5470 From noreply@sourceforge.net Tue Jan 9 22:03:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Jan 2001 14:03:31 -0800 Subject: [Python-bugs-list] [Bug #128220] cmp() broken with Unicode? Message-ID: Bug #128220, was updated on 2001-Jan-09 14:03 Here is a current snapshot of the bug. Project: Python Category: Unicode Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: beazley Assigned to : nobody Summary: cmp() broken with Unicode? Details: Is cmp() supposed to return the same result as == below? >>> a = "Hello" >>> b = u"Hello" >>> a == b 1 >>> cmp(a,b) 0 >>> For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128220&group_id=5470 From nobody@sourceforge.net Tue Jan 9 22:15:35 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 09 Jan 2001 14:15:35 -0800 Subject: [Python-bugs-list] [Bug #128223] Typo in saxutils.py Message-ID: From: noreply@sourceforge.net Bug #128223, was updated on 2001-Jan-09 14:15 Here is a current snapshot of the bug. Project: Python Category: XML Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: malraux Assigned to : nobody Summary: Typo in saxutils.py Details: Line 221 of saxutils.py in the Python 2.0 (#1, Oct 16 2000, 18:10:03) release is: f.setSystemId(f.name) It should be: source.setSystemId(f.name) If you pass an existing open file object into the parse routine, line 221 will throw "AttributeError: setSystemId". For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128223&group_id=5470 From noreply@sourceforge.net Tue Jan 9 22:17:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Jan 2001 14:17:32 -0800 Subject: [Python-bugs-list] [Bug #128220] cmp() broken with Unicode? Message-ID: Bug #128220, was updated on 2001-Jan-09 14:03 Here is a current snapshot of the bug. Project: Python Category: Unicode Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: beazley Assigned to : nobody Summary: cmp() broken with Unicode? Details: Is cmp() supposed to return the same result as == below? >>> a = "Hello" >>> b = u"Hello" >>> a == b 1 >>> cmp(a,b) 0 >>> Follow-Ups: Date: 2001-Jan-09 14:17 By: beazley Comment: Argh! Okay, my head is fried from too much Unicode.... sorry about this :-). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128220&group_id=5470 From noreply@sourceforge.net Tue Jan 9 22:34:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Jan 2001 14:34:34 -0800 Subject: [Python-bugs-list] [Bug #128220] cmp() broken with Unicode? Message-ID: Bug #128220, was updated on 2001-Jan-09 14:03 Here is a current snapshot of the bug. Project: Python Category: Unicode Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: beazley Assigned to : nobody Summary: cmp() broken with Unicode? Details: Is cmp() supposed to return the same result as == below? >>> a = "Hello" >>> b = u"Hello" >>> a == b 1 >>> cmp(a,b) 0 >>> Follow-Ups: Date: 2001-Jan-09 14:34 By: nobody Comment: I don't understand your request: cmp(a,b) == 0 means that a equals b. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-09 14:17 By: beazley Comment: Argh! Okay, my head is fried from too much Unicode.... sorry about this :-). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128220&group_id=5470 From noreply@sourceforge.net Tue Jan 9 22:38:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Jan 2001 14:38:39 -0800 Subject: [Python-bugs-list] [Bug #128040] memory leak when using win32 extension for Python Message-ID: Bug #128040, was updated on 2001-Jan-08 07:00 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: pbmtl Assigned to : mhammond Summary: memory leak when using win32 extension for Python Details: I run script that use the win32 extension embedded in a server. When I call the Py_Finalize method, the memory is not free completely. Each time I run a script, my server uses more and more memory. I think the Patch #101713 talk about this problem. It seems that python have problem handling multiple Py_Initialize and Py_Finalise when extension are used. Follow-Ups: Date: 2001-Jan-09 14:38 By: tim_one Comment: Reassigned to MarkH. Mark, sound familiar? ------------------------------------------------------- Date: 2001-Jan-08 18:02 By: gvanrossum Comment: Assigned to Tim. First task would be to request needed infromation from submitter. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128040&group_id=5470 From noreply@sourceforge.net Tue Jan 9 22:41:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Jan 2001 14:41:37 -0800 Subject: [Python-bugs-list] [Bug #128210] Threads using same stream blow up (Windows) Message-ID: Bug #128210, was updated on 2001-Jan-09 13:10 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: 3rd Party Priority: 1 Submitted by: tim_one Assigned to : nobody Summary: Threads using same stream blow up (Windows) Details: Blows up under released Windows 2.0 and CVS Pythons (so it's not due to anything new): import thread def read(f): import time time.sleep(.01) n = 0 while n < 1000000: x = f.readline() n += len(x) print "r", print "read " + `n` m.release() m = thread.allocate_lock() f = open("ga", "w+") print "opened" m.acquire() thread.start_new_thread(read, (f,)) n = 0 x = "x" * 113 + "\n" while n < 1000000: f.write(x) print "w", n += len(x) m.acquire() print "done" Typical run: C:\Python20>\code\python\dist\src\pcbuild\python temp.py opened w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r r w r w r w r w r w r and then it dies in msvcrt.dll with a bad pointer. Also dies under the debugger (yay!) ... always dies like so: + We (Python) call the MS fwrite, from fileobject.c file_write. + MS fwrite succeeds with its _lock_str(stream) call. + MS fwrite then calls MS _fwrite_lk. + MS _fwrite_lk calls memcpy, which blows up for a non-obvious reason. Looks like the stream's _cnt member has gone mildly negative, which _fwrite_lk casts to unsigned and so treats like a giant positive count, and so memcpy eventually runs off the end of the process address space. Only thing I can conclude from this is that MS's internal stream-locking implementation is buggy. At least on W98SE. Other flavors of Windows? Other platforms? Note that I don't claim the program above is *sensible*, just that it shouldn't blow up. Alas, short of adding a separate mutex in Python file objects-- or writing our own stdio --I don't believe I can fix this. Follow-Ups: Date: 2001-Jan-09 14:41 By: tim_one Comment: Adding info communicated via email: + Also blows up under Windows 2000. + Yes, C doesn't define what happens here even if it weren't threaded (you can't mix reads and writes willy-nilly (without e.g. seeking before reading) and expect something sensible). The program is not sensible. But even silly programs shouldn't *blow up* in Python. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128210&group_id=5470 From noreply@sourceforge.net Tue Jan 9 23:47:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Jan 2001 15:47:48 -0800 Subject: [Python-bugs-list] [Bug #128220] cmp() broken with Unicode? Message-ID: Bug #128220, was updated on 2001-Jan-09 14:03 Here is a current snapshot of the bug. Project: Python Category: Unicode Status: Closed Resolution: Invalid Bug Group: Not a Bug Priority: 5 Submitted by: beazley Assigned to : nobody Summary: cmp() broken with Unicode? Details: Is cmp() supposed to return the same result as == below? >>> a = "Hello" >>> b = u"Hello" >>> a == b 1 >>> cmp(a,b) 0 >>> Follow-Ups: Date: 2001-Jan-09 15:47 By: tim_one Comment: Suggest that you read the docs for cmp (Library Ref, under builtin functions). >>> 42 == 42 1 >>> cmp(42, 42) 0 >>> cmp is supposed to return 0 iff its arguments compare equal. ------------------------------------------------------- Date: 2001-Jan-09 14:34 By: nobody Comment: I don't understand your request: cmp(a,b) == 0 means that a equals b. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-09 14:17 By: beazley Comment: Argh! Okay, my head is fried from too much Unicode.... sorry about this :-). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128220&group_id=5470 From noreply@sourceforge.net Wed Jan 10 01:11:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Jan 2001 17:11:50 -0800 Subject: [Python-bugs-list] [Bug #128040] memory leak with multiple Py_Initialize/Py_Finalize calls Message-ID: Bug #128040, was updated on 2001-Jan-08 07:00 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: pbmtl Assigned to : mhammond Summary: memory leak with multiple Py_Initialize/Py_Finalize calls Details: I run script that use the win32 extension embedded in a server. When I call the Py_Finalize method, the memory is not free completely. Each time I run a script, my server uses more and more memory. I think the Patch #101713 talk about this problem. It seems that python have problem handling multiple Py_Initialize and Py_Finalise when extension are used. Follow-Ups: Date: 2001-Jan-09 17:11 By: mhammond Comment: I dont believe this is Windows specific, nor specific to the Win32 extensions. I can confirm that Python does leak with multiple Init/Terms, as I had to change the COM extensions to only initialize once (and hence never finalize). It is definitely related to the referenced patch (#101713) This has been raised before, but there doesnt appear much enthusiasm for a fix. As far as I can tell, it would involve having Py_Finalize() correctly release _all_ memory allocated by Py_Initialize(). However, I have seen numerous people state that "one off" allocations that are not freed are not worth finding and freeing - however, if this bug wants a fix, then we must track them all down. I further note that the problem is not only in the Python core, but in extension modules. Modules need a reliable way to be told that Python is finalizing so they can free their own "one off" allocations. Various hacks have been proposed for this (eg, rely on ref-count semantics to ensure that a special object is destroyed as the module dict is cleared) but nothing "reasonable" has been proposed. Really not sure what I can do here. I am willing to do my bit in patching up the leaks, but would want a (fuzzy) commitment from python-dev that I wouldnt be doing it alone, and that it is seen as important. I have updated the bug description and platform appropriately, but haven't reallocated a new person. ------------------------------------------------------- Date: 2001-Jan-09 14:38 By: tim_one Comment: Reassigned to MarkH. Mark, sound familiar? ------------------------------------------------------- Date: 2001-Jan-08 18:02 By: gvanrossum Comment: Assigned to Tim. First task would be to request needed infromation from submitter. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128040&group_id=5470 From noreply@sourceforge.net Wed Jan 10 01:13:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Jan 2001 17:13:55 -0800 Subject: [Python-bugs-list] [Bug #127722] getpythonregpath fails Message-ID: Bug #127722, was updated on 2001-Jan-05 21:16 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: effbiae Assigned to : mhammond Summary: getpythonregpath fails Details: Hi, I'm on Win95 (regrettably). I found that while experimenting with embedding Python in C, I initialized the interpreter, and got the message: 'import site' failed; use -v for traceback If I putenv("PYTHONHOME=C:\python20"), this disappears. Also, if I put the executable in C:\python20, the problem disappears. Please excuse any stupidity that follows as I am a newby to the windows registy. in the file: Pc\getpathp.c in the function: static char * getpythonregpath(HKEY keyBase, int skipcore) in the call: rc = RegQueryInfoKey(newKey, NULL, NULL, NULL, &numKeys, NULL, NULL, NULL, NULL, &dataSize, NULL, NULL); numKeys is being set to 0 because in my installation of Python 2.0, the registry key: HKEY_LOCAL_MACHINE\\Software\\Python\\PythonCore\\PythonPath\ has no subkeys. It has the 'default' (?) value: C:\Python20\Lib\plat-win;C:\Python20\Lib;C:\Python20\DLLs;C:\Python20\Lib\lib-tk (I do not have HKEY_CURRENT_USER\\Software\\Python\\PythonCore\\PythonPath -- in fact I do not have HKEY_CURRENT_USER\\Software\\Python) Anyway, it looks like the code assumes 'numKeys > 0', which is not the case at my run-time. It appears that the the registry editing part of the installation program may have changed recently, and this file has not been updated accordingly. Also, the doco for the Python/C API says that the PATH environment variable may be examined to locate the python executable, but it appears that in the Win version of Python2.0, PATH is ignored. Is there a reason why PATH is not examined in the Win version? Follow-Ups: Date: 2001-Jan-09 17:13 By: mhammond Comment: Happy to look at this, but it will probably need to wait until I return to Oz - early Feb. ------------------------------------------------------- Date: 2001-Jan-07 21:37 By: tim_one Comment: Assigned to MarkH cuz he might actually think he knows what the code is doing Bug #128251, was updated on 2001-Jan-09 21:14 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 6 Submitted by: tim_one Assigned to : fdrake Summary: Windows mmap docs need cleaning Details: WRT the docs for the Windows flavor of mmap.mmap(): 1) Doc needed: The file *must* be opened for update (r+, w+, rb+ or wb+). That's because CreateFileMapping is called with PAGE_READWRITE, and that won't let you increase permissions over the original open mode. Violating this yields baffling "The parameter is wrong" Windows errors from mmap.mmap(). 2) Doc needed: Passing a size of 0 makes the maximum size of the mapping the actual current size of the file. Don't know whether that's also true on Unices (ask AMK?); on Windows it's intentional; and it's handy to know so it's worth documenting. 3) Doc bug: The docs read as if omitting the optional tagname is different than supplying a tagname of None. I don't believe that's true; needs mild rewording. Fred and AMK and c.l.py got a longer version of this msg. I think the example of using mmap with re would be worth including too (but it would be nice to have an example that isn't Windows-specific! someone should try that on Linux too, and fiddle as needed). For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128251&group_id=5470 From noreply@sourceforge.net Wed Jan 10 05:20:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Jan 2001 21:20:53 -0800 Subject: [Python-bugs-list] [Bug #128040] memory leak with multiple Py_Initialize/Py_Finalize calls Message-ID: Bug #128040, was updated on 2001-Jan-08 07:00 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: pbmtl Assigned to : gvanrossum Summary: memory leak with multiple Py_Initialize/Py_Finalize calls Details: I run script that use the win32 extension embedded in a server. When I call the Py_Finalize method, the memory is not free completely. Each time I run a script, my server uses more and more memory. I think the Patch #101713 talk about this problem. It seems that python have problem handling multiple Py_Initialize and Py_Finalise when extension are used. Follow-Ups: Date: 2001-Jan-09 21:20 By: tim_one Comment: Thank you, Mark! Since nobody is going to volunteer to do all this stuff, and everyone else will try to stop them if they did , I reassigned it to Guido -- it's never going to get done if he doesn't push for it (and if he doesn't think it's worth the effort, that's fine too, but that's his call). ------------------------------------------------------- Date: 2001-Jan-09 17:11 By: mhammond Comment: I dont believe this is Windows specific, nor specific to the Win32 extensions. I can confirm that Python does leak with multiple Init/Terms, as I had to change the COM extensions to only initialize once (and hence never finalize). It is definitely related to the referenced patch (#101713) This has been raised before, but there doesnt appear much enthusiasm for a fix. As far as I can tell, it would involve having Py_Finalize() correctly release _all_ memory allocated by Py_Initialize(). However, I have seen numerous people state that "one off" allocations that are not freed are not worth finding and freeing - however, if this bug wants a fix, then we must track them all down. I further note that the problem is not only in the Python core, but in extension modules. Modules need a reliable way to be told that Python is finalizing so they can free their own "one off" allocations. Various hacks have been proposed for this (eg, rely on ref-count semantics to ensure that a special object is destroyed as the module dict is cleared) but nothing "reasonable" has been proposed. Really not sure what I can do here. I am willing to do my bit in patching up the leaks, but would want a (fuzzy) commitment from python-dev that I wouldnt be doing it alone, and that it is seen as important. I have updated the bug description and platform appropriately, but haven't reallocated a new person. ------------------------------------------------------- Date: 2001-Jan-09 14:38 By: tim_one Comment: Reassigned to MarkH. Mark, sound familiar? ------------------------------------------------------- Date: 2001-Jan-08 18:02 By: gvanrossum Comment: Assigned to Tim. First task would be to request needed infromation from submitter. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128040&group_id=5470 From noreply@sourceforge.net Wed Jan 10 08:37:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 00:37:50 -0800 Subject: [Python-bugs-list] [Bug #128210] Threads using same stream blow up (Windows) Message-ID: Bug #128210, was updated on 2001-Jan-09 13:10 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: 3rd Party Priority: 1 Submitted by: tim_one Assigned to : nobody Summary: Threads using same stream blow up (Windows) Details: Blows up under released Windows 2.0 and CVS Pythons (so it's not due to anything new): import thread def read(f): import time time.sleep(.01) n = 0 while n < 1000000: x = f.readline() n += len(x) print "r", print "read " + `n` m.release() m = thread.allocate_lock() f = open("ga", "w+") print "opened" m.acquire() thread.start_new_thread(read, (f,)) n = 0 x = "x" * 113 + "\n" while n < 1000000: f.write(x) print "w", n += len(x) m.acquire() print "done" Typical run: C:\Python20>\code\python\dist\src\pcbuild\python temp.py opened w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r r w r w r w r w r w r and then it dies in msvcrt.dll with a bad pointer. Also dies under the debugger (yay!) ... always dies like so: + We (Python) call the MS fwrite, from fileobject.c file_write. + MS fwrite succeeds with its _lock_str(stream) call. + MS fwrite then calls MS _fwrite_lk. + MS _fwrite_lk calls memcpy, which blows up for a non-obvious reason. Looks like the stream's _cnt member has gone mildly negative, which _fwrite_lk casts to unsigned and so treats like a giant positive count, and so memcpy eventually runs off the end of the process address space. Only thing I can conclude from this is that MS's internal stream-locking implementation is buggy. At least on W98SE. Other flavors of Windows? Other platforms? Note that I don't claim the program above is *sensible*, just that it shouldn't blow up. Alas, short of adding a separate mutex in Python file objects-- or writing our own stdio --I don't believe I can fix this. Follow-Ups: Date: 2001-Jan-10 00:37 By: tim_one Comment: Here's a standalone C program with the same symptom: #include #include static FILE* fp; void reader(void* irrelevant) { char buf[100]; for (;;) { char* p = fgets(buf, sizeof buf, fp); if (p) { putchar('r'); } } } void main() { int i; char string[100]; for (i = 0; i < sizeof(string) - 1; ++i) { string[i] = 'x'; } string[sizeof(string) - 1] = '\n'; fp = fopen("whatever", "w+"); _beginthread(reader, 0, NULL); for (;;) { fwrite(string, 1, sizeof(string), fp); putchar('w'); } } ------------------------------------------------------- Date: 2001-Jan-09 14:41 By: tim_one Comment: Adding info communicated via email: + Also blows up under Windows 2000. + Yes, C doesn't define what happens here even if it weren't threaded (you can't mix reads and writes willy-nilly (without e.g. seeking before reading) and expect something sensible). The program is not sensible. But even silly programs shouldn't *blow up* in Python. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128210&group_id=5470 From noreply@sourceforge.net Wed Jan 10 14:17:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 06:17:17 -0800 Subject: [Python-bugs-list] [Bug #128040] memory leak with multiple Py_Initialize/Py_Finalize calls Message-ID: Bug #128040, was updated on 2001-Jan-08 07:00 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: pbmtl Assigned to : gvanrossum Summary: memory leak with multiple Py_Initialize/Py_Finalize calls Details: I run script that use the win32 extension embedded in a server. When I call the Py_Finalize method, the memory is not free completely. Each time I run a script, my server uses more and more memory. I think the Patch #101713 talk about this problem. It seems that python have problem handling multiple Py_Initialize and Py_Finalise when extension are used. Follow-Ups: Date: 2001-Jan-10 06:17 By: pbmtl Comment: I agree with you that it's not that important when script are executed using PythonWin for example, because when PythonWin is closed, the memory is recover. But if you use python embedded in a server on a remote computer that is never supposed to be stopped, it's a real problem. The memory usage increase rapidly, Hundreds KB at each execution in my case. In fact, I can't call PyInitialize and PyFinalize for each script because if I do, the second script to be executed will not work correctly (the call to PyEval_CallObject will return an error). I use the Py_NewInterpreter and the Py_EndInterpreter. For my part, I think the script virtual machine should be responsable of the memory created by the scripts. Otherwise, there is no garanty that the PyFinalyze will free the memory correctly. Thanks ------------------------------------------------------- Date: 2001-Jan-09 21:20 By: tim_one Comment: Thank you, Mark! Since nobody is going to volunteer to do all this stuff, and everyone else will try to stop them if they did , I reassigned it to Guido -- it's never going to get done if he doesn't push for it (and if he doesn't think it's worth the effort, that's fine too, but that's his call). ------------------------------------------------------- Date: 2001-Jan-09 17:11 By: mhammond Comment: I dont believe this is Windows specific, nor specific to the Win32 extensions. I can confirm that Python does leak with multiple Init/Terms, as I had to change the COM extensions to only initialize once (and hence never finalize). It is definitely related to the referenced patch (#101713) This has been raised before, but there doesnt appear much enthusiasm for a fix. As far as I can tell, it would involve having Py_Finalize() correctly release _all_ memory allocated by Py_Initialize(). However, I have seen numerous people state that "one off" allocations that are not freed are not worth finding and freeing - however, if this bug wants a fix, then we must track them all down. I further note that the problem is not only in the Python core, but in extension modules. Modules need a reliable way to be told that Python is finalizing so they can free their own "one off" allocations. Various hacks have been proposed for this (eg, rely on ref-count semantics to ensure that a special object is destroyed as the module dict is cleared) but nothing "reasonable" has been proposed. Really not sure what I can do here. I am willing to do my bit in patching up the leaks, but would want a (fuzzy) commitment from python-dev that I wouldnt be doing it alone, and that it is seen as important. I have updated the bug description and platform appropriately, but haven't reallocated a new person. ------------------------------------------------------- Date: 2001-Jan-09 14:38 By: tim_one Comment: Reassigned to MarkH. Mark, sound familiar? ------------------------------------------------------- Date: 2001-Jan-08 18:02 By: gvanrossum Comment: Assigned to Tim. First task would be to request needed infromation from submitter. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128040&group_id=5470 From noreply@sourceforge.net Wed Jan 10 14:43:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 06:43:01 -0800 Subject: [Python-bugs-list] [Bug #128223] Typo in saxutils.py Message-ID: Bug #128223, was updated on 2001-Jan-09 14:15 Here is a current snapshot of the bug. Project: Python Category: XML Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: malraux Assigned to : fdrake Summary: Typo in saxutils.py Details: Line 221 of saxutils.py in the Python 2.0 (#1, Oct 16 2000, 18:10:03) release is: f.setSystemId(f.name) It should be: source.setSystemId(f.name) If you pass an existing open file object into the parse routine, line 221 will throw "AttributeError: setSystemId". For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128223&group_id=5470 From noreply@sourceforge.net Wed Jan 10 14:48:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 06:48:50 -0800 Subject: [Python-bugs-list] [Bug #128210] Threads using same stream blow up (Windows) Message-ID: Bug #128210, was updated on 2001-Jan-09 13:10 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: 3rd Party Priority: 1 Submitted by: tim_one Assigned to : nobody Summary: Threads using same stream blow up (Windows) Details: Blows up under released Windows 2.0 and CVS Pythons (so it's not due to anything new): import thread def read(f): import time time.sleep(.01) n = 0 while n < 1000000: x = f.readline() n += len(x) print "r", print "read " + `n` m.release() m = thread.allocate_lock() f = open("ga", "w+") print "opened" m.acquire() thread.start_new_thread(read, (f,)) n = 0 x = "x" * 113 + "\n" while n < 1000000: f.write(x) print "w", n += len(x) m.acquire() print "done" Typical run: C:\Python20>\code\python\dist\src\pcbuild\python temp.py opened w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r r w r w r w r w r w r and then it dies in msvcrt.dll with a bad pointer. Also dies under the debugger (yay!) ... always dies like so: + We (Python) call the MS fwrite, from fileobject.c file_write. + MS fwrite succeeds with its _lock_str(stream) call. + MS fwrite then calls MS _fwrite_lk. + MS _fwrite_lk calls memcpy, which blows up for a non-obvious reason. Looks like the stream's _cnt member has gone mildly negative, which _fwrite_lk casts to unsigned and so treats like a giant positive count, and so memcpy eventually runs off the end of the process address space. Only thing I can conclude from this is that MS's internal stream-locking implementation is buggy. At least on W98SE. Other flavors of Windows? Other platforms? Note that I don't claim the program above is *sensible*, just that it shouldn't blow up. Alas, short of adding a separate mutex in Python file objects-- or writing our own stdio --I don't believe I can fix this. Follow-Ups: Date: 2001-Jan-10 06:48 By: gvanrossum Comment: Mixing reads and writes on the same stream is always a bad idea. I believe that the stdio docs prescribe that you must use fflush() whenever switching between reading and writing. We could enforce this by adding two flags, "reading" and "writing" to the file object. (It's possible that using fseek() is also allowed to change directions.) I'm not sure tht this is worth fixing though -- no sensible programmer will do this. ------------------------------------------------------- Date: 2001-Jan-10 00:37 By: tim_one Comment: Here's a standalone C program with the same symptom: #include #include static FILE* fp; void reader(void* irrelevant) { char buf[100]; for (;;) { char* p = fgets(buf, sizeof buf, fp); if (p) { putchar('r'); } } } void main() { int i; char string[100]; for (i = 0; i < sizeof(string) - 1; ++i) { string[i] = 'x'; } string[sizeof(string) - 1] = '\n'; fp = fopen("whatever", "w+"); _beginthread(reader, 0, NULL); for (;;) { fwrite(string, 1, sizeof(string), fp); putchar('w'); } } ------------------------------------------------------- Date: 2001-Jan-09 14:41 By: tim_one Comment: Adding info communicated via email: + Also blows up under Windows 2000. + Yes, C doesn't define what happens here even if it weren't threaded (you can't mix reads and writes willy-nilly (without e.g. seeking before reading) and expect something sensible). The program is not sensible. But even silly programs shouldn't *blow up* in Python. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128210&group_id=5470 From noreply@sourceforge.net Wed Jan 10 15:13:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 07:13:29 -0800 Subject: [Python-bugs-list] [Bug #128223] Typo in saxutils.py Message-ID: Bug #128223, was updated on 2001-Jan-09 14:15 Here is a current snapshot of the bug. Project: Python Category: XML Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: malraux Assigned to : larsga Summary: Typo in saxutils.py Details: Line 221 of saxutils.py in the Python 2.0 (#1, Oct 16 2000, 18:10:03) release is: f.setSystemId(f.name) It should be: source.setSystemId(f.name) If you pass an existing open file object into the parse routine, line 221 will throw "AttributeError: setSystemId". Follow-Ups: Date: 2001-Jan-10 07:13 By: fdrake Comment: Already fixed in Lib/xml/sax/saxutils.py revision 1.13, by Lars Garshol. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128223&group_id=5470 From noreply@sourceforge.net Wed Jan 10 16:03:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 08:03:59 -0800 Subject: [Python-bugs-list] [Bug #128079] memory leak in pyexpat parser Message-ID: Bug #128079, was updated on 2001-Jan-08 12:09 Here is a current snapshot of the bug. Project: Python Category: XML Status: Closed Resolution: Invalid Bug Group: Not a Bug Priority: 5 Submitted by: nobody Assigned to : fdrake Summary: memory leak in pyexpat parser Details: Hi, I am having a problem with memroy when I am running a python program which has a code similar to this. from xml.dom import minidom while 1: doc = minidom.parse('text.xml') print doc del doc The memory size keeps incrementing as the loop is executed.This is the text.xml file 50008 10 10 10 10 I am trying to delete it manually even then the memory size is increasing. Please I need some help . Thanks kishore Follow-Ups: Date: 2001-Jan-10 08:03 By: fdrake Comment: This has to do with minidom, not pyexpat. minidom creates internal circular references which need to be cleared by calling the .unlink() method on the document object. See the development copy of the documentation for more information: http://python.sourceforge.net/devel-docs/lib/module-xml.dom.minidom.html ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128079&group_id=5470 From noreply@sourceforge.net Wed Jan 10 16:07:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 08:07:06 -0800 Subject: [Python-bugs-list] [Bug #116388] cStringIO rejects Unicode strings Message-ID: Bug #116388, was updated on 2000-Oct-08 17:42 Here is a current snapshot of the bug. Project: Python Category: Unicode Status: Open Resolution: Later Bug Group: Feature Request Priority: 5 Submitted by: prescod Assigned to : fdrake Summary: cStringIO rejects Unicode strings Details: >>> import cStringIO >>> s=cStringIO.StringIO(u"abcdefgh") Traceback (innermost last): File "", line 1, in ? s=cStringIO.StringIO(u"abcdefgh") TypeError: expected string, unicode found Follow-Ups: Date: 2001-Jan-10 08:07 By: fdrake Comment: Status: Jim said I can work on it, but the priority isn't very high for him. ------------------------------------------------------- Date: 2001-Jan-07 19:56 By: fdrake Comment: Ok, ok, ok... I've sent a prod to appropriate people. This *should* be interesting to have done. ------------------------------------------------------- Date: 2000-Dec-12 13:00 By: gvanrossum Comment: Assigned to Fred -- maybe you can prod Jim into looking into this. ------------------------------------------------------- Date: 2000-Oct-09 01:34 By: lemburg Comment: I've marked this as feature request since making the standard lib Unicode compatible is a post-2.0 project (probably a good one for 2.1). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=116388&group_id=5470 From noreply@sourceforge.net Wed Jan 10 16:59:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 08:59:22 -0800 Subject: [Python-bugs-list] [Bug #128040] memory leak with multiple Py_Initialize/Py_Finalize calls Message-ID: Bug #128040, was updated on 2001-Jan-08 07:00 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: pbmtl Assigned to : gvanrossum Summary: memory leak with multiple Py_Initialize/Py_Finalize calls Details: I run script that use the win32 extension embedded in a server. When I call the Py_Finalize method, the memory is not free completely. Each time I run a script, my server uses more and more memory. I think the Patch #101713 talk about this problem. It seems that python have problem handling multiple Py_Initialize and Py_Finalise when extension are used. Follow-Ups: Date: 2001-Jan-10 08:59 By: gvanrossum Comment: I agree with Mark that in the past we have been lax in addressing these kinds of problems. I do wish to fix these in the future! It's just hard to find all the leaks. In the past we had reports where a simple loop calling Py_Initialize() and Py_Finalize() with nothing in between would leak; we've fixed these. But now if you put real work in between it still seems to leak. I'll see if I can check in a test program in the Demo tree which Barry can then work on using Insure++. pbmtl, when you write that "the call to PyEval_CallObject will return an error", can you submit a separate bug report for that with enough details (e.g. C source code) so that we can reproduce the problem? This seems to be a separate bug, unrelated to leakage! ------------------------------------------------------- Date: 2001-Jan-10 06:17 By: pbmtl Comment: I agree with you that it's not that important when script are executed using PythonWin for example, because when PythonWin is closed, the memory is recover. But if you use python embedded in a server on a remote computer that is never supposed to be stopped, it's a real problem. The memory usage increase rapidly, Hundreds KB at each execution in my case. In fact, I can't call PyInitialize and PyFinalize for each script because if I do, the second script to be executed will not work correctly (the call to PyEval_CallObject will return an error). I use the Py_NewInterpreter and the Py_EndInterpreter. For my part, I think the script virtual machine should be responsable of the memory created by the scripts. Otherwise, there is no garanty that the PyFinalyze will free the memory correctly. Thanks ------------------------------------------------------- Date: 2001-Jan-09 21:20 By: tim_one Comment: Thank you, Mark! Since nobody is going to volunteer to do all this stuff, and everyone else will try to stop them if they did , I reassigned it to Guido -- it's never going to get done if he doesn't push for it (and if he doesn't think it's worth the effort, that's fine too, but that's his call). ------------------------------------------------------- Date: 2001-Jan-09 17:11 By: mhammond Comment: I dont believe this is Windows specific, nor specific to the Win32 extensions. I can confirm that Python does leak with multiple Init/Terms, as I had to change the COM extensions to only initialize once (and hence never finalize). It is definitely related to the referenced patch (#101713) This has been raised before, but there doesnt appear much enthusiasm for a fix. As far as I can tell, it would involve having Py_Finalize() correctly release _all_ memory allocated by Py_Initialize(). However, I have seen numerous people state that "one off" allocations that are not freed are not worth finding and freeing - however, if this bug wants a fix, then we must track them all down. I further note that the problem is not only in the Python core, but in extension modules. Modules need a reliable way to be told that Python is finalizing so they can free their own "one off" allocations. Various hacks have been proposed for this (eg, rely on ref-count semantics to ensure that a special object is destroyed as the module dict is cleared) but nothing "reasonable" has been proposed. Really not sure what I can do here. I am willing to do my bit in patching up the leaks, but would want a (fuzzy) commitment from python-dev that I wouldnt be doing it alone, and that it is seen as important. I have updated the bug description and platform appropriately, but haven't reallocated a new person. ------------------------------------------------------- Date: 2001-Jan-09 14:38 By: tim_one Comment: Reassigned to MarkH. Mark, sound familiar? ------------------------------------------------------- Date: 2001-Jan-08 18:02 By: gvanrossum Comment: Assigned to Tim. First task would be to request needed infromation from submitter. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128040&group_id=5470 From noreply@sourceforge.net Wed Jan 10 17:15:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 09:15:14 -0800 Subject: [Python-bugs-list] [Bug #128302] Repeatedly initializing the interpreter dumps core Message-ID: Bug #128302, was updated on 2001-Jan-10 09:15 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: None Priority: 4 Submitted by: gvanrossum Assigned to : nobody Summary: Repeatedly initializing the interpreter dumps core Details: I've checked in a simple test program: Demo/embed/loop.c. If you run "make looptest" in this directory, you should get a few lines of 'hello world' followed by a core dump. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128302&group_id=5470 From noreply@sourceforge.net Wed Jan 10 18:33:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 10:33:41 -0800 Subject: [Python-bugs-list] [Bug #128210] Threads using same stream blow up (Windows) Message-ID: Bug #128210, was updated on 2001-Jan-09 13:10 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: 3rd Party Priority: 1 Submitted by: tim_one Assigned to : nobody Summary: Threads using same stream blow up (Windows) Details: Blows up under released Windows 2.0 and CVS Pythons (so it's not due to anything new): import thread def read(f): import time time.sleep(.01) n = 0 while n < 1000000: x = f.readline() n += len(x) print "r", print "read " + `n` m.release() m = thread.allocate_lock() f = open("ga", "w+") print "opened" m.acquire() thread.start_new_thread(read, (f,)) n = 0 x = "x" * 113 + "\n" while n < 1000000: f.write(x) print "w", n += len(x) m.acquire() print "done" Typical run: C:\Python20>\code\python\dist\src\pcbuild\python temp.py opened w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r r w r w r w r w r w r and then it dies in msvcrt.dll with a bad pointer. Also dies under the debugger (yay!) ... always dies like so: + We (Python) call the MS fwrite, from fileobject.c file_write. + MS fwrite succeeds with its _lock_str(stream) call. + MS fwrite then calls MS _fwrite_lk. + MS _fwrite_lk calls memcpy, which blows up for a non-obvious reason. Looks like the stream's _cnt member has gone mildly negative, which _fwrite_lk casts to unsigned and so treats like a giant positive count, and so memcpy eventually runs off the end of the process address space. Only thing I can conclude from this is that MS's internal stream-locking implementation is buggy. At least on W98SE. Other flavors of Windows? Other platforms? Note that I don't claim the program above is *sensible*, just that it shouldn't blow up. Alas, short of adding a separate mutex in Python file objects-- or writing our own stdio --I don't believe I can fix this. Follow-Ups: Date: 2001-Jan-10 10:33 By: tim_one Comment: Guido, I've said multiple times (and in this very bug report!) that the program isn't sensible. That isn't the point. Having multiple threads even just reading from the same stream without explicit user locks isn't sensible either, and you can't have it both ways: on Python-Dev you said the point to using FLOCKFILE in get_line was to prevent core dumps in case the user was doing multiple reads by *accident*. That's fine: I agree, and a file open for update is likely just as prone to mixed read/write "accidents". As far as the std goes, input following output should have intervening fflush, fseek, fsetpos or rewind; while output following input should-- unless input hit EOF --have intervening fseek, fsetpos or rewind (not fflush, though! fflush immediately after input is undefined). Adding flags to the file object doesn't seem to help much, because the combo of e.g. "I'm doing a read now" and "I'm setting the 'reading' flag" needs to be atomic in a threaded world else it's unreliable (and then you're back to Python-level locks to repair that). Does this blow up on Linux for you? That's more interesting to me. I've implemented stdio in the past, and I think what's happening here is quite likely what it looks like: a bug in MS's file-locking (the _cnt member just doesn't go negative if the FILE* struct is properly locked during manipulations!). If that's true, this is surely rare enough that we can wait for MS to fix it. But in the meantime, it is a way to get Python to coredump on Windows. ------------------------------------------------------- Date: 2001-Jan-10 06:48 By: gvanrossum Comment: Mixing reads and writes on the same stream is always a bad idea. I believe that the stdio docs prescribe that you must use fflush() whenever switching between reading and writing. We could enforce this by adding two flags, "reading" and "writing" to the file object. (It's possible that using fseek() is also allowed to change directions.) I'm not sure tht this is worth fixing though -- no sensible programmer will do this. ------------------------------------------------------- Date: 2001-Jan-10 00:37 By: tim_one Comment: Here's a standalone C program with the same symptom: #include #include static FILE* fp; void reader(void* irrelevant) { char buf[100]; for (;;) { char* p = fgets(buf, sizeof buf, fp); if (p) { putchar('r'); } } } void main() { int i; char string[100]; for (i = 0; i < sizeof(string) - 1; ++i) { string[i] = 'x'; } string[sizeof(string) - 1] = '\n'; fp = fopen("whatever", "w+"); _beginthread(reader, 0, NULL); for (;;) { fwrite(string, 1, sizeof(string), fp); putchar('w'); } } ------------------------------------------------------- Date: 2001-Jan-09 14:41 By: tim_one Comment: Adding info communicated via email: + Also blows up under Windows 2000. + Yes, C doesn't define what happens here even if it weren't threaded (you can't mix reads and writes willy-nilly (without e.g. seeking before reading) and expect something sensible). The program is not sensible. But even silly programs shouldn't *blow up* in Python. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128210&group_id=5470 From noreply@sourceforge.net Wed Jan 10 21:19:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jan 2001 13:19:49 -0800 Subject: [Python-bugs-list] [Bug #125744] httplib does not check if port is valid (easy to fix?) Message-ID: Bug #125744, was updated on 2000-Dec-13 20:45 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: dealfaro Assigned to : jhylton Summary: httplib does not check if port is valid (easy to fix?) Details: In httplib.py, line 336, the following code appears: def _set_hostport(self, host, port): if port is None: i = string.find(host, ':') if i >= 0: port = int(host[i+1:]) host = host[:i] else: port = self.default_port self.host = host self.port = port Ths code breaks if the host string ends with ":", so that int("") is called. In the old (1.5.2) version of this module, the corresponding int () conversion used to be enclosed in a try/except pair: try: port = string.atoi(port) except string.atoi_error: raise socket.error, "nonnumeric port" and this fixed the problem. Note BTW that now the error reported by int is "ValueError: invalid literal for int():" rather than the above string.atoi_error. I found this problem while downloading web pages, but unfortunately I cannot pinpoint which page caused the problem. Luca de Alfaro Follow-Ups: Date: 2001-Jan-10 13:19 By: martinthomas Comment: I have been trying to pin down a problem in Redhat's Update agent which is written in Python (..mostly) which happens when a proxy is specified. In RH7.0, they are still using Python 1.5.2 and the message 'nonnumeric port' is received when a proxy is specified in the following form: http://proxy.yourdomain.com:80 but the following: proxy.yourdomain.com:80 works.. looking at the code, it seems that it expects that the only colon would be near the end of the url and makes no allowance for 'http:' nor 'https:'... Regards / Martin ------------------------------------------------------- Date: 2000-Dec-18 14:38 By: gvanrossum Comment: Thanks for explaining this more. I am surprised that a 301 redirect would give an invalid port -- but surely webmasters aren't perfect. :-) The argument that urllib.Urlopener.open() checks for socket.error but not for other errors is a good one. However I don't see the httplib.py code raising socket.error elsewhere. I'll ask Jeremy. The rest of the module seems to be using a totally different set of exceptions. On the other hand, it *can* raise socket.error, implicitly (when various socket calls are being made). ------------------------------------------------------- Date: 2000-Dec-18 14:25 By: dealfaro Comment: There are three (minor?) problems with raising ValueError. 1) Compatibility. I had some code for 1.5.2 that was trying to load web pages checking for various errors, and it was expecting this error to cause a socket error, not a value error. 2) Accuracy. ValueError can be caused by anything. The 'non-numeric port' error is much more informative. I don't want to catch ValueError, because it can be caused in too many situations. I also cannot check myself that the port is fine, because the port and the URL are often given by a redirect (errors 301 and 302, if I remember correctly). This in fact was the situation that caused the problem. Hence, my only real solution was to patch my version of httplib. 3) Style. I am somewhat new to Python, but I was under the impression that, stilistically, a ValueError was used to convey a situation that was the fault of the programmer, while other more specific errors were used for unexpected situations (communication, etc). Since the socket is the result of a URL redirection (errors 301 or 302), the programmer is not in a position to prevent this error by "better checking". Hence, I would consider a network-relted exception to be more appropriate here. But who am I to argue with the creator of Python? ;-) Luca ------------------------------------------------------- Date: 2000-Dec-14 06:37 By: gvanrossum Comment: The only effect is that it raises ValueError instead of socket.error. Where is this a problem? (Note that string.atoi_error is an alias for ValueError.) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=125744&group_id=5470 From noreply@sourceforge.net Thu Jan 11 14:59:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jan 2001 06:59:17 -0800 Subject: [Python-bugs-list] [Bug #128210] Threads using same stream blow up (Windows) Message-ID: Bug #128210, was updated on 2001-Jan-09 13:10 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: 3rd Party Priority: 1 Submitted by: tim_one Assigned to : nobody Summary: Threads using same stream blow up (Windows) Details: Blows up under released Windows 2.0 and CVS Pythons (so it's not due to anything new): import thread def read(f): import time time.sleep(.01) n = 0 while n < 1000000: x = f.readline() n += len(x) print "r", print "read " + `n` m.release() m = thread.allocate_lock() f = open("ga", "w+") print "opened" m.acquire() thread.start_new_thread(read, (f,)) n = 0 x = "x" * 113 + "\n" while n < 1000000: f.write(x) print "w", n += len(x) m.acquire() print "done" Typical run: C:\Python20>\code\python\dist\src\pcbuild\python temp.py opened w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r r w r w r w r w r w r and then it dies in msvcrt.dll with a bad pointer. Also dies under the debugger (yay!) ... always dies like so: + We (Python) call the MS fwrite, from fileobject.c file_write. + MS fwrite succeeds with its _lock_str(stream) call. + MS fwrite then calls MS _fwrite_lk. + MS _fwrite_lk calls memcpy, which blows up for a non-obvious reason. Looks like the stream's _cnt member has gone mildly negative, which _fwrite_lk casts to unsigned and so treats like a giant positive count, and so memcpy eventually runs off the end of the process address space. Only thing I can conclude from this is that MS's internal stream-locking implementation is buggy. At least on W98SE. Other flavors of Windows? Other platforms? Note that I don't claim the program above is *sensible*, just that it shouldn't blow up. Alas, short of adding a separate mutex in Python file objects-- or writing our own stdio --I don't believe I can fix this. Follow-Ups: Date: 2001-Jan-11 06:59 By: gvanrossum Comment: I knew it wasn't sensible (I did read what you wrote). I just don't like having bug reports that we can't do something about without a lot of hackery. I've seen stdio implementations before that were totally naive about mixing reads and writes, even in a single-threaded program. That said, I can't get this to crash on Linux. ------------------------------------------------------- Date: 2001-Jan-10 10:33 By: tim_one Comment: Guido, I've said multiple times (and in this very bug report!) that the program isn't sensible. That isn't the point. Having multiple threads even just reading from the same stream without explicit user locks isn't sensible either, and you can't have it both ways: on Python-Dev you said the point to using FLOCKFILE in get_line was to prevent core dumps in case the user was doing multiple reads by *accident*. That's fine: I agree, and a file open for update is likely just as prone to mixed read/write "accidents". As far as the std goes, input following output should have intervening fflush, fseek, fsetpos or rewind; while output following input should-- unless input hit EOF --have intervening fseek, fsetpos or rewind (not fflush, though! fflush immediately after input is undefined). Adding flags to the file object doesn't seem to help much, because the combo of e.g. "I'm doing a read now" and "I'm setting the 'reading' flag" needs to be atomic in a threaded world else it's unreliable (and then you're back to Python-level locks to repair that). Does this blow up on Linux for you? That's more interesting to me. I've implemented stdio in the past, and I think what's happening here is quite likely what it looks like: a bug in MS's file-locking (the _cnt member just doesn't go negative if the FILE* struct is properly locked during manipulations!). If that's true, this is surely rare enough that we can wait for MS to fix it. But in the meantime, it is a way to get Python to coredump on Windows. ------------------------------------------------------- Date: 2001-Jan-10 06:48 By: gvanrossum Comment: Mixing reads and writes on the same stream is always a bad idea. I believe that the stdio docs prescribe that you must use fflush() whenever switching between reading and writing. We could enforce this by adding two flags, "reading" and "writing" to the file object. (It's possible that using fseek() is also allowed to change directions.) I'm not sure tht this is worth fixing though -- no sensible programmer will do this. ------------------------------------------------------- Date: 2001-Jan-10 00:37 By: tim_one Comment: Here's a standalone C program with the same symptom: #include #include static FILE* fp; void reader(void* irrelevant) { char buf[100]; for (;;) { char* p = fgets(buf, sizeof buf, fp); if (p) { putchar('r'); } } } void main() { int i; char string[100]; for (i = 0; i < sizeof(string) - 1; ++i) { string[i] = 'x'; } string[sizeof(string) - 1] = '\n'; fp = fopen("whatever", "w+"); _beginthread(reader, 0, NULL); for (;;) { fwrite(string, 1, sizeof(string), fp); putchar('w'); } } ------------------------------------------------------- Date: 2001-Jan-09 14:41 By: tim_one Comment: Adding info communicated via email: + Also blows up under Windows 2000. + Yes, C doesn't define what happens here even if it weren't threaded (you can't mix reads and writes willy-nilly (without e.g. seeking before reading) and expect something sensible). The program is not sensible. But even silly programs shouldn't *blow up* in Python. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128210&group_id=5470 From noreply@sourceforge.net Thu Jan 11 19:05:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jan 2001 11:05:19 -0800 Subject: [Python-bugs-list] [Bug #128475] mimetools.encode (sometimes) fails when called from a thread Message-ID: Bug #128475, was updated on 2001-Jan-11 11:05 Here is a current snapshot of the bug. Project: Python Category: Threads Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : nobody Summary: mimetools.encode (sometimes) fails when called from a thread Details: I used this script to test. The code of filesender.prepare_msgs is at the end of the report. ## import threading import filesender file = open('c:/windows/desktop/mp3/Aphex Twin - Bucephalus Bouncing Ball.mp3', 'rb') t1 = threading.Thread(target=filesender.prepare_msgs, args=(file,'a@b.c')) from cStringIO import StringIO data = StringIO() import mimetools t2=threading.Thread(target=mimetools.encode, args=(file,data,'base64')) import sys if '-t1' in sys.argv: t1.start() elif '-t2' in sys.argv: t2.start() else: filesender.prepare_msgs(file, 'a@b.c') ## Results of running it with -t1, -t2, and no options, on Windows: C:\Python20>python test.py -t1 preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 Fatal Python error: Interpreter not initialized (version mismatch?) abnormal program termination C:\Python20>python test.py -t1 preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 Fatal Python error: Interpreter not initialized (version mismatch?) abnormal program termination C:\Python20>python test.py -t2 Fatal Python error: Interpreter not initialized (version mismatch?) abnormal program termination C:\Python20>python test.py -t2 C:\Python20>python test.py preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 encoded got value data length is 7807732 Encoded Aphex Twin - Bucephalus Bouncing Ball.mp3 is too large, splitting into 2 parts C:\Python20>python test.py preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 encoded got value data length is 7807732 Encoded Aphex Twin - Bucephalus Bouncing Ball.mp3 is too large, splitting into 2 parts On Linux: wolfson@senator:~% python test.py preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 encoded got value data length is 7807732 Encoded Aphex Twin - Bucephalus Bouncing Ball.mp3 is too large, splitting into 2 p arts wolfson@senator:~% python test.py -t1 preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 Fatal Python error: Interpreter not initialized (version mismatch?) Abort wolfson@senator:~% python test.py -t1 preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 Fatal Python error: Interpreter not initialized (version mismatch?) Abort wolfson@senator:~% python test.py -t2 Fatal Python error: Interpreter not initialized (version mismatch?) Abort wolfson@senator:~% python test.py -t2 Fatal Python error: Interpreter not initialized (version mismatch?) Abort wolfson@senator:~% python test.py -t2 Fatal Python error: Interpreter not initialized (version mismatch?) Abort On Sun 5 it seems to always succeed. The code for filesender.prepare_msgs: def prepare_msgs(file, addressee): data = StringIO.StringIO() fn = getname(file) print 'preparing %s' % fn mimetools.encode(file, data, 'base64') print 'encoded' data = data.getvalue() print 'got value' datalen = len(data) print 'data length is %d' % datalen if datalen > MAX_MSG_SZ: numsplits = 1 + datalen / MAX_MSG_SZ print 'Encoded %s is too large, splitting into %d parts' % (fn,numsplits) msgs = [] for i in range(numsplits): thismsg, data = data[:MAX_MSG_SZ], data[MAX_MSG_SZ:] msgs.append(fmt_message(fn, addressee, thismsg, '(%d/%d)' % (i+1, numsplits), MSG)) return msgs return [fmt_message(fn, addressee, data, '', MSG)] For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128475&group_id=5470 From noreply@sourceforge.net Thu Jan 11 22:51:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jan 2001 14:51:31 -0800 Subject: [Python-bugs-list] [Bug #128251] Windows mmap docs need cleaning Message-ID: Bug #128251, was updated on 2001-Jan-09 21:14 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 6 Submitted by: tim_one Assigned to : akuchling Summary: Windows mmap docs need cleaning Details: WRT the docs for the Windows flavor of mmap.mmap(): 1) Doc needed: The file *must* be opened for update (r+, w+, rb+ or wb+). That's because CreateFileMapping is called with PAGE_READWRITE, and that won't let you increase permissions over the original open mode. Violating this yields baffling "The parameter is wrong" Windows errors from mmap.mmap(). 2) Doc needed: Passing a size of 0 makes the maximum size of the mapping the actual current size of the file. Don't know whether that's also true on Unices (ask AMK?); on Windows it's intentional; and it's handy to know so it's worth documenting. 3) Doc bug: The docs read as if omitting the optional tagname is different than supplying a tagname of None. I don't believe that's true; needs mild rewording. Fred and AMK and c.l.py got a longer version of this msg. I think the example of using mmap with re would be worth including too (but it would be nice to have an example that isn't Windows-specific! someone should try that on Linux too, and fiddle as needed). Follow-Ups: Date: 2001-Jan-11 14:51 By: fdrake Comment: I've updated the documentation according to Tim's comments in Doc/lib/libmmap.tex revision 1.4. Andrew: do you know anything about passing a length of zero on Unix? I wasn't able to find anything in the mmap() man page, and don't have ready access to any other reference material at this time. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128251&group_id=5470 From noreply@sourceforge.net Fri Jan 12 03:48:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jan 2001 19:48:19 -0800 Subject: [Python-bugs-list] [Bug #128210] Threads using same stream blow up (Windows) Message-ID: Bug #128210, was updated on 2001-Jan-09 13:10 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Closed Resolution: Wont Fix Bug Group: 3rd Party Priority: 1 Submitted by: tim_one Assigned to : tim_one Summary: Threads using same stream blow up (Windows) Details: Blows up under released Windows 2.0 and CVS Pythons (so it's not due to anything new): import thread def read(f): import time time.sleep(.01) n = 0 while n < 1000000: x = f.readline() n += len(x) print "r", print "read " + `n` m.release() m = thread.allocate_lock() f = open("ga", "w+") print "opened" m.acquire() thread.start_new_thread(read, (f,)) n = 0 x = "x" * 113 + "\n" while n < 1000000: f.write(x) print "w", n += len(x) m.acquire() print "done" Typical run: C:\Python20>\code\python\dist\src\pcbuild\python temp.py opened w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r w r r w r w r w r w r w r and then it dies in msvcrt.dll with a bad pointer. Also dies under the debugger (yay!) ... always dies like so: + We (Python) call the MS fwrite, from fileobject.c file_write. + MS fwrite succeeds with its _lock_str(stream) call. + MS fwrite then calls MS _fwrite_lk. + MS _fwrite_lk calls memcpy, which blows up for a non-obvious reason. Looks like the stream's _cnt member has gone mildly negative, which _fwrite_lk casts to unsigned and so treats like a giant positive count, and so memcpy eventually runs off the end of the process address space. Only thing I can conclude from this is that MS's internal stream-locking implementation is buggy. At least on W98SE. Other flavors of Windows? Other platforms? Note that I don't claim the program above is *sensible*, just that it shouldn't blow up. Alas, short of adding a separate mutex in Python file objects-- or writing our own stdio --I don't believe I can fix this. Follow-Ups: Date: 2001-Jan-11 19:48 By: tim_one Comment: Since this appears to be unique to Windows, appears to be a bug in Windows stdio, has got to be exceedingly rare in practice, and unreasonably difficult to worm around in the Python implementation, closing this as WontFix. ------------------------------------------------------- Date: 2001-Jan-11 06:59 By: gvanrossum Comment: I knew it wasn't sensible (I did read what you wrote). I just don't like having bug reports that we can't do something about without a lot of hackery. I've seen stdio implementations before that were totally naive about mixing reads and writes, even in a single-threaded program. That said, I can't get this to crash on Linux. ------------------------------------------------------- Date: 2001-Jan-10 10:33 By: tim_one Comment: Guido, I've said multiple times (and in this very bug report!) that the program isn't sensible. That isn't the point. Having multiple threads even just reading from the same stream without explicit user locks isn't sensible either, and you can't have it both ways: on Python-Dev you said the point to using FLOCKFILE in get_line was to prevent core dumps in case the user was doing multiple reads by *accident*. That's fine: I agree, and a file open for update is likely just as prone to mixed read/write "accidents". As far as the std goes, input following output should have intervening fflush, fseek, fsetpos or rewind; while output following input should-- unless input hit EOF --have intervening fseek, fsetpos or rewind (not fflush, though! fflush immediately after input is undefined). Adding flags to the file object doesn't seem to help much, because the combo of e.g. "I'm doing a read now" and "I'm setting the 'reading' flag" needs to be atomic in a threaded world else it's unreliable (and then you're back to Python-level locks to repair that). Does this blow up on Linux for you? That's more interesting to me. I've implemented stdio in the past, and I think what's happening here is quite likely what it looks like: a bug in MS's file-locking (the _cnt member just doesn't go negative if the FILE* struct is properly locked during manipulations!). If that's true, this is surely rare enough that we can wait for MS to fix it. But in the meantime, it is a way to get Python to coredump on Windows. ------------------------------------------------------- Date: 2001-Jan-10 06:48 By: gvanrossum Comment: Mixing reads and writes on the same stream is always a bad idea. I believe that the stdio docs prescribe that you must use fflush() whenever switching between reading and writing. We could enforce this by adding two flags, "reading" and "writing" to the file object. (It's possible that using fseek() is also allowed to change directions.) I'm not sure tht this is worth fixing though -- no sensible programmer will do this. ------------------------------------------------------- Date: 2001-Jan-10 00:37 By: tim_one Comment: Here's a standalone C program with the same symptom: #include #include static FILE* fp; void reader(void* irrelevant) { char buf[100]; for (;;) { char* p = fgets(buf, sizeof buf, fp); if (p) { putchar('r'); } } } void main() { int i; char string[100]; for (i = 0; i < sizeof(string) - 1; ++i) { string[i] = 'x'; } string[sizeof(string) - 1] = '\n'; fp = fopen("whatever", "w+"); _beginthread(reader, 0, NULL); for (;;) { fwrite(string, 1, sizeof(string), fp); putchar('w'); } } ------------------------------------------------------- Date: 2001-Jan-09 14:41 By: tim_one Comment: Adding info communicated via email: + Also blows up under Windows 2000. + Yes, C doesn't define what happens here even if it weren't threaded (you can't mix reads and writes willy-nilly (without e.g. seeking before reading) and expect something sensible). The program is not sensible. But even silly programs shouldn't *blow up* in Python. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128210&group_id=5470 From noreply@sourceforge.net Fri Jan 12 18:15:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 10:15:25 -0800 Subject: [Python-bugs-list] [Bug #114780] Rare hangs in w9xpopen.exe Message-ID: Bug #114780, was updated on 2000-Sep-19 01:50 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Closed Resolution: Wont Fix Bug Group: 3rd Party Priority: 1 Submitted by: tim_one Assigned to : mhammond Summary: Rare hangs in w9xpopen.exe Details: Every two or three days, when I'm running the std test suite on my Win98SE box, test_popen2 just hangs. wintop shows that w9xpopen.exe is alive, but not consuming any cycles. test_popen2.py is waiting on a .read(). No other clues. It *may* be the case that I'm establishing a modem connection near the time test_popen2 starts to run. I'll try to provoke that. Assigned to MarkH simply to share the misery . Mark, I don't expect you to "fix this", but I don't expect me to either -- it's just something we should both be aware of. Follow-Ups: Date: 2001-Jan-12 10:15 By: tim_one Comment: Closed as WontFix and 3rdParty, as there's no reason to believe we're missing anything we can fix. I still see hangs once or twice a week (here and in DevStudio). My only guess was that these may have coincided with establishing phone-modem connections, but I didn't get anywhere with that, and now that I have an "always on" cable modem instead there's no change in symtpoms or frequency. Smells like an OS bug. ------------------------------------------------------- Date: 2000-Oct-04 18:53 By: tim_one Comment: A (useless, alas) clue: every now & again, doing a Batch Build under MSVC hangs in midstream: Never makes progress, and Stop Build has no effect. Have to kill DevStudio via the task manager. Then things get *really* screwed up unless I also kill a leftover "vcspawn" task from the task manager. This suggests that Win98SE (or, at least, my copy of it) simply screws up spawning from time to time. I reduced the priority on this bug again, reflecting that I now suspect it's a platform bug we're not causing and can't cure. ------------------------------------------------------- Date: 2000-Sep-25 15:07 By: tim_one Comment: Just noting that I've been building and testing Python a *lot* since I entered this bug report, and haven't seen the problem again. ------------------------------------------------------- Date: 2000-Sep-19 05:51 By: gvanrossum Comment: Tim, do you remember the problem I had with using popen() from IDLE? I had code that essentially did os.popen("start "+url).close(). This worked fine in a DOS box but hung inexplicably for 30 seconds before returning and starting the browser when used in IDLE. The problem went away (the call returned immediately and the browser was started within 2-3 seconds) when I saved the pipe object in an instance variable. We never fixed this, but I tracked it down to probably something having to do with the need to pump events. Mark will understand. I don't doubt that popen2, popen3, popen4 all share this problem. (Check webbrowser.py, class WindowsDefault, for the current solution.) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=114780&group_id=5470 From noreply@sourceforge.net Fri Jan 12 21:15:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jan 2001 13:15:30 -0800 Subject: [Python-bugs-list] [Bug #128591] C-level GC API is not documented Message-ID: Bug #128591, was updated on 2001-Jan-12 13:15 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: Feature Request Priority: 6 Submitted by: fdrake Assigned to : nascheme Summary: C-level GC API is not documented Details: The C macros and functions needed to interface with the garbage collector and used to implement GC-aware types are not documented. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128591&group_id=5470 From noreply@sourceforge.net Sat Jan 13 16:13:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 08:13:38 -0800 Subject: [Python-bugs-list] [Bug #128475] mimetools.encode (sometimes) fails when called from a thread Message-ID: Bug #128475, was updated on 2001-Jan-11 11:05 Here is a current snapshot of the bug. Project: Python Category: Threads Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : nobody Summary: mimetools.encode (sometimes) fails when called from a thread Details: I used this script to test. The code of filesender.prepare_msgs is at the end of the report. ## import threading import filesender file = open('c:/windows/desktop/mp3/Aphex Twin - Bucephalus Bouncing Ball.mp3', 'rb') t1 = threading.Thread(target=filesender.prepare_msgs, args=(file,'a@b.c')) from cStringIO import StringIO data = StringIO() import mimetools t2=threading.Thread(target=mimetools.encode, args=(file,data,'base64')) import sys if '-t1' in sys.argv: t1.start() elif '-t2' in sys.argv: t2.start() else: filesender.prepare_msgs(file, 'a@b.c') ## Results of running it with -t1, -t2, and no options, on Windows: C:\Python20>python test.py -t1 preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 Fatal Python error: Interpreter not initialized (version mismatch?) abnormal program termination C:\Python20>python test.py -t1 preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 Fatal Python error: Interpreter not initialized (version mismatch?) abnormal program termination C:\Python20>python test.py -t2 Fatal Python error: Interpreter not initialized (version mismatch?) abnormal program termination C:\Python20>python test.py -t2 C:\Python20>python test.py preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 encoded got value data length is 7807732 Encoded Aphex Twin - Bucephalus Bouncing Ball.mp3 is too large, splitting into 2 parts C:\Python20>python test.py preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 encoded got value data length is 7807732 Encoded Aphex Twin - Bucephalus Bouncing Ball.mp3 is too large, splitting into 2 parts On Linux: wolfson@senator:~% python test.py preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 encoded got value data length is 7807732 Encoded Aphex Twin - Bucephalus Bouncing Ball.mp3 is too large, splitting into 2 p arts wolfson@senator:~% python test.py -t1 preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 Fatal Python error: Interpreter not initialized (version mismatch?) Abort wolfson@senator:~% python test.py -t1 preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 Fatal Python error: Interpreter not initialized (version mismatch?) Abort wolfson@senator:~% python test.py -t2 Fatal Python error: Interpreter not initialized (version mismatch?) Abort wolfson@senator:~% python test.py -t2 Fatal Python error: Interpreter not initialized (version mismatch?) Abort wolfson@senator:~% python test.py -t2 Fatal Python error: Interpreter not initialized (version mismatch?) Abort On Sun 5 it seems to always succeed. The code for filesender.prepare_msgs: def prepare_msgs(file, addressee): data = StringIO.StringIO() fn = getname(file) print 'preparing %s' % fn mimetools.encode(file, data, 'base64') print 'encoded' data = data.getvalue() print 'got value' datalen = len(data) print 'data length is %d' % datalen if datalen > MAX_MSG_SZ: numsplits = 1 + datalen / MAX_MSG_SZ print 'Encoded %s is too large, splitting into %d parts' % (fn,numsplits) msgs = [] for i in range(numsplits): thismsg, data = data[:MAX_MSG_SZ], data[MAX_MSG_SZ:] msgs.append(fmt_message(fn, addressee, thismsg, '(%d/%d)' % (i+1, numsplits), MSG)) return msgs return [fmt_message(fn, addressee, data, '', MSG)] Follow-Ups: Date: 2001-Jan-13 08:13 By: nobody Comment: I'll get you! ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128475&group_id=5470 From noreply@sourceforge.net Sat Jan 13 17:27:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 09:27:06 -0800 Subject: [Python-bugs-list] [Bug #128302] Repeatedly initializing the interpreter dumps core Message-ID: Bug #128302, was updated on 2001-Jan-10 09:15 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: None Priority: 4 Submitted by: gvanrossum Assigned to : nascheme Summary: Repeatedly initializing the interpreter dumps core Details: I've checked in a simple test program: Demo/embed/loop.c. If you run "make looptest" in this directory, you should get a few lines of 'hello world' followed by a core dump. Follow-Ups: Date: 2001-Jan-13 09:27 By: gvanrossum Comment: Neil, do you mind if I assign this to you? When I look at this in gdb, it usually seems to have crashed somewhere in the GC code. Could you give it a quick look over? Is it possible that the GC code doesn't do the right thing when Py_Finalize() and Py_Initialize() are called more than once? If you don't have time or don't think it's GC's fault, please give it back to me or to None. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128302&group_id=5470 From noreply@sourceforge.net Sat Jan 13 19:38:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 11:38:56 -0800 Subject: [Python-bugs-list] [Bug #128685] popen on Win9x isnt smart enough about finding w9xpopen.exe Message-ID: Bug #128685, was updated on 2001-Jan-13 11:38 Here is a current snapshot of the bug. Project: Python Category: Extension Modules Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: mhammond Assigned to : nobody Summary: popen on Win9x isnt smart enough about finding w9xpopen.exe Details: The code in posixmodule that emulates popen*() isnt very smart about locating the .exe for the Win9x popen hacks. It assumes that w9xpopen.exe can be located in the directory of the main executable, which fails in may embedding situations. A reasonable fix would be to also attempt to locate the file in the "sys.prefix" directory - typically this will be set correctly. Im not at my main dev machine, hence I am submitting a bug rather than a patch. I will submit a patch ASAP. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128685&group_id=5470 From noreply@sourceforge.net Sat Jan 13 19:39:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 11:39:20 -0800 Subject: [Python-bugs-list] [Bug #128685] popen on Win9x isnt smart enough about finding w9xpopen.exe Message-ID: Bug #128685, was updated on 2001-Jan-13 11:38 Here is a current snapshot of the bug. Project: Python Category: Extension Modules Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: mhammond Assigned to : mhammond Summary: popen on Win9x isnt smart enough about finding w9xpopen.exe Details: The code in posixmodule that emulates popen*() isnt very smart about locating the .exe for the Win9x popen hacks. It assumes that w9xpopen.exe can be located in the directory of the main executable, which fails in may embedding situations. A reasonable fix would be to also attempt to locate the file in the "sys.prefix" directory - typically this will be set correctly. Im not at my main dev machine, hence I am submitting a bug rather than a patch. I will submit a patch ASAP. Follow-Ups: Date: 2001-Jan-13 11:39 By: mhammond Comment: Giving to me! ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128685&group_id=5470 From noreply@sourceforge.net Sat Jan 13 19:40:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 11:40:05 -0800 Subject: [Python-bugs-list] [Bug #128302] Repeatedly initializing the interpreter dumps core Message-ID: Bug #128302, was updated on 2001-Jan-10 09:15 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: None Priority: 4 Submitted by: gvanrossum Assigned to : gvanrossum Summary: Repeatedly initializing the interpreter dumps core Details: I've checked in a simple test program: Demo/embed/loop.c. If you run "make looptest" in this directory, you should get a few lines of 'hello world' followed by a core dump. Follow-Ups: Date: 2001-Jan-13 11:40 By: nascheme Comment: The GC always gets the blame, doesn't it? ;-) I get setfaults all over the place. Linking with efence gives this segfault: (gdb) run "print 1" Starting program: /home/nas/Python/py/Demo/embed/loop "print 1" Electric Fence 2.0.5 Copyright (C) 1987-1998 Bruce Perens. 1 Program received signal SIGSEGV, Segmentation fault. 0x8055ff9 in _PySys_Init () at sysmodule.c:634 634 Py_INCREF(warnoptions); (gdb) p *warnoptions $1 = {ob_refcnt = 0, ob_type = 0x818b820} (gdb) bt #0 0x8055ff9 in _PySys_Init () at sysmodule.c:634 #1 0x8052fd7 in Py_Initialize () at pythonrun.c:135 #2 0x8052de9 in main (argc=2, argv=0xbffffaac) at loop.c:21 This code looks a bit suspect to me: if (warnoptions != NULL) { PyDict_SetItemString(sysdict, "warnoptions", v = warnoptions); Py_DECREF(v); } Removing the decref seems to solve the problem. Back to you Guido. ------------------------------------------------------- Date: 2001-Jan-13 09:27 By: gvanrossum Comment: Neil, do you mind if I assign this to you? When I look at this in gdb, it usually seems to have crashed somewhere in the GC code. Could you give it a quick look over? Is it possible that the GC code doesn't do the right thing when Py_Finalize() and Py_Initialize() are called more than once? If you don't have time or don't think it's GC's fault, please give it back to me or to None. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128302&group_id=5470 From noreply@sourceforge.net Sat Jan 13 20:07:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 12:07:21 -0800 Subject: [Python-bugs-list] [Bug #128688] Tools/compiler can't compile Lib/*.py Message-ID: Bug #128688, was updated on 2001-Jan-13 12:07 Here is a current snapshot of the bug. Project: Python Category: demos and tools Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nascheme Assigned to : nobody Summary: Tools/compiler can't compile Lib/*.py Details: Subject says it all. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128688&group_id=5470 From noreply@sourceforge.net Sat Jan 13 20:34:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 12:34:55 -0800 Subject: [Python-bugs-list] [Bug #128688] Tools/compiler can't compile Lib/*.py Message-ID: Bug #128688, was updated on 2001-Jan-13 12:07 Here is a current snapshot of the bug. Project: Python Category: demos and tools Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nascheme Assigned to : jhylton Summary: Tools/compiler can't compile Lib/*.py Details: Subject says it all. Follow-Ups: Date: 2001-Jan-13 12:34 By: nascheme Comment: This (incorrect?) patch to transformer.py seems to help: - def com_NEWLINE(self): + def com_NEWLINE(self, nodelist): but the resulting bytecode kills the interpreter: (gdb) run Lib/test/regrtest.py Starting program: /home/nas/Python/py/python Lib/test/regrtest.py test_grammar test_opcodes test_operations test_builtin test_exceptions test_types test_MimeWriter test_StringIO Program received signal SIGSEGV, Segmentation fault. 0x805b8d3 in eval_code2 (co=0x8255f08, globals=0x8258e44, locals=0x0, args=0x81ffd64, argcount=1, kws=0x81ffd68, kwcount=0, defs=0x0, defcount=0) at ceval.c:2079 2079 Py_XDECREF(v); (gdb) l 2074 2075 /* Pop remaining stack entries */ 2076 2077 while (!EMPTY()) { 2078 v = POP(); 2079 Py_XDECREF(v); 2080 } 2081 2082 if (why != WHY_RETURN) 2083 retval = NULL; (gdb) p *v Cannot access memory at address 0x22. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128688&group_id=5470 From noreply@sourceforge.net Sat Jan 13 22:07:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 14:07:21 -0800 Subject: [Python-bugs-list] [Bug #128302] Repeatedly initializing the interpreter dumps core Message-ID: Bug #128302, was updated on 2001-Jan-10 09:15 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Closed Resolution: Fixed Bug Group: None Priority: 4 Submitted by: gvanrossum Assigned to : gvanrossum Summary: Repeatedly initializing the interpreter dumps core Details: I've checked in a simple test program: Demo/embed/loop.c. If you run "make looptest" in this directory, you should get a few lines of 'hello world' followed by a core dump. Follow-Ups: Date: 2001-Jan-13 14:07 By: gvanrossum Comment: Thanks, Neil! I clearly need to learn about efence myself. :-) The loop program now leaks memory, slowly; I'll ask Barry to look at that. ------------------------------------------------------- Date: 2001-Jan-13 11:40 By: nascheme Comment: The GC always gets the blame, doesn't it? ;-) I get setfaults all over the place. Linking with efence gives this segfault: (gdb) run "print 1" Starting program: /home/nas/Python/py/Demo/embed/loop "print 1" Electric Fence 2.0.5 Copyright (C) 1987-1998 Bruce Perens. 1 Program received signal SIGSEGV, Segmentation fault. 0x8055ff9 in _PySys_Init () at sysmodule.c:634 634 Py_INCREF(warnoptions); (gdb) p *warnoptions $1 = {ob_refcnt = 0, ob_type = 0x818b820} (gdb) bt #0 0x8055ff9 in _PySys_Init () at sysmodule.c:634 #1 0x8052fd7 in Py_Initialize () at pythonrun.c:135 #2 0x8052de9 in main (argc=2, argv=0xbffffaac) at loop.c:21 This code looks a bit suspect to me: if (warnoptions != NULL) { PyDict_SetItemString(sysdict, "warnoptions", v = warnoptions); Py_DECREF(v); } Removing the decref seems to solve the problem. Back to you Guido. ------------------------------------------------------- Date: 2001-Jan-13 09:27 By: gvanrossum Comment: Neil, do you mind if I assign this to you? When I look at this in gdb, it usually seems to have crashed somewhere in the GC code. Could you give it a quick look over? Is it possible that the GC code doesn't do the right thing when Py_Finalize() and Py_Initialize() are called more than once? If you don't have time or don't think it's GC's fault, please give it back to me or to None. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128302&group_id=5470 From noreply@sourceforge.net Sat Jan 13 23:19:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 15:19:29 -0800 Subject: [Python-bugs-list] [Bug #126851] ftplib.py should default to passive mode Message-ID: Bug #126851, was updated on 2000-Dec-26 12:07 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: Feature Request Priority: 4 Submitted by: flight Assigned to : gvanrossum Summary: ftplib.py should default to passive mode Details: For the Debian package, there has been the request that the ftplib module should by default use passive FTP. Any comments [Forwarded from the Debian bug tracking system, bug#71823] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=71823&repeatmerged=yes Sender: Mike Fisk Package: python-base Version: 1.5.2-10 This is an upstream bug that has existed for quite a while (probably forever). With many systems living behind firewalls (including their own ipchains filters), passive FTP should be the default for FTP clients. It always has been for Netscape and there hasn't been much uproar about that being bad. Python's ftplib.py supports passive mode, but defaults to non-passive mode. ftplib.py is used by other Debian packages such as the downloader in xanim-modules. The result, when living behind many firewalls, is that you can't download anything using ftplib.py or urllib.py. The patch to fix this is trivial: --- /usr/lib/python1.5/ftplib.py Sat Sep 16 14:31:35 2000 +++ /tmp/ftplib.py Sat Sep 16 14:31:24 2000 @@ -112,7 +112,7 @@ - port: port to connect to (integer, default previous port)''' if host: self.host = host if port: self.port = port - self.passiveserver = 0 + self.passiveserver = 1 self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.sock.connect(self.host, self.port) self.file = self.sock.makefile('rb') -- Mike Fisk, RADIANT Team, Network Engineering Group, Los Alamos National Lab See http://home.lanl.gov/mfisk/ for contact information Follow-Ups: Date: 2001-Jan-13 15:19 By: mfisk Comment: Since I only use the urllib interface, changing it would be sufficient for me, but I'm not sure that it's the "best" thing for all the other ftplib users. I agree that this would break an FTP into a firewall that currently works. I've had occaision to do this (although not with ftplib), but it's pretty rare. I strongly believe that FTPing to a service behind a filter is much less common than FTPing from a client that is behind a filter. Assuming that people agree that that statement, it's mainly a question of being willing to break some small number of existing users in order to fix some larger number of users. My personal preference would be to make the library default to a state that is most frequently functional (passive). Different projects have different customs when it comes to changing existing semantics --- I'll defer to whatever the usual custom here is. For our site's firewall documentation, we did a study of which popular clients default to or support passive. For web browsers, it is common to default to passive. For normal FTP clients (including GUI clients on Mac & Windows), the default seems to be non-passive. Internet Explorer seems to almost alternate between releases. Some FTP client implementations try one option (passive or not) and automatically revert to the other after some timeout. Getting this right seems more difficult than it's worth unless somebody is ambitious in this regard. ncftp seems to default to this if anybody is interested in looking at their code. One could argue that since passivity is a negotiated option in the FTP protocol, a server than cannot accept passive connections should not accept the PASV command. In this case the client could back-off to non-passive mode. Unfortunately, I have no reason to believe that any common FTP servers have this option or that their administrators would use it. ------------------------------------------------------- Date: 2001-Jan-08 17:57 By: gvanrossum Comment: Thomas Wouters raised the concern that passive mode makes it impossible to access servers that are inside a firewall. I'm not sure that this is a showstopper (does anybody do that?) but I'd like to stay on the careful side. Thomas noted that ftplib is used for more diverse tasks than Netscape. Would it be sufficient to make a change to urllib that changes the connection to passive mode in its ftpwrapper class? That would solve the problem for urllib (most comparable to Netscape) without breaking any code that directly uses ftplib. ------------------------------------------------------- Date: 2000-Dec-27 15:16 By: gvanrossum Comment: Hmm... I like the proposed patch. I don't know about ftp'ing into a firewall -- why would that be common? Typically ftp servers live outside firewalls because ftp is considered insecure... ------------------------------------------------------- Date: 2000-Dec-27 14:13 By: twouters Comment: For what it's worth, I mildly agree that passive mode should be the default. However, it does have potential for breaking stuff: using passive-ftp *into* a firewall, instead of out of one, doesn't work. And I'm pretty sure that Python's ftplib is used much more often in that manner than is Netscape or whatever other ftp client defaults to passive. It's probably not much, but I think it's enough to think twice about changing the default ;P ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=126851&group_id=5470 From noreply@sourceforge.net Sun Jan 14 02:36:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 18:36:33 -0800 Subject: [Python-bugs-list] [Bug #128711] Need string-to-character-list splitter Message-ID: Bug #128711, was updated on 2001-Jan-13 18:36 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Submitted by: brysmith Assigned to : nobody Summary: Need string-to-character-list splitter Details: Python has many neat tools for string handling, but on eseems to be missing - to expand a string into a list of characters. Currently the code lst = string.split("abcdef","") returns "Value error - empty separator" I would like to suggest that split with "" as the second argument be interpreted as a request to expand the first (string) argument into a list of the characters that make up the string. e.g. string.split("ab c","") would return ['a', 'b', ' ', 'c'] This seems to make sense, since split(x,"") would then be the inverse of join(y,"") I doubt that this enhancement of string.split would break any existing code, since string.split("abc","") is currently an invalid call. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128711&group_id=5470 From noreply@sourceforge.net Sun Jan 14 02:58:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 18:58:03 -0800 Subject: [Python-bugs-list] [Bug #128711] Need string-to-character-list splitter Message-ID: Bug #128711, was updated on 2001-Jan-13 18:36 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Closed Resolution: Works For Me Bug Group: Feature Request Priority: 5 Submitted by: brysmith Assigned to : nobody Summary: Need string-to-character-list splitter Details: Python has many neat tools for string handling, but on eseems to be missing - to expand a string into a list of characters. Currently the code lst = string.split("abcdef","") returns "Value error - empty separator" I would like to suggest that split with "" as the second argument be interpreted as a request to expand the first (string) argument into a list of the characters that make up the string. e.g. string.split("ab c","") would return ['a', 'b', ' ', 'c'] This seems to make sense, since split(x,"") would then be the inverse of join(y,"") I doubt that this enhancement of string.split would break any existing code, since string.split("abc","") is currently an invalid call. Follow-Ups: Date: 2001-Jan-13 18:58 By: tim_one Comment: It's odd that when people ask "I need something to convert X to Y!", they don't try Y(X) to see what happens : >>> list("abcdef") ['a', 'b', 'c', 'd', 'e', 'f'] >>> list() converts an object of any sequence type to a list of its elements, and strings are a sequence type. Here's a much sillier way: >>> import re >>> re.findall('.', 'abcdef') ['a', 'b', 'c', 'd', 'e', 'f'] >>> Two ways already is plenty ... ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128711&group_id=5470 From noreply@sourceforge.net Sun Jan 14 04:11:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jan 2001 20:11:14 -0800 Subject: [Python-bugs-list] [Bug #128713] type() on mmap object causes segfault Message-ID: Bug #128713, was updated on 2001-Jan-13 20:11 Here is a current snapshot of the bug. Project: Python Category: Extension Modules Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: tokeneater Assigned to : nobody Summary: type() on mmap object causes segfault Details: Apparently, mmap_object_type.ob_type wasn't initialized properly for UNIX platforms. The patch below fixes the problem for Linux, and I believe it should work for windows as well. =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/mmapmodule.c,v retrieving revision 2.26 diff -c -r2.26 mmapmodule.c *** mmapmodule.c 2001/01/10 21:03:32 2.26 --- mmapmodule.c 2001/01/14 04:03:15 *************** *** 841,849 **** int fileno; HANDLE fh = 0; - /* Patch the object type */ - mmap_object_type.ob_type = &PyType_Type; - if (!PyArg_ParseTuple(args, "iO|z", &fileno, --- 841,846 ---- *************** *** 956,961 **** --- 953,962 ---- initmmap(void) { PyObject *dict, *module; + + /* Patch the object type */ + mmap_object_type.ob_type = &PyType_Type; + module = Py_InitModule ("mmap", mmap_functions); dict = PyModule_GetDict (module); mmap_module_error = PyExc_EnvironmentError; For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128713&group_id=5470 From noreply@sourceforge.net Sun Jan 14 08:06:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Jan 2001 00:06:52 -0800 Subject: [Python-bugs-list] [Bug #128713] type() on mmap object causes segfault Message-ID: Bug #128713, was updated on 2001-Jan-13 20:11 Here is a current snapshot of the bug. Project: Python Category: Extension Modules Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: tokeneater Assigned to : tim_one Summary: type() on mmap object causes segfault Details: Apparently, mmap_object_type.ob_type wasn't initialized properly for UNIX platforms. The patch below fixes the problem for Linux, and I believe it should work for windows as well. =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/mmapmodule.c,v retrieving revision 2.26 diff -c -r2.26 mmapmodule.c *** mmapmodule.c 2001/01/10 21:03:32 2.26 --- mmapmodule.c 2001/01/14 04:03:15 *************** *** 841,849 **** int fileno; HANDLE fh = 0; - /* Patch the object type */ - mmap_object_type.ob_type = &PyType_Type; - if (!PyArg_ParseTuple(args, "iO|z", &fileno, --- 841,846 ---- *************** *** 956,961 **** --- 953,962 ---- initmmap(void) { PyObject *dict, *module; + + /* Patch the object type */ + mmap_object_type.ob_type = &PyType_Type; + module = Py_InitModule ("mmap", mmap_functions); dict = PyModule_GetDict (module); mmap_module_error = PyExc_EnvironmentError; Follow-Ups: Date: 2001-Jan-14 00:06 By: moshez Comment: Assigning to tim, because I recall seeing a checkin message from him saying he fixed it. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128713&group_id=5470 From noreply@sourceforge.net Sun Jan 14 10:51:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Jan 2001 02:51:19 -0800 Subject: [Python-bugs-list] [Bug #128713] type() on mmap object causes segfault Message-ID: Bug #128713, was updated on 2001-Jan-13 20:11 Here is a current snapshot of the bug. Project: Python Category: Extension Modules Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: tokeneater Assigned to : tim_one Summary: type() on mmap object causes segfault Details: Apparently, mmap_object_type.ob_type wasn't initialized properly for UNIX platforms. The patch below fixes the problem for Linux, and I believe it should work for windows as well. =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/mmapmodule.c,v retrieving revision 2.26 diff -c -r2.26 mmapmodule.c *** mmapmodule.c 2001/01/10 21:03:32 2.26 --- mmapmodule.c 2001/01/14 04:03:15 *************** *** 841,849 **** int fileno; HANDLE fh = 0; - /* Patch the object type */ - mmap_object_type.ob_type = &PyType_Type; - if (!PyArg_ParseTuple(args, "iO|z", &fileno, --- 841,846 ---- *************** *** 956,961 **** --- 953,962 ---- initmmap(void) { PyObject *dict, *module; + + /* Patch the object type */ + mmap_object_type.ob_type = &PyType_Type; + module = Py_InitModule ("mmap", mmap_functions); dict = PyModule_GetDict (module); mmap_module_error = PyExc_EnvironmentError; Follow-Ups: Date: 2001-Jan-14 02:51 By: tim_one Comment: Thanks, Moshe. I swear I closed this already, adding a note giving the new revision numbers for mmapmodule.c, test_mmap, output/test_mmap, and mentioned I'd also checked in a new ACKS. But, indeed, there's no record of that here! So closing it now (again, from my POV). ------------------------------------------------------- Date: 2001-Jan-14 00:06 By: moshez Comment: Assigning to tim, because I recall seeing a checkin message from him saying he fixed it. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128713&group_id=5470 From noreply@sourceforge.net Sun Jan 14 14:28:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Jan 2001 06:28:27 -0800 Subject: [Python-bugs-list] [Bug #121654] sre regex () groups have strong memory Message-ID: Bug #121654, was updated on 2000-Nov-05 00:17 Here is a current snapshot of the bug. Project: Python Category: Regular Expressions Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: david_alessio Assigned to : effbot Summary: sre regex () groups have strong memory Details: The new re module (sre) has a problem with () grouping. It seems () groups sometimes "remember" the previous match. Try the following: #!/usr/bin/python """ This module parses a CSV string and produces a list whose elements are the Comma-Seperated Values. myCSV uses Python's regular expression matching. The search pattern uses three groups of (). findall() returns a list of tuples containing three elements--the results of the search groups. The lambda function returns the correct element of the three. For more info on regular expressions see: Mastering Regular Expressions Jeffrey E. F. Friedl O'Reilly Press ###################################################################### Created: 23-Mar-2000 Author: David S. Alessio Last Modified: $Modtime:$ Last Modified by: $Author:$ Revision: $Revision:$ Revision History: $Log:$ ###################################################################### """ import re class myCSV: def __init__(self): self.srchPat = '"([^"\\\\]*(\\\\.[^"\\\\]*)*)",?|([^,]+),?|,' self.srchProg = re.compile(self.srchPat) def __str2num(self, str): try: num = int(str) except: try: num = long(str) except: try: num = float(str) except: num = str return num def __pick_best_value(self, t): value = t[0] or t[2] return self.__str2num(value) def csv2list(self, str): # print self.srchProg.findall(str) return map(lambda t: t[0] or t[2], self.srchProg.findall(str)) def csv2numlist(self, str): return map(self.__pick_best_value, self.srchProg.findall(str)) def test(self): str = '1,2,3,"ab\\"c","de,f",name,"123",,,"xyz","","zzz"' tstnumlst = [1,2,3,'ab\\"c','de,f','name',123,'','','xyz','','zzz'] list = self.csv2list(str) numlst = self.csv2numlist(str) print str print list print numlst print tstnumlst #""" if tstnumlst != numlst: print "\nERROR:" if len(numlst) > len(tstnumlst): print 'NumList Too Long!!!' elif len(numlst) < len(tstnumlst): print 'NumList Too Short!!!' else: print ' Expected Got' for i in xrange(len(tstnumlst)): mark = '' if tstnumlst[i] != numlst[i]: mark = ' <===' print 'L[%2d]: %10s %10s %s' % (i, tstnumlst[i], numlst[i], mark) else: print 'OK' #""" if __name__ == '__main__': from sys import argv if len(argv) == 1: print 'Compiling CSV' x = myCSV(); print 'Testing...' x.test() elif len(argv) == 2: fin = open(argv[1]) x = myCSV(); while 1: str = fin.readline() if not str: break csv = x.csv2numlist(str[:-1]) print csv else: print 'Usage: %s [file.csv]' % argv[0] Follow-Ups: Date: 2001-Jan-05 07:36 By: effbot Comment: Fixed but not closed? Might mean that it's fixed locally, but not in the CVS repository. I'll investigate. /F ------------------------------------------------------- Date: 2000-Nov-09 11:54 By: effbot Comment: same as #117612 ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=121654&group_id=5470 From noreply@sourceforge.net Sun Jan 14 14:29:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Jan 2001 06:29:57 -0800 Subject: [Python-bugs-list] [Bug #127259] New re breaks on some '*?' matches Message-ID: Bug #127259, was updated on 2001-Jan-01 20:37 Here is a current snapshot of the bug. Project: Python Category: Regular Expressions Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: nobody Assigned to : effbot Summary: New re breaks on some '*?' matches Details: New python library: Python 2.0 (#2, Nov 29 2000, 07:33:50) [GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import re >>> re.match("a[ ]*?\ (\d+)", "a 10") >>> re.match("a[ ]*?\ (\d+)", "a 10") Old python library: Python 1.5.2 (#1, Aug 25 2000, 09:33:37) [GCC 2.96 20000731 (experimental)] on linux-i386 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import re >>> re.match("a[ ]*?\ (\d+)", "a 10") >>> re.match("a[ ]*?\ (\d+)", "a 10") >>> I see no reason why the second line should not match. (IE. the old regular expression library seems correct to me.) Ok, "so don't do that" - well I encountered it in code that autogenerates regular expressions, so it isn't so easy to always avoid. Besides, it doesn't look correct to me. Thanks, -Kevin (kevoc@bellatlantic.net) Follow-Ups: Date: 2001-Jan-02 15:39 By: nobody Comment: Two bugs in one: Kevin's problem was that SRE didn't always reset the internal string pointer after a failed minimizing tail match. Pearu's problem was that the meaning of \Z was (incorrectly) changed by (?m) -- in other words, \Z behaved like $. Both bugs have been fixed on my box; I'll check them in as soon as I've fixed my CVS install... ------------------------------------------------------- Date: 2001-Jan-02 09:56 By: pearu Comment: Here is another example where new re produces different (incorrect) result compared to Python 1.5.2 re module: Python 1.5.2: >>>re.match(r'(?ms).*?}\s*\Z(?P.*)','{}\012}\012').groupdict() {'rest': ''} Python 2.0: >>>re.match(r'(?ms).*?}\s*\Z(?P.*)','{}\012}\012').groupdict() {'rest': '\012}\012'} which deviates from the definition of \Z: \Z Matches only at the end of the string. Here group 'rest' is used only for illustration, it should always be empty string. tim.one has suspected that this bug could be related to `*?' part. Though it seems to me that \Z meaning is violated here more. Thanks, Pearu ------------------------------------------------------- Date: 2001-Jan-02 05:23 By: gvanrossum Comment: Also note that if you increase the number of spaces between 'a' and '10', sre gives a match for an odd number of spaces only. ------------------------------------------------------- Date: 2001-Jan-01 21:20 By: tim_one Comment: Reproduced and assigned to /F. Agree it's a bug. Also agree you shouldn't do that . SourceForge's treatment of whitespace is maddening. Note that there *should* be 3 blanks in "a 10" (first example) but 4 in "a 10" (second, failing example). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127259&group_id=5470 From noreply@sourceforge.net Sun Jan 14 14:31:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Jan 2001 06:31:43 -0800 Subject: [Python-bugs-list] [Bug #125531] sre Scanner.scan typo (?) Message-ID: Bug #125531, was updated on 2000-Dec-12 11:20 Here is a current snapshot of the bug. Project: Python Category: Regular Expressions Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: nobody Assigned to : effbot Summary: sre Scanner.scan typo (?) Details: I believe there's a small glitch in the Scanner.scan method in the sre module (up through ver. 1.25). Here's what the scan method does when it finds a match: if callable(action): self.match = match action = action(self, m.group()) the local variable match in the above is a reference to the match routine from the internal scanner object in the C DLL. I think the intention of the above was probably to set self.match to m -- the Match object returned from the successful search. Follow-Ups: Date: 2001-Jan-02 15:51 By: nobody Comment: The Scanner class is experimental, and wasn't really meant to be in 2.0. I plan to fix all bugs in 2.1 -- but it's up to the python-dev team to decide if it should an official part of Python's RE package. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=125531&group_id=5470 From noreply@sourceforge.net Sun Jan 14 14:35:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Jan 2001 06:35:55 -0800 Subject: [Python-bugs-list] [Bug #123769] sre bug for non-greedy match Message-ID: Bug #123769, was updated on 2000-Nov-28 20:15 Here is a current snapshot of the bug. Project: Python Category: Regular Expressions Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: nobody Assigned to : effbot Summary: sre bug for non-greedy match Details: import pre, sre print pre.match(r'.*?\S *:', 'xx:').group() # ok print sre.match(r'.*?\S *:', 'xx:').group() # error Follow-Ups: Date: 2001-Jan-14 06:35 By: effbot Comment: Same as 123769 ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=123769&group_id=5470 From noreply@sourceforge.net Sun Jan 14 21:09:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Jan 2001 13:09:57 -0800 Subject: [Python-bugs-list] [Bug #115900] difference between pre and sre for buggy expressions Message-ID: Bug #115900, was updated on 2000-Oct-03 03:11 Here is a current snapshot of the bug. Project: Python Category: Regular Expressions Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: htrd Assigned to : effbot Summary: difference between pre and sre for buggy expressions Details: def check_pattern(pattern): import pre, sre pre_version = pre.compile(pattern) print pre_version.match('-1234a') print pre_version.match(' 1234a') sre_version = sre.compile(pattern) print sre_version.match('-1234a') print sre_version.match(' 1234a') # This is a buggy re: It is trying to match a minus sign as part of a # set of characters, but does not follow the documented rule of # "precede it with a backslash, or place it as the first character" # However, pre and sre behave differently, and neither behaviour is # quite what I was expecting. Is this a hint of a bug? check_pattern('([\s-])(\.?)' + r'([HLEr0123456789\s-])(\.?)'*4 +r'([abcd]?)') # Preceeding them with a backslash makes pre and sre behave identically. check_pattern('([\s\-])(\.?)' + r'([HLEr0123456789\s\-])(\.?)'*4 +r'([abcd]?)') Follow-Ups: Date: 2001-Jan-14 13:09 By: effbot Comment: part 1 (character class followed by hyphen) is same as bug #116251 (fixed by amk 2000-10-07) part 2 (bogus regexps) is fixed in current CVS. Will be in 2.1. ------------------------------------------------------- Date: 2000-Oct-13 18:43 By: jdnier Comment: I've also run into a few bogus regexes that sre (NT4; python 2.0c1) swallows but pre doesn't. These patterns are contrived but typos happen and without a compile traceback the problem can be hard to discover. Just run C:\Python20\Tools\Scripts\redemo.py, give it a string to search like "aaaaaabbb" and enter, for example, (? (?) a+?? <-shouldn't this raise 'nothing to repeat' error? It matches a single 'a'; the second '?' is ignored a+??? <-this matches the null string a+???? <-this finally errors "nothing to repeat" a??????????? <-never errors; matches null string a++++++++ <-never errors; matches same as a+ It's the "matches the null string" part that seems evil, even if you allow sre to be more permissive and not complain about the regex syntax errors. Also, a* and permutations seem to work as expected, so it looks like something is up with + and ? in particular. Other novelties... a?+? a????+? a?????+ a+??? a(?)????????????b ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=115900&group_id=5470 From noreply@sourceforge.net Sun Jan 14 22:03:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Jan 2001 14:03:04 -0800 Subject: [Python-bugs-list] [Bug #128764] urllib.splithost() chokes on password containing '/' Message-ID: Bug #128764, was updated on 2001-Jan-14 14:03 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: dougfort Assigned to : nobody Summary: urllib.splithost() chokes on password containing '/' Details: urllib.splithost() uses a regular expression to split url hostnames of the form 'http://userid:password@host...' The regex stops at the first '/'. If the password contains a '/' the results are invalid. I'm submitting this as a bug, rather than a diff, because I'm afraid to mess with the regex. If I come up with something, I'll send in a diff. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128764&group_id=5470 From noreply@sourceforge.net Sun Jan 14 22:56:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Jan 2001 14:56:44 -0800 Subject: [Python-bugs-list] [Bug #128764] urllib.splithost() chokes on password containing '/' Message-ID: Bug #128764, was updated on 2001-Jan-14 14:03 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Closed Resolution: None Bug Group: None Priority: 5 Submitted by: dougfort Assigned to : nobody Summary: urllib.splithost() chokes on password containing '/' Details: urllib.splithost() uses a regular expression to split url hostnames of the form 'http://userid:password@host...' The regex stops at the first '/'. If the password contains a '/' the results are invalid. I'm submitting this as a bug, rather than a diff, because I'm afraid to mess with the regex. If I come up with something, I'll send in a diff. Follow-Ups: Date: 2001-Jan-14 14:56 By: gvanrossum Comment: This is not a bug -- if you allow arbitrary characters in the password, the URL could become totally ambiguous. E.g. what if the password started with "80/"? How can a browser know what is meant if the URL is "http://user:80/garbage@host" ??? According to RFC 1738: ``Within the user and password field, any ":", "@", or "/" must be encoded.'' The splituser() function correctly calls unquote() to remove the %xx encoding from the username and password. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128764&group_id=5470 From noreply@sourceforge.net Sun Jan 14 22:57:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Jan 2001 14:57:16 -0800 Subject: [Python-bugs-list] [Bug #128764] urllib.splithost() chokes on password containing '/' Message-ID: Bug #128764, was updated on 2001-Jan-14 14:03 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Closed Resolution: Invalid Bug Group: Not a Bug Priority: 5 Submitted by: dougfort Assigned to : gvanrossum Summary: urllib.splithost() chokes on password containing '/' Details: urllib.splithost() uses a regular expression to split url hostnames of the form 'http://userid:password@host...' The regex stops at the first '/'. If the password contains a '/' the results are invalid. I'm submitting this as a bug, rather than a diff, because I'm afraid to mess with the regex. If I come up with something, I'll send in a diff. Follow-Ups: Date: 2001-Jan-14 14:56 By: gvanrossum Comment: This is not a bug -- if you allow arbitrary characters in the password, the URL could become totally ambiguous. E.g. what if the password started with "80/"? How can a browser know what is meant if the URL is "http://user:80/garbage@host" ??? According to RFC 1738: ``Within the user and password field, any ":", "@", or "/" must be encoded.'' The splituser() function correctly calls unquote() to remove the %xx encoding from the username and password. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128764&group_id=5470 From noreply@sourceforge.net Sun Jan 14 23:50:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Jan 2001 15:50:15 -0800 Subject: [Python-bugs-list] [Bug #115696] sre RuntimeError when .*? matches >16K string Message-ID: Bug #115696, was updated on 2000-Sep-29 19:47 Here is a current snapshot of the bug. Project: Python Category: Regular Expressions Status: Closed Resolution: Fixed Bug Group: None Priority: 6 Submitted by: jdnier Assigned to : effbot Summary: sre RuntimeError when .*? matches >16K string Details: The following code (run under WinNT): sre.search('x.*?z', 'x%sx' % ("y" * 16037,)) raises "RuntimeError: maximum recursion limit exceeded". sre doesn't seem to be able to do a minimal match across more than ~16K characters. I think pcre can match something like 2**32 characters, so this is an area where the sre behavior deviates radically from pcre. I have lots of code that breaks with this limit. Yikes! Can something be done? While trying to come up with the magic number of characters that cause a minimal match to fail, I ran this interactive session (I'm not sure if this means anything or if it's a quirk of the interactive interpreter.) C:\>python Python 2.0b2 (#6, Sep 26 2000, 14:59:21) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import sre >>> sre.search('x.*?x', 'x%sx' % ('@'*16035,)) >>> sre.search('x.*?x', 'x%sx' % ('@'*16036,)) >>> sre.search('x.*?x', 'x%sx' % ('@'*16037,)) <-- first failure Traceback (most recent call last): File "", line 1, in ? File "D:\Python20\lib\sre.py", line 47, in search return _compile(pattern, flags).search(string) RuntimeError: maximum recursion limit exceeded >>> sre.search('x.*?x', 'x%sx' % ('@'*16037,)) <-- now it works (?!) >>> sre.search('x.*?x', 'x%sx' % ('@'*16038,)) >>> >>> sre.search('x.*?x', 'x%sx' % ('@'*16166,)) >>> sre.search('x.*?x', 'x%sx' % ('@'*16167,)) <-- here it fails again Traceback (most recent call last): File "", line 1, in ? File "D:\Python20\lib\sre.py", line 47, in search return _compile(pattern, flags).search(string) RuntimeError: maximum recursion limit exceeded >>> sre.search('x.*?x', 'x%sx' % ('@'*16167,)) <-- continues to fail Traceback (most recent call last): File "", line 1, in ? File "D:\Python20\lib\sre.py", line 47, in search return _compile(pattern, flags).search(string) RuntimeError: maximum recursion limit exceeded Follow-Ups: Date: 2000-Oct-23 12:23 By: nshelley Comment: I am getting killed by this same bug! #!/usr/bin/env python2.0 import re output = """Using == Data Table == s m:d mb 3.300000 0.000104772187944365 -1.23330767339032e-15 3.200000 0.000103862130408037 -1.23481086168441e-15 3.100000 0.000102831826202984 -1.23643366708223e-15 3.000000 0.000101671354638586 -1.23819069775402e-15 2.900000 0.000100370082245968 -1.24009908383179e-15 2.800000 9.89166376398503e-05 -1.24217904419247e-15 2.700000 9.72988932844521e-05 -1.24445461136295e-15 2.600000 9.55039568198016e-05 -1.24695456774457e-15 2.500000 9.3518175238995e-05 -1.24971366756711e-15 2.400000 9.13271559565959e-05 -1.25277425005882e-15 2.300000 8.89158096852735e-05 -1.25618839559713e-15 2.200000 8.62684210547775e-05 -1.26002084671538e-15 2.100000 8.33687540802062e-05 -1.26435302405962e-15 2.000000 8.02002009414518e-05 -1.26928863786894e-15 1.900000 7.67459841300842e-05 -1.27496167015724e-15 1.800000 7.29894239935539e-05 -1.28154795600633e-15 1.700000 6.89142864097651e-05 -1.28928236065365e-15 1.600000 6.45052296412595e-05 -1.29848488989922e-15 1.500000 5.97483776126083e-05 -1.30960148694006e-15 1.400000 5.46320649249439e-05 -1.32326977154928e-15 1.300000 4.91478435825781e-05 -1.3404286750276e-15 1.200000 4.32919623998454e-05 -1.36250830892367e-15 1.100000 3.70678871330223e-05 -1.39177202537724e-15 1.000000 3.04915786576429e-05 -1.43195494399345e-15 0.900000 2.36052666077545e-05 -1.48947100843164e-15 0.800000 1.65202853321069e-05 -1.57551564136398e-15 0.700000 9.56073716566518e-06 -1.70791288744525e-15 0.600000 3.67125710597e-06 -1.89923336361812e-15 0.500000 6.00021904261974e-07 -2.08381565027337e-15 0.400000 4.27864345038415e-08 -2.14973379503184e-15 0.300000 2.5741570279509e-09 -2.15852923041729e-15 0.200000 1.60325700603365e-10 -2.15762110254924e-15 0.100000 1.10181009347061e-11 -2.15430351925385e-15 0.000000 9.18460199298261e-13 -2.14607756126421e-15 -0.100000 8.2907448480307e-14 -2.13154544128925e-15 -0.200000 9.49291906644266e-15 -2.09562596113738e-15 -0.300000 2.57398712712903e-15 -1.89144055818718e-15 -0.400000 1.23896929747012e-15 -1.18482371296596e-15 -0.500000 4.77088843470797e-16 -4.74259070979461e-16 3.300000 0.000725333230235404 -1.60279744215745e-14 3.200000 0.000698989627849489 -1.57983897758426e-14 3.100000 0.000672395787137216 -1.55721529060957e-14 3.000000 0.000645566845212758 -1.53549883971193e-14 2.900000 0.000618516906916818 -1.51624220311135e-14 2.800000 0.000591259277466284 -1.50347782956977e-14 2.700000 0.000563806714724985 -1.5069525306854e-14 2.600000 0.000536171704020601 -1.54848062262748e-14 2.500000 0.000508366761845922 -1.67334737461837e-14 2.400000 0.000480404778779427 -1.96904798125589e-14 2.300000 0.00045229941701671 -2.59347024715496e-14 2.200000 0.000424065584744255 -3.81354821168744e-14 2.100000 0.000395720019338978 -6.05316531752639e-14 2.000000 0.000367282025836478 -9.9457021513997e-14 1.900000 0.000338774439198852 -1.63825993533288e-13 1.800000 0.000310224913488982 -2.65456611717139e-13 1.700000 0.000281667696431468 -4.19089961445906e-13 1.600000 0.000253146138686846 -6.4197984099406e-13 1.500000 0.000224716340367884 -9.52983499747302e-13 1.400000 0.00019645260393449 -1.37117106753005e-12 1.300000 0.000168455842857815 -1.9140171376089e-12 1.200000 0.000140866992561325 -2.5949957749272e-12 1.100000 0.000113889209694637 -3.419066099784e-12 1.000000 8.78261401150504e-05 -4.36958009251635e-12 0.900000 6.31506490822963e-05 -5.36461118003355e-12 0.800000 4.06312963119592e-05 -6.12577475587495e-12 0.700000 2.15481889941145e-05 -5.92418822150058e-12 0.600000 7.87604367966821e-06 -3.80859906972703e-12 0.500000 1.3904896761789e-06 -9.79870732426348e-13 0.400000 1.06064890626322e-07 -9.39992702457847e-14 0.300000 6.34950130197645e-09 -1.65503941397823e-14 0.200000 3.88292805625561e-10 -1.16204226732226e-14 0.100000 2.57865399432747e-11 -1.11870703136006e-14 0.000000 2.05458930149398e-12 -1.09482596289954e-14 -0.100000 1.85578779234532e-13 -1.06729449780495e-14 -0.200000 2.5577583052963e-14 -1.02232392679007e-14 -0.300000 1.05769385343133e-14 -9.2322860676878e-15 -0.400000 8.00273522170935e-15 -7.88228414475344e-15 -0.500000 6.51965630664677e-15 -6.50815076902941e-15 3.300000 0.000778073989265561 -1.65574096734398e-07 3.200000 0.00074963150963251 -1.92244746339178e-07 3.100000 0.000721015586364691 -2.21197891556889e-07 3.000000 0.000692226507232058 -2.52254070463242e-07 2.900000 0.000663264988754168 -2.85152554002688e-07 2.800000 0.000634132321079485 -3.19546222567145e-07 2.700000 0.000604830546549725 -3.54998299569146e-07 2.600000 0.000575362679604795 -3.90981285317844e-07 2.500000 0.000545732977654778 -4.26878409205096e-07 2.400000 0.000515947275272665 -4.61987879332959e-07 2.300000 0.000486013397947319 -4.95530155074015e-07 2.200000 0.000455941677304999 -5.26658398699649e-07 2.100000 0.000425745598153737 -5.54472176489517e-07 2.000000 0.000395442620520435 -5.78034377120716e-07 1.900000 0.000365055239615154 -5.96391194651538e-07 1.800000 0.000334612377612625 -6.0859488246625e-07 1.700000 0.000304151250425071 -6.13728816719563e-07 1.600000 0.000273719932661724 -6.1093419812057e-07 1.500000 0.000243380977243086 -5.99437433988553e-07 1.400000 0.000213216675616044 -5.78576796961394e-07 1.300000 0.000183336956663227 -5.47826196051382e-07 1.200000 0.000153891700661593 -5.06812695554088e-07 1.100000 0.000125090796710056 -4.55323667088038e-07 1.000000 9.7238530664174e-05 -3.9330616509577e-07 0.900000 7.07959411929754e-05 -3.20910962327376e-07 0.800000 4.64992533700793e-05 -2.38877973057319e-07 0.700000 2.55795422135307e-05 -1.50458199069334e-07 0.600000 1.00314893206752e-05 -6.74343626580743e-08 0.500000 2.00947524041218e-06 -1.48839482947924e-08 0.400000 1.67232105200131e-07 -1.2816627677716e-09 0.300000 1.00809637284154e-08 -7.82708572696571e-11 0.200000 6.12196843592758e-10 -4.83619605089934e-12 0.100000 4.0027953235145e-11 -3.39466185939354e-13 0.000000 3.1163322565507e-12 -4.38427713973686e-14 -0.100000 2.82036148373174e-13 -2.01235539818538e-14 -0.200000 4.04726306794353e-14 -1.75747562532315e-14 -0.300000 1.83397331593843e-14 -1.63366924660679e-14 -0.400000 1.50709750319906e-14 -1.48901998089388e-14 -0.500000 1.34240392889815e-14 -1.34063683071726e-14 3.300000 0.000104772187944365 -1.23330767339032e-15 3.200000 0.000103862130408037 -1.23481086168441e-15 3.100000 0.000102831826202984 -1.23643366708223e-15 3.000000 0.000101671354638586 -1.23819069775402e-15 2.900000 0.000100370082245968 -1.24009908383179e-15 2.800000 9.89166376398503e-05 -1.24217904419247e-15 2.700000 9.72988932844521e-05 -1.24445461136295e-15 2.600000 9.55039568198016e-05 -1.24695456774457e-15 2.500000 9.3518175238995e-05 -1.24971366756711e-15 2.400000 9.13271559565959e-05 -1.25277425005882e-15 2.300000 8.89158096852735e-05 -1.25618839559713e-15 2.200000 8.62684210547775e-05 -1.26002084671538e-15 2.100000 8.33687540802062e-05 -1.26435302405962e-15 2.000000 8.02002009414518e-05 -1.26928863786894e-15 1.900000 7.67459841300842e-05 -1.27496167015724e-15 1.800000 7.29894239935539e-05 -1.28154795600633e-15 1.700000 6.89142864097651e-05 -1.28928236065365e-15 1.600000 6.45052296412595e-05 -1.29848488989922e-15 1.500000 5.97483776126083e-05 -1.30960148694006e-15 1.400000 5.46320649249439e-05 -1.32326977154928e-15 1.300000 4.91478435825781e-05 -1.3404286750276e-15 1.200000 4.32919623998454e-05 -1.36250830892367e-15 1.100000 3.70678871330223e-05 -1.39177202537724e-15 1.000000 3.04915786576429e-05 -1.43195494399345e-15 0.900000 2.36052666077545e-05 -1.48947100843164e-15 0.800000 1.65202853321069e-05 -1.57551564136398e-15 0.700000 9.56073716566518e-06 -1.70791288744525e-15 0.600000 3.67125710597e-06 -1.89923336361812e-15 0.500000 6.00021904261974e-07 -2.08381565027337e-15 0.400000 4.27864345038415e-08 -2.14973379503184e-15 0.300000 2.5741570279509e-09 -2.15852923041729e-15 0.200000 1.60325700603365e-10 -2.15762110254924e-15 0.100000 1.10181009347061e-11 -2.15430351925385e-15 0.000000 9.18460199298261e-13 -2.14607756126421e-15 -0.100000 8.2907448480307e-14 -2.13154544128925e-15 -0.200000 9.49291906644266e-15 -2.09562596113738e-15 -0.300000 2.57398712712903e-15 -1.89144055818718e-15 -0.400000 1.23896929747012e-15 -1.18482371296596e-15 -0.500000 4.77088843470797e-16 -4.74259070979461e-16 3.300000 0.000725333230235404 -1.60279744215745e-14 3.200000 0.000698989627849489 -1.57983897758426e-14 3.100000 0.000672395787137216 -1.55721529060957e-14 3.000000 0.000645566845212758 -1.53549883971193e-14 2.900000 0.000618516906916818 -1.51624220311135e-14 2.800000 0.000591259277466284 -1.50347782956977e-14 2.700000 0.000563806714724985 -1.5069525306854e-14 2.600000 0.000536171704020601 -1.54848062262748e-14 2.500000 0.000508366761845922 -1.67334737461837e-14 2.400000 0.000480404778779427 -1.96904798125589e-14 2.300000 0.00045229941701671 -2.59347024715496e-14 2.200000 0.000424065584744255 -3.81354821168744e-14 2.100000 0.000395720019338978 -6.05316531752639e-14 2.000000 0.000367282025836478 -9.9457021513997e-14 1.900000 0.000338774439198852 -1.63825993533288e-13 1.800000 0.000310224913488982 -2.65456611717139e-13 1.700000 0.000281667696431468 -4.19089961445906e-13 1.600000 0.000253146138686846 -6.4197984099406e-13 1.500000 0.000224716340367884 -9.52983499747302e-13 1.400000 0.00019645260393449 -1.37117106753005e-12 1.300000 0.000168455842857815 -1.9140171376089e-12 1.200000 0.000140866992561325 -2.5949957749272e-12 1.100000 0.000113889209694637 -3.419066099784e-12 1.000000 8.78261401150504e-05 -4.36958009251635e-12 0.900000 6.31506490822963e-05 -5.36461118003355e-12 0.800000 4.06312963119592e-05 -6.12577475587495e-12 0.700000 2.15481889941145e-05 -5.92418822150058e-12 0.600000 7.87604367966821e-06 -3.80859906972703e-12 0.500000 1.3904896761789e-06 -9.79870732426348e-13 0.400000 1.06064890626322e-07 -9.39992702457847e-14 0.300000 6.34950130197645e-09 -1.65503941397823e-14 0.200000 3.88292805625561e-10 -1.16204226732226e-14 0.100000 2.57865399432747e-11 -1.11870703136006e-14 0.000000 2.05458930149398e-12 -1.09482596289954e-14 -0.100000 1.85578779234532e-13 -1.06729449780495e-14 -0.200000 2.5577583052963e-14 -1.02232392679007e-14 -0.300000 1.05769385343133e-14 -9.2322860676878e-15 -0.400000 8.00273522170935e-15 -7.88228414475344e-15 -0.500000 6.51965630664677e-15 -6.50815076902941e-15 """ re.search("== Data Table ==\n(.*?)\n(.*?)\s*$", output, re.S) ------------------------------------------------------- Date: 2000-Sep-30 21:19 By: gvanrossum Comment: Any comments, Fredrik??? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=115696&group_id=5470 From noreply@sourceforge.net Sun Jan 14 23:59:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 14 Jan 2001 15:59:05 -0800 Subject: [Python-bugs-list] [Bug #115903] sre: split exceeds recursion limit Message-ID: Bug #115903, was updated on 2000-Oct-03 04:45 Here is a current snapshot of the bug. Project: Python Category: Regular Expressions Status: Closed Resolution: Fixed Bug Group: None Priority: 6 Submitted by: dundacek Assigned to : effbot Summary: sre: split exceeds recursion limit Details: Python 1.6 (#2, Sep 6 2000, 18:20:07) [C] on osf1V4 >>> import sre >>> import pre >>> txt=open("file").read() >>> patt1=sre.compile('a.*?bb', sre.DOTALL) >>> patt2=pre.compile('a.*?bb', pre.DOTALL) >>> patt1.split(txt) # ERROR Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python1.6/sre.py", line 146, in _split m = c.search() RuntimeError: maximum recursion limit exceeded >>> patt2.split(txt) # OK ['begin\012', '\012end\012'] where file content is: begin atttttttb atttttttb ... atttttttb atttttttb atttttttbb end If string "atttttttb" is repeated more than 1000 times sre ends with RuntimeError. If "attttttt" or "atttttttbb" are used instead of "atttttttb" lines, there is no problem. Follow-Ups: Date: 2001-Jan-14 15:59 By: effbot Comment: same as 115696 ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=115903&group_id=5470 From noreply@sourceforge.net Mon Jan 15 10:07:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 02:07:52 -0800 Subject: [Python-bugs-list] [Bug #128823] uncompatible re.findall() with the new engine = "sre" Message-ID: Bug #128823, was updated on 2001-Jan-15 02:07 Here is a current snapshot of the bug. Project: Python Category: Regular Expressions Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : nobody Summary: uncompatible re.findall() with the new engine = "sre" Details: The following example code: ------------------------------------- import re strA = ('1,"2",1,3') strB = ('1,"2","2",3') # from Perl cookbook for parsing CSV lines: pattern = r'"([^\"\\]*(?:\\.[^\"\\]*)*)",?|([^,]+),?|,' lstA = re.findall(pattern,strA) for tupl in lstA: print tupl print lstB = re.findall(pattern,strB) for tupl in lstB: print tupl ------------------------------------- produces the following (correct) input for re.engine = "pre": ('', '1') ('2', '') ('', '1') ('', '3') ('', '1') ('2', '') ('2', '') ('', '3') and the following (STRANGE!) output for re.engine = "sre": ('', '1') ('2', '1') ('2', '1') ('2', '3') ('', '1') ('2', '1') ('2', '1') ('2', '3') It seems as the matching group's value don't reset between the iterations of findall(). For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128823&group_id=5470 From noreply@sourceforge.net Mon Jan 15 11:31:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 03:31:19 -0800 Subject: [Python-bugs-list] [Bug #128830] re is greedy with non-greedy operator Message-ID: Bug #128830, was updated on 2001-Jan-15 03:31 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: beroul Assigned to : nobody Summary: re is greedy with non-greedy operator Details: In the program below, the pattern "" is used to match an SGML comment. Despite the use of the non-greedy operator '?', re fails to find the shortest possible match, which would be the comment preceding " """ element_pattern = re.compile(r"(?P\s+)" r"(?P)", re.DOTALL) match = element_pattern.search(dtd_text) if match: print "Matched comment:" print "----------------" print match.group("comment") print "Matched tag text:" print "-----------------" print match.group("tag_text") else: print "No match found." For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128830&group_id=5470 From noreply@sourceforge.net Mon Jan 15 11:49:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 03:49:46 -0800 Subject: [Python-bugs-list] [Bug #128830] re is greedy with non-greedy operator Message-ID: Bug #128830, was updated on 2001-Jan-15 03:31 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: beroul Assigned to : nobody Summary: re is greedy with non-greedy operator Details: In the program below, the pattern "" is used to match an SGML comment. Despite the use of the non-greedy operator '?', re fails to find the shortest possible match, which would be the comment preceding " """ element_pattern = re.compile(r"(?P\s+)" r"(?P)", re.DOTALL) match = element_pattern.search(dtd_text) if match: print "Matched comment:" print "----------------" print match.group("comment") print "Matched tag text:" print "-----------------" print match.group("tag_text") else: print "No match found." Follow-Ups: Date: 2001-Jan-15 03:49 By: beroul Comment: Actually, here's a minimal example: given the string "foo", the pattern "<.*?>foo" will match the entire string, when it should match only "foo". ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128830&group_id=5470 From noreply@sourceforge.net Mon Jan 15 14:28:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 06:28:55 -0800 Subject: [Python-bugs-list] [Bug #128823] uncompatible re.findall() with the new engine = "sre" Message-ID: Bug #128823, was updated on 2001-Jan-15 02:07 Here is a current snapshot of the bug. Project: Python Category: Regular Expressions Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : effbot Summary: uncompatible re.findall() with the new engine = "sre" Details: The following example code: ------------------------------------- import re strA = ('1,"2",1,3') strB = ('1,"2","2",3') # from Perl cookbook for parsing CSV lines: pattern = r'"([^\"\\]*(?:\\.[^\"\\]*)*)",?|([^,]+),?|,' lstA = re.findall(pattern,strA) for tupl in lstA: print tupl print lstB = re.findall(pattern,strB) for tupl in lstB: print tupl ------------------------------------- produces the following (correct) input for re.engine = "pre": ('', '1') ('2', '') ('', '1') ('', '3') ('', '1') ('2', '') ('2', '') ('', '3') and the following (STRANGE!) output for re.engine = "sre": ('', '1') ('2', '1') ('2', '1') ('2', '3') ('', '1') ('2', '1') ('2', '1') ('2', '3') It seems as the matching group's value don't reset between the iterations of findall(). For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128823&group_id=5470 From noreply@sourceforge.net Mon Jan 15 14:36:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 06:36:01 -0800 Subject: [Python-bugs-list] [Bug #128830] re is greedy with non-greedy operator Message-ID: Bug #128830, was updated on 2001-Jan-15 03:31 Here is a current snapshot of the bug. Project: Python Category: Regular Expressions Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: beroul Assigned to : effbot Summary: re is greedy with non-greedy operator Details: In the program below, the pattern "" is used to match an SGML comment. Despite the use of the non-greedy operator '?', re fails to find the shortest possible match, which would be the comment preceding " """ element_pattern = re.compile(r"(?P\s+)" r"(?P)", re.DOTALL) match = element_pattern.search(dtd_text) if match: print "Matched comment:" print "----------------" print match.group("comment") print "Matched tag text:" print "-----------------" print match.group("tag_text") else: print "No match found." Follow-Ups: Date: 2001-Jan-15 03:49 By: beroul Comment: Actually, here's a minimal example: given the string "foo", the pattern "<.*?>foo" will match the entire string, when it should match only "foo". ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128830&group_id=5470 From noreply@sourceforge.net Mon Jan 15 16:33:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 08:33:44 -0800 Subject: [Python-bugs-list] [Bug #126851] ftplib.py should default to passive mode Message-ID: Bug #126851, was updated on 2000-Dec-26 12:07 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Closed Resolution: None Bug Group: Feature Request Priority: 4 Submitted by: flight Assigned to : gvanrossum Summary: ftplib.py should default to passive mode Details: For the Debian package, there has been the request that the ftplib module should by default use passive FTP. Any comments [Forwarded from the Debian bug tracking system, bug#71823] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=71823&repeatmerged=yes Sender: Mike Fisk Package: python-base Version: 1.5.2-10 This is an upstream bug that has existed for quite a while (probably forever). With many systems living behind firewalls (including their own ipchains filters), passive FTP should be the default for FTP clients. It always has been for Netscape and there hasn't been much uproar about that being bad. Python's ftplib.py supports passive mode, but defaults to non-passive mode. ftplib.py is used by other Debian packages such as the downloader in xanim-modules. The result, when living behind many firewalls, is that you can't download anything using ftplib.py or urllib.py. The patch to fix this is trivial: --- /usr/lib/python1.5/ftplib.py Sat Sep 16 14:31:35 2000 +++ /tmp/ftplib.py Sat Sep 16 14:31:24 2000 @@ -112,7 +112,7 @@ - port: port to connect to (integer, default previous port)''' if host: self.host = host if port: self.port = port - self.passiveserver = 0 + self.passiveserver = 1 self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.sock.connect(self.host, self.port) self.file = self.sock.makefile('rb') -- Mike Fisk, RADIANT Team, Network Engineering Group, Los Alamos National Lab See http://home.lanl.gov/mfisk/ for contact information Follow-Ups: Date: 2001-Jan-15 08:33 By: gvanrossum Comment: You've convinced me. I've checked the change in, so it will (hopefully) get some testing during the 2.1 alpha and beta test phases. ------------------------------------------------------- Date: 2001-Jan-13 15:19 By: mfisk Comment: Since I only use the urllib interface, changing it would be sufficient for me, but I'm not sure that it's the "best" thing for all the other ftplib users. I agree that this would break an FTP into a firewall that currently works. I've had occaision to do this (although not with ftplib), but it's pretty rare. I strongly believe that FTPing to a service behind a filter is much less common than FTPing from a client that is behind a filter. Assuming that people agree that that statement, it's mainly a question of being willing to break some small number of existing users in order to fix some larger number of users. My personal preference would be to make the library default to a state that is most frequently functional (passive). Different projects have different customs when it comes to changing existing semantics --- I'll defer to whatever the usual custom here is. For our site's firewall documentation, we did a study of which popular clients default to or support passive. For web browsers, it is common to default to passive. For normal FTP clients (including GUI clients on Mac & Windows), the default seems to be non-passive. Internet Explorer seems to almost alternate between releases. Some FTP client implementations try one option (passive or not) and automatically revert to the other after some timeout. Getting this right seems more difficult than it's worth unless somebody is ambitious in this regard. ncftp seems to default to this if anybody is interested in looking at their code. One could argue that since passivity is a negotiated option in the FTP protocol, a server than cannot accept passive connections should not accept the PASV command. In this case the client could back-off to non-passive mode. Unfortunately, I have no reason to believe that any common FTP servers have this option or that their administrators would use it. ------------------------------------------------------- Date: 2001-Jan-08 17:57 By: gvanrossum Comment: Thomas Wouters raised the concern that passive mode makes it impossible to access servers that are inside a firewall. I'm not sure that this is a showstopper (does anybody do that?) but I'd like to stay on the careful side. Thomas noted that ftplib is used for more diverse tasks than Netscape. Would it be sufficient to make a change to urllib that changes the connection to passive mode in its ftpwrapper class? That would solve the problem for urllib (most comparable to Netscape) without breaking any code that directly uses ftplib. ------------------------------------------------------- Date: 2000-Dec-27 15:16 By: gvanrossum Comment: Hmm... I like the proposed patch. I don't know about ftp'ing into a firewall -- why would that be common? Typically ftp servers live outside firewalls because ftp is considered insecure... ------------------------------------------------------- Date: 2000-Dec-27 14:13 By: twouters Comment: For what it's worth, I mildly agree that passive mode should be the default. However, it does have potential for breaking stuff: using passive-ftp *into* a firewall, instead of out of one, doesn't work. And I'm pretty sure that Python's ftplib is used much more often in that manner than is Netscape or whatever other ftp client defaults to passive. It's probably not much, but I think it's enough to think twice about changing the default ;P ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=126851&group_id=5470 From noreply@sourceforge.net Mon Jan 15 16:53:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 08:53:45 -0800 Subject: [Python-bugs-list] [Bug #128823] uncompatible re.findall() with the new engine = "sre" Message-ID: Bug #128823, was updated on 2001-Jan-15 02:07 Here is a current snapshot of the bug. Project: Python Category: Regular Expressions Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: nobody Assigned to : effbot Summary: uncompatible re.findall() with the new engine = "sre" Details: The following example code: ------------------------------------- import re strA = ('1,"2",1,3') strB = ('1,"2","2",3') # from Perl cookbook for parsing CSV lines: pattern = r'"([^\"\\]*(?:\\.[^\"\\]*)*)",?|([^,]+),?|,' lstA = re.findall(pattern,strA) for tupl in lstA: print tupl print lstB = re.findall(pattern,strB) for tupl in lstB: print tupl ------------------------------------- produces the following (correct) input for re.engine = "pre": ('', '1') ('2', '') ('', '1') ('', '3') ('', '1') ('2', '') ('2', '') ('', '3') and the following (STRANGE!) output for re.engine = "sre": ('', '1') ('2', '1') ('2', '1') ('2', '3') ('', '1') ('2', '1') ('2', '1') ('2', '3') It seems as the matching group's value don't reset between the iterations of findall(). Follow-Ups: Date: 2001-Jan-15 08:53 By: effbot Comment: this was fixed in the CVS version in October 2000. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128823&group_id=5470 From noreply@sourceforge.net Mon Jan 15 17:04:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 09:04:26 -0800 Subject: [Python-bugs-list] [Bug #128830] re is greedy with non-greedy operator Message-ID: Bug #128830, was updated on 2001-Jan-15 03:31 Here is a current snapshot of the bug. Project: Python Category: Regular Expressions Status: Closed Resolution: Wont Fix Bug Group: None Priority: 5 Submitted by: beroul Assigned to : effbot Summary: re is greedy with non-greedy operator Details: In the program below, the pattern "" is used to match an SGML comment. Despite the use of the non-greedy operator '?', re fails to find the shortest possible match, which would be the comment preceding " """ element_pattern = re.compile(r"(?P\s+)" r"(?P)", re.DOTALL) match = element_pattern.search(dtd_text) if match: print "Matched comment:" print "----------------" print match.group("comment") print "Matched tag text:" print "-----------------" print match.group("tag_text") else: print "No match found." Follow-Ups: Date: 2001-Jan-15 09:04 By: effbot Comment: Python's RE search method doesn't look for the shortest possible match, it looks for the *first* possible match. (or in other words, Python provide Perl-style semantics, not POSIX semantics) ------------------------------------------------------- Date: 2001-Jan-15 03:49 By: beroul Comment: Actually, here's a minimal example: given the string "foo", the pattern "<.*?>foo" will match the entire string, when it should match only "foo". ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128830&group_id=5470 From noreply@sourceforge.net Mon Jan 15 18:03:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 10:03:30 -0800 Subject: [Python-bugs-list] [Bug #128899] SRE fails to match when using {m,n} syntax Message-ID: Bug #128899, was updated on 2001-Jan-15 10:03 Here is a current snapshot of the bug. Project: Python Category: Regular Expressions Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: effbot Assigned to : nobody Summary: SRE fails to match when using {m,n} syntax Details: from comp.lang.python: I find the following bug/feature/difference between the new and older re modules, is this a known feature? Seems like the new re doesn't like {m,n} modifiers. >>> import re, pre >>> P = re.compile('\\{(M{1,5}|YYYY|YY|D{1,4})\\}',re.MULTILINE|re.IGNORECASE) >>> oP = pre.compile('\\{(M{1,5}|YYYY|YY|D{1,4})\\}',re.MULTILINE|re.IGNORECASE) >>> P.match('{MMMMM}') >>> oP.match('{MMMMM}') >>> -- Robin Becker For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128899&group_id=5470 From noreply@sourceforge.net Mon Jan 15 18:04:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 10:04:01 -0800 Subject: [Python-bugs-list] [Bug #128899] SRE fails to match when using {m,n} syntax Message-ID: Bug #128899, was updated on 2001-Jan-15 10:03 Here is a current snapshot of the bug. Project: Python Category: Regular Expressions Status: Open Resolution: None Bug Group: None Priority: 6 Submitted by: effbot Assigned to : effbot Summary: SRE fails to match when using {m,n} syntax Details: from comp.lang.python: I find the following bug/feature/difference between the new and older re modules, is this a known feature? Seems like the new re doesn't like {m,n} modifiers. >>> import re, pre >>> P = re.compile('\\{(M{1,5}|YYYY|YY|D{1,4})\\}',re.MULTILINE|re.IGNORECASE) >>> oP = pre.compile('\\{(M{1,5}|YYYY|YY|D{1,4})\\}',re.MULTILINE|re.IGNORECASE) >>> P.match('{MMMMM}') >>> oP.match('{MMMMM}') >>> -- Robin Becker For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128899&group_id=5470 From noreply@sourceforge.net Mon Jan 15 18:29:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 10:29:47 -0800 Subject: [Python-bugs-list] [Bug #128899] SRE: ignorecase doesn't work for uppercase literals (!) Message-ID: Bug #128899, was updated on 2001-Jan-15 10:03 Here is a current snapshot of the bug. Project: Python Category: Regular Expressions Status: Closed Resolution: Fixed Bug Group: None Priority: 6 Submitted by: effbot Assigned to : effbot Summary: SRE: ignorecase doesn't work for uppercase literals (!) Details: from comp.lang.python: I find the following bug/feature/difference between the new and older re modules, is this a known feature? Seems like the new re doesn't like {m,n} modifiers. >>> import re, pre >>> P = re.compile('\\{(M{1,5}|YYYY|YY|D{1,4})\\}',re.MULTILINE|re.IGNORECASE) >>> oP = pre.compile('\\{(M{1,5}|YYYY|YY|D{1,4})\\}',re.MULTILINE|re.IGNORECASE) >>> P.match('{MMMMM}') >>> oP.match('{MMMMM}') >>> -- Robin Becker Follow-Ups: Date: 2001-Jan-15 10:29 By: effbot Comment: using uppercase literals with the ignorecase flag caused the match to fail. this was a really stupid bug. enough said ;-) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128899&group_id=5470 From noreply@sourceforge.net Mon Jan 15 19:54:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 11:54:47 -0800 Subject: [Python-bugs-list] [Bug #128475] mimetools.encode (sometimes) fails when called from a thread Message-ID: Bug #128475, was updated on 2001-Jan-11 11:05 Here is a current snapshot of the bug. Project: Python Category: Threads Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: nobody Assigned to : tim_one Summary: mimetools.encode (sometimes) fails when called from a thread Details: I used this script to test. The code of filesender.prepare_msgs is at the end of the report. ## import threading import filesender file = open('c:/windows/desktop/mp3/Aphex Twin - Bucephalus Bouncing Ball.mp3', 'rb') t1 = threading.Thread(target=filesender.prepare_msgs, args=(file,'a@b.c')) from cStringIO import StringIO data = StringIO() import mimetools t2=threading.Thread(target=mimetools.encode, args=(file,data,'base64')) import sys if '-t1' in sys.argv: t1.start() elif '-t2' in sys.argv: t2.start() else: filesender.prepare_msgs(file, 'a@b.c') ## Results of running it with -t1, -t2, and no options, on Windows: C:\Python20>python test.py -t1 preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 Fatal Python error: Interpreter not initialized (version mismatch?) abnormal program termination C:\Python20>python test.py -t1 preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 Fatal Python error: Interpreter not initialized (version mismatch?) abnormal program termination C:\Python20>python test.py -t2 Fatal Python error: Interpreter not initialized (version mismatch?) abnormal program termination C:\Python20>python test.py -t2 C:\Python20>python test.py preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 encoded got value data length is 7807732 Encoded Aphex Twin - Bucephalus Bouncing Ball.mp3 is too large, splitting into 2 parts C:\Python20>python test.py preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 encoded got value data length is 7807732 Encoded Aphex Twin - Bucephalus Bouncing Ball.mp3 is too large, splitting into 2 parts On Linux: wolfson@senator:~% python test.py preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 encoded got value data length is 7807732 Encoded Aphex Twin - Bucephalus Bouncing Ball.mp3 is too large, splitting into 2 p arts wolfson@senator:~% python test.py -t1 preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 Fatal Python error: Interpreter not initialized (version mismatch?) Abort wolfson@senator:~% python test.py -t1 preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 Fatal Python error: Interpreter not initialized (version mismatch?) Abort wolfson@senator:~% python test.py -t2 Fatal Python error: Interpreter not initialized (version mismatch?) Abort wolfson@senator:~% python test.py -t2 Fatal Python error: Interpreter not initialized (version mismatch?) Abort wolfson@senator:~% python test.py -t2 Fatal Python error: Interpreter not initialized (version mismatch?) Abort On Sun 5 it seems to always succeed. The code for filesender.prepare_msgs: def prepare_msgs(file, addressee): data = StringIO.StringIO() fn = getname(file) print 'preparing %s' % fn mimetools.encode(file, data, 'base64') print 'encoded' data = data.getvalue() print 'got value' datalen = len(data) print 'data length is %d' % datalen if datalen > MAX_MSG_SZ: numsplits = 1 + datalen / MAX_MSG_SZ print 'Encoded %s is too large, splitting into %d parts' % (fn,numsplits) msgs = [] for i in range(numsplits): thismsg, data = data[:MAX_MSG_SZ], data[MAX_MSG_SZ:] msgs.append(fmt_message(fn, addressee, thismsg, '(%d/%d)' % (i+1, numsplits), MSG)) return msgs return [fmt_message(fn, addressee, data, '', MSG)] Follow-Ups: Date: 2001-Jan-15 11:54 By: gvanrossum Comment: I'm assigning this to Tim, our all-purpose Windows cleaner. :-) Thread problems like this are notoriously hard to find, so don't hold your breath. Sorry! Setting the group to platform-specific since you mention it works fine on Sun5. ------------------------------------------------------- Date: 2001-Jan-13 08:13 By: nobody Comment: I'll get you! ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128475&group_id=5470 From noreply@sourceforge.net Mon Jan 15 20:43:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 12:43:13 -0800 Subject: [Python-bugs-list] [Bug #128921] string.count crashes on Unicode Message-ID: Bug #128921, was updated on 2001-Jan-15 12:43 Here is a current snapshot of the bug. Project: Python Category: Unicode Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : nobody Summary: string.count crashes on Unicode Details: 'hello world'.count(u'foo') For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128921&group_id=5470 From noreply@sourceforge.net Mon Jan 15 21:35:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 13:35:26 -0800 Subject: [Python-bugs-list] [Bug #128930] Inconsistent -L, -R options Message-ID: Bug #128930, was updated on 2001-Jan-15 13:35 Here is a current snapshot of the bug. Project: Python Category: Distutils Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: akuchling Assigned to : nobody Summary: Inconsistent -L, -R options Details: Martin von Loewis observes: python setup.py build_ext -L/tmp -lbla works now for me. Unfortunately, passing -R is still broken; python setup.py build_ext -L/tmp -R/tmp -lbla Also, I wonder what the rationale is for supporting -L/tmp:/var/tmp, while not supporting the Unixish -L/tmp -L/var/tmp. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128930&group_id=5470 From noreply@sourceforge.net Mon Jan 15 21:50:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 13:50:14 -0800 Subject: [Python-bugs-list] [Bug #128830] re is greedy with non-greedy operator Message-ID: Bug #128830, was updated on 2001-Jan-15 03:31 Here is a current snapshot of the bug. Project: Python Category: Regular Expressions Status: Closed Resolution: Wont Fix Bug Group: None Priority: 5 Submitted by: beroul Assigned to : effbot Summary: re is greedy with non-greedy operator Details: In the program below, the pattern "" is used to match an SGML comment. Despite the use of the non-greedy operator '?', re fails to find the shortest possible match, which would be the comment preceding " """ element_pattern = re.compile(r"(?P\s+)" r"(?P)", re.DOTALL) match = element_pattern.search(dtd_text) if match: print "Matched comment:" print "----------------" print match.group("comment") print "Matched tag text:" print "-----------------" print match.group("tag_text") else: print "No match found." Follow-Ups: Date: 2001-Jan-15 13:50 By: tim_one Comment: FYI, POSIX semantics also matches at the leftmost-possible position (and then finds the longest (or shortest) possible match at that point, without regard to the ordering of alternatives etc -- it's the latter point where the semantics differ from Perl/Python/Emacs/etc). I don't know of any regexp implementation that acts the way beroul expected. He could use re.findall() to find all the comments and then pick the shortest himself, though. ------------------------------------------------------- Date: 2001-Jan-15 09:04 By: effbot Comment: Python's RE search method doesn't look for the shortest possible match, it looks for the *first* possible match. (or in other words, Python provide Perl-style semantics, not POSIX semantics) ------------------------------------------------------- Date: 2001-Jan-15 03:49 By: beroul Comment: Actually, here's a minimal example: given the string "foo", the pattern "<.*?>foo" will match the entire string, when it should match only "foo". ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128830&group_id=5470 From noreply@sourceforge.net Mon Jan 15 22:59:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 14:59:20 -0800 Subject: [Python-bugs-list] [Bug #128930] Inconsistent -L, -R options Message-ID: Bug #128930, was updated on 2001-Jan-15 13:35 Here is a current snapshot of the bug. Project: Python Category: Distutils Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: akuchling Assigned to : akuchling Summary: Inconsistent -L, -R options Details: Martin von Loewis observes: python setup.py build_ext -L/tmp -lbla works now for me. Unfortunately, passing -R is still broken; python setup.py build_ext -L/tmp -R/tmp -lbla Also, I wonder what the rationale is for supporting -L/tmp:/var/tmp, while not supporting the Unixish -L/tmp -L/var/tmp. Follow-Ups: Date: 2001-Jan-15 14:59 By: bwarsaw Comment: I'm not sure how it's broken for you, but when I try to build the pybsddb3 package passing in a -R flag I get the following exception: % python setup.py build_ext -R/usr/local/BerkeleyDB.3.1 --inplace running build_ext building 'bsddb3._db' extension skipping src/_db.c (build/temp.linux-i686-2.0/src/_db.o up-to-date) Traceback (most recent call last): File "setup.py", line 122, in ? data_files = utils, File "/usr/local/lib/python2.0/distutils/core.py", line 138, in setup dist.run_commands() File "/usr/local/lib/python2.0/distutils/dist.py", line 867, in run_commands self.run_command(cmd) File "/usr/local/lib/python2.0/distutils/dist.py", line 887, in run_command cmd_obj.run() File "/usr/local/lib/python2.0/distutils/command/build_ext.py", line 225, in run self.build_extensions() File "/usr/local/lib/python2.0/distutils/command/build_ext.py", line 441, in build_extensions build_temp=self.build_temp) File "/usr/local/lib/python2.0/distutils/ccompiler.py", line 662, in link_shared_object extra_preargs, extra_postargs, build_temp) File "/usr/local/lib/python2.0/distutils/unixccompiler.py", line 208, in link (libraries, library_dirs, runtime_library_dirs) = \ File "/usr/local/lib/python2.0/distutils/ccompiler.py", line 438, in _fix_lib_args runtime_library_dirs = (list (runtime_library_dirs) + TypeError: can only concatenate list (not "string") to list ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128930&group_id=5470 From noreply@sourceforge.net Mon Jan 15 23:28:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 15:28:48 -0800 Subject: [Python-bugs-list] [Bug #123625] "authinfo" belongs before "mode reader" in nntplib.py Message-ID: Bug #123625, was updated on 2000-Nov-27 12:20 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: mogul Assigned to : twouters Summary: "authinfo" belongs before "mode reader" in nntplib.py Details: On some secure news servers (Netcape Collabra in this case), a client cannot even set "mode reader" before providing authentication information. If you have Mailman attempt to gate news from such a server, it will error with an entry such as this in the logs: Nov 27 11:01:44 2000 gate_news(9768): Traceback (innermost last): Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/cron/gate_news", line 222, in ? Nov 27 11:01:44 2000 gate_news(9768): main() Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/cron/gate_news", line 203, in main Nov 27 11:01:44 2000 gate_news(9768): process_lists(lock) Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/cron/gate_news", line 148, in process_lists Nov 27 11:01:44 2000 gate_news(9768): conn, first, last = open_newsgroup(mlist) Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/cron/gate_news", line 75, in open_newsgroup Nov 27 11:01:44 2000 gate_news(9768): password=mm_cfg.NNTP_PASSWORD) Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/Mailman/pythonlib/nntplib.py", line 117, in __init__ Nov 27 11:01:44 2000 gate_news(9768): self.welcome = self.shortcmd('mode reader') Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/Mailman/pythonlib/nntplib.py", line 210, in shortcmd Nov 27 11:01:44 2000 gate_news(9768): return self.getresp() Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/Mailman/pythonlib/nntplib.py", line 184, in getresp Nov 27 11:01:44 2000 gate_news(9768): raise NNTPTemporaryError(resp) Nov 27 11:01:44 2000 gate_news(9768): Mailman.pythonlib.nntplib . NNTPTemporaryError : 480 Authentication required for command My solution: Move these lines... if readermode: try: self.welcome = self.shortcmd('mode reader') except NNTPPermanentError: # error 500, probably 'not implemented' pass to the end of NNTP's constructor, in other words, after the authinfo exchange is done. Bret Follow-Ups: Date: 2001-Jan-15 15:28 By: twouters Comment: Yes, after consulting with two INN/NNTP experts (or at least practitioners :) I'm now sure of my case. Some versions/installations/configurations of INN need 'mode reader' *before* authinfo, because 'mode reader' simply spawns 'nnrpd', losing the previously passed authinfo. I'll check in the workaround I suggested (try mode reader, catch autherror and send authinfo (if any)) sometime tomorrow or tonight. ------------------------------------------------------- Date: 2001-Jan-03 15:52 By: twouters Comment: It's not so simple :-( I already forgot all this stuff again, but here's what I remember: The reader-mode isn't covered by the RFC on NNTP (which is pretty old) but is basically yet another addition by INN (IIRC, that is). We had one particular setup where readmode really was necessary before anything else, including, IIRC, authinfo. That was because the nnrpd that could handle all that wasn't spawned until you gave the 'mode reader' command, and it couldn't pass that info. However, I need to doublecheck to be sure. I think we dropped most of that intricate setup when we built our new set of top-of-the-line newsservers using Diablo rather than INN. I'll consult with a couple of local news guru's tomorrow, see if I'm not remembering wrong. If I'm not, we may have to do some dancing around by sending readermode, catching autherror, and re-sending after authinfo in that case. ------------------------------------------------------- Date: 2001-Jan-03 14:08 By: gvanrossum Comment: Thomas, you seem to be the author of the readermode code. I was going to just check in the suggested change, but when I read the CVS logs, it mentioned that "mode reader" was sent before authentication, so perhaps there's a reason. If you agree with the suggestion here, please go ahead and check it in -- no need to go through the patch manager. ------------------------------------------------------- Date: 2001-Jan-02 22:30 By: bwarsaw Comment: This is more accurately a bug in Python's nntplib.py ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=123625&group_id=5470 From noreply@sourceforge.net Tue Jan 16 00:33:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 16:33:52 -0800 Subject: [Python-bugs-list] [Bug #128921] string.count crashes on Unicode Message-ID: Bug #128921, was updated on 2001-Jan-15 12:43 Here is a current snapshot of the bug. Project: Python Category: Unicode Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : nobody Summary: string.count crashes on Unicode Details: 'hello world'.count(u'foo') Follow-Ups: Date: 2001-Jan-15 16:33 By: mwh Comment: I've just submitted patch #103249 which I believe fixes this (and another problem to do with propogating exceptions properly). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128921&group_id=5470 From noreply@sourceforge.net Tue Jan 16 01:10:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 17:10:17 -0800 Subject: [Python-bugs-list] [Bug #128830] re is greedy with non-greedy operator Message-ID: Bug #128830, was updated on 2001-Jan-15 03:31 Here is a current snapshot of the bug. Project: Python Category: Regular Expressions Status: Closed Resolution: Wont Fix Bug Group: None Priority: 5 Submitted by: beroul Assigned to : effbot Summary: re is greedy with non-greedy operator Details: In the program below, the pattern "" is used to match an SGML comment. Despite the use of the non-greedy operator '?', re fails to find the shortest possible match, which would be the comment preceding " """ element_pattern = re.compile(r"(?P\s+)" r"(?P)", re.DOTALL) match = element_pattern.search(dtd_text) if match: print "Matched comment:" print "----------------" print match.group("comment") print "Matched tag text:" print "-----------------" print match.group("tag_text") else: print "No match found." Follow-Ups: Date: 2001-Jan-15 17:10 By: beroul Comment: OK, in that case, it might be helpful to clarify the documentation, which says that when you use ".*?", "as few characters as possible will be matched", i.e. that you will in fact get the shortest possible match. ------------------------------------------------------- Date: 2001-Jan-15 13:50 By: tim_one Comment: FYI, POSIX semantics also matches at the leftmost-possible position (and then finds the longest (or shortest) possible match at that point, without regard to the ordering of alternatives etc -- it's the latter point where the semantics differ from Perl/Python/Emacs/etc). I don't know of any regexp implementation that acts the way beroul expected. He could use re.findall() to find all the comments and then pick the shortest himself, though. ------------------------------------------------------- Date: 2001-Jan-15 09:04 By: effbot Comment: Python's RE search method doesn't look for the shortest possible match, it looks for the *first* possible match. (or in other words, Python provide Perl-style semantics, not POSIX semantics) ------------------------------------------------------- Date: 2001-Jan-15 03:49 By: beroul Comment: Actually, here's a minimal example: given the string "foo", the pattern "<.*?>foo" will match the entire string, when it should match only "foo". ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128830&group_id=5470 From noreply@sourceforge.net Tue Jan 16 02:33:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 18:33:15 -0800 Subject: [Python-bugs-list] [Bug #128965] Windows package does not seem to be compiled with thread sup Message-ID: Bug #128965, was updated on 2001-Jan-15 18:33 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : nobody Summary: Windows package does not seem to be compiled with thread sup Details: Occurs when attempting to use gadly: > Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32 > Type "copyright", "credits" or "license" for more information. > >>> import sys > >>> gadflydir=r"c:\program files\python20\lib\gadfly" > >>> sys.path.append(gadflydir) > >>> from gadfly import gadfly > >>> connection=gadfly() > >>> connection.startup("mydatabase", r"c:\data") > >>> cursor = connection.cursor() > >>> cursor.execute("create table ph(nm varchar, ph varchar)") > Fatal Python error: PyThreadState_Get: no current thread > > abnormal program termination > For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128965&group_id=5470 From noreply@sourceforge.net Tue Jan 16 02:52:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 18:52:37 -0800 Subject: [Python-bugs-list] [Bug #125919] docs for random, whrandom too complex Message-ID: Bug #125919, was updated on 2000-Dec-15 11:02 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 7 Submitted by: tim_one Assigned to : fdrake Summary: docs for random, whrandom too complex Details: From the docstring: """ x, random=random.random -> shuffle list x in place; return None. Optional arg random is a 0-argument function returning a random float in [0.0, 1.0); by default, the standard random.random. Note that for even rather small len(x), the total number of permutations of x is larger than the period of most random number generators; this implies that "most" permutations of a long sequence can never be generated. """ I would have added this myself to the docs, but don't understand the structure of the docs; e.g., I always thought whrandom was an internal implementation detail for random that wasn't meant to be exposed on its own, and the "Random Number Generator Interface" appears to be a half-baked Grand Generalization that was abandoned the day after it got dreamt up. Suggest the docs in this area would be much clearer if they documented the random module on its own, and dropped the sections on whrandom and the RNGI. Python's randomization facilities are too meager to merit so much complexity. Follow-Ups: Date: 2001-Jan-15 18:52 By: randrews Comment: Possible related typo from Python Library Reference section 5.3.1 on The Random Number Generator Interface: random () Returns the next random floating point number in the range [0.0 ... 1.0). Should the range read (0.0 ... 1.0) instead of [0.0 ... 1.0)? ------------------------------------------------------- Date: 2000-Dec-15 11:16 By: fdrake Comment: random.shuffle() was documented before I got the bug notice for this one! Your other comments still need to be dealt with, so I'll leave this open, but re-title it. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=125919&group_id=5470 From noreply@sourceforge.net Tue Jan 16 03:35:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 19:35:14 -0800 Subject: [Python-bugs-list] [Bug #125919] docs for random, whrandom too complex Message-ID: Bug #125919, was updated on 2000-Dec-15 11:02 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 7 Submitted by: tim_one Assigned to : fdrake Summary: docs for random, whrandom too complex Details: From the docstring: """ x, random=random.random -> shuffle list x in place; return None. Optional arg random is a 0-argument function returning a random float in [0.0, 1.0); by default, the standard random.random. Note that for even rather small len(x), the total number of permutations of x is larger than the period of most random number generators; this implies that "most" permutations of a long sequence can never be generated. """ I would have added this myself to the docs, but don't understand the structure of the docs; e.g., I always thought whrandom was an internal implementation detail for random that wasn't meant to be exposed on its own, and the "Random Number Generator Interface" appears to be a half-baked Grand Generalization that was abandoned the day after it got dreamt up. Suggest the docs in this area would be much clearer if they documented the random module on its own, and dropped the sections on whrandom and the RNGI. Python's randomization facilities are too meager to merit so much complexity. Follow-Ups: Date: 2001-Jan-15 19:35 By: tim_one Comment: No, the docs mean [0,1). People differ as to whether they favor [0,1) or (0,1), but Python picked [0,1) a long time ago. Doesn't mean you're ever going to see a 0, but does mean it won't be considered a bug if you do see one. Python's implementation of Wichmann-Hill actually ends with a mod operation, so a 0 return isn't impossible "in theory" (although on machines using proper IEEE-754 double arithmetic, I don't believe the hardware can actually generate a 0 from the sequence of operations Python performs). ------------------------------------------------------- Date: 2001-Jan-15 18:52 By: randrews Comment: Possible related typo from Python Library Reference section 5.3.1 on The Random Number Generator Interface: random () Returns the next random floating point number in the range [0.0 ... 1.0). Should the range read (0.0 ... 1.0) instead of [0.0 ... 1.0)? ------------------------------------------------------- Date: 2000-Dec-15 11:16 By: fdrake Comment: random.shuffle() was documented before I got the bug notice for this one! Your other comments still need to be dealt with, so I'll leave this open, but re-title it. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=125919&group_id=5470 From noreply@sourceforge.net Tue Jan 16 05:12:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 21:12:43 -0800 Subject: [Python-bugs-list] [Bug #128973] OpenBSD Problems with _funlockfile in fileobject.c Message-ID: Bug #128973, was updated on 2001-Jan-15 21:12 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: jpettit Assigned to : nobody Summary: OpenBSD Problems with _funlockfile in fileobject.c Details: When I compile the current CVS version of Python on OpenBSD 2.8, I get the following linker error: ld: _funlockfile: non-function jmpslot collect2: ld returned 1 exit status *** Error code 1 This function was first added to Python in version 2.97 of "fileobject.c". For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128973&group_id=5470 From noreply@sourceforge.net Tue Jan 16 06:19:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 22:19:22 -0800 Subject: [Python-bugs-list] [Bug #128973] OpenBSD Problems with _funlockfile in fileobject.c Message-ID: Bug #128973, was updated on 2001-Jan-15 21:12 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: jpettit Assigned to : nobody Summary: OpenBSD Problems with _funlockfile in fileobject.c Details: When I compile the current CVS version of Python on OpenBSD 2.8, I get the following linker error: ld: _funlockfile: non-function jmpslot collect2: ld returned 1 exit status *** Error code 1 This function was first added to Python in version 2.97 of "fileobject.c". Follow-Ups: Date: 2001-Jan-15 22:19 By: tim_one Comment: Ho ho ho: so this means some flavor of Unix has getc_unlocked() but not the flockfile() and funlockfile() that are supposed to come with it? Man, Windows looks better every day -- and so does the getline_via_fgets() hack ... ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128973&group_id=5470 From noreply@sourceforge.net Tue Jan 16 06:40:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 22:40:20 -0800 Subject: [Python-bugs-list] [Bug #123625] "authinfo" belongs before "mode reader" in nntplib.py Message-ID: Bug #123625, was updated on 2000-Nov-27 12:20 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: mogul Assigned to : twouters Summary: "authinfo" belongs before "mode reader" in nntplib.py Details: On some secure news servers (Netcape Collabra in this case), a client cannot even set "mode reader" before providing authentication information. If you have Mailman attempt to gate news from such a server, it will error with an entry such as this in the logs: Nov 27 11:01:44 2000 gate_news(9768): Traceback (innermost last): Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/cron/gate_news", line 222, in ? Nov 27 11:01:44 2000 gate_news(9768): main() Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/cron/gate_news", line 203, in main Nov 27 11:01:44 2000 gate_news(9768): process_lists(lock) Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/cron/gate_news", line 148, in process_lists Nov 27 11:01:44 2000 gate_news(9768): conn, first, last = open_newsgroup(mlist) Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/cron/gate_news", line 75, in open_newsgroup Nov 27 11:01:44 2000 gate_news(9768): password=mm_cfg.NNTP_PASSWORD) Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/Mailman/pythonlib/nntplib.py", line 117, in __init__ Nov 27 11:01:44 2000 gate_news(9768): self.welcome = self.shortcmd('mode reader') Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/Mailman/pythonlib/nntplib.py", line 210, in shortcmd Nov 27 11:01:44 2000 gate_news(9768): return self.getresp() Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/Mailman/pythonlib/nntplib.py", line 184, in getresp Nov 27 11:01:44 2000 gate_news(9768): raise NNTPTemporaryError(resp) Nov 27 11:01:44 2000 gate_news(9768): Mailman.pythonlib.nntplib . NNTPTemporaryError : 480 Authentication required for command My solution: Move these lines... if readermode: try: self.welcome = self.shortcmd('mode reader') except NNTPPermanentError: # error 500, probably 'not implemented' pass to the end of NNTP's constructor, in other words, after the authinfo exchange is done. Bret Follow-Ups: Date: 2001-Jan-15 22:40 By: twouters Comment: I've checked in a fix in revision 1.23 of Lib/nntplib.py. It should work, but I haven't been able to test it for the case it fixes. Mogul, maybe you can test this ? You should be able to grab the nntplib.py file from the CVS tree (using a CVS client, or the SourceForge CVSWeb page. Just replace the old nntplib.py in Mailman/pythonlib with the new one. Barry, if you are going to release a Mailman 2.0.2, you probably want to grab this revision and dump it in pythonlib/ -- it should work with Python 1.5.2. ------------------------------------------------------- Date: 2001-Jan-15 15:28 By: twouters Comment: Yes, after consulting with two INN/NNTP experts (or at least practitioners :) I'm now sure of my case. Some versions/installations/configurations of INN need 'mode reader' *before* authinfo, because 'mode reader' simply spawns 'nnrpd', losing the previously passed authinfo. I'll check in the workaround I suggested (try mode reader, catch autherror and send authinfo (if any)) sometime tomorrow or tonight. ------------------------------------------------------- Date: 2001-Jan-03 15:52 By: twouters Comment: It's not so simple :-( I already forgot all this stuff again, but here's what I remember: The reader-mode isn't covered by the RFC on NNTP (which is pretty old) but is basically yet another addition by INN (IIRC, that is). We had one particular setup where readmode really was necessary before anything else, including, IIRC, authinfo. That was because the nnrpd that could handle all that wasn't spawned until you gave the 'mode reader' command, and it couldn't pass that info. However, I need to doublecheck to be sure. I think we dropped most of that intricate setup when we built our new set of top-of-the-line newsservers using Diablo rather than INN. I'll consult with a couple of local news guru's tomorrow, see if I'm not remembering wrong. If I'm not, we may have to do some dancing around by sending readermode, catching autherror, and re-sending after authinfo in that case. ------------------------------------------------------- Date: 2001-Jan-03 14:08 By: gvanrossum Comment: Thomas, you seem to be the author of the readermode code. I was going to just check in the suggested change, but when I read the CVS logs, it mentioned that "mode reader" was sent before authentication, so perhaps there's a reason. If you agree with the suggestion here, please go ahead and check it in -- no need to go through the patch manager. ------------------------------------------------------- Date: 2001-Jan-02 22:30 By: bwarsaw Comment: This is more accurately a bug in Python's nntplib.py ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=123625&group_id=5470 From noreply@sourceforge.net Tue Jan 16 07:58:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jan 2001 23:58:34 -0800 Subject: [Python-bugs-list] [Bug #123625] "authinfo" belongs before "mode reader" in nntplib.py Message-ID: Bug #123625, was updated on 2000-Nov-27 12:20 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: mogul Assigned to : twouters Summary: "authinfo" belongs before "mode reader" in nntplib.py Details: On some secure news servers (Netcape Collabra in this case), a client cannot even set "mode reader" before providing authentication information. If you have Mailman attempt to gate news from such a server, it will error with an entry such as this in the logs: Nov 27 11:01:44 2000 gate_news(9768): Traceback (innermost last): Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/cron/gate_news", line 222, in ? Nov 27 11:01:44 2000 gate_news(9768): main() Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/cron/gate_news", line 203, in main Nov 27 11:01:44 2000 gate_news(9768): process_lists(lock) Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/cron/gate_news", line 148, in process_lists Nov 27 11:01:44 2000 gate_news(9768): conn, first, last = open_newsgroup(mlist) Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/cron/gate_news", line 75, in open_newsgroup Nov 27 11:01:44 2000 gate_news(9768): password=mm_cfg.NNTP_PASSWORD) Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/Mailman/pythonlib/nntplib.py", line 117, in __init__ Nov 27 11:01:44 2000 gate_news(9768): self.welcome = self.shortcmd('mode reader') Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/Mailman/pythonlib/nntplib.py", line 210, in shortcmd Nov 27 11:01:44 2000 gate_news(9768): return self.getresp() Nov 27 11:01:44 2000 gate_news(9768): File "/usr/share/mailman/Mailman/pythonlib/nntplib.py", line 184, in getresp Nov 27 11:01:44 2000 gate_news(9768): raise NNTPTemporaryError(resp) Nov 27 11:01:44 2000 gate_news(9768): Mailman.pythonlib.nntplib . NNTPTemporaryError : 480 Authentication required for command My solution: Move these lines... if readermode: try: self.welcome = self.shortcmd('mode reader') except NNTPPermanentError: # error 500, probably 'not implemented' pass to the end of NNTP's constructor, in other words, after the authinfo exchange is done. Bret Follow-Ups: Date: 2001-Jan-15 23:58 By: mogul Comment: Works like crazy! Thanks a ton, guys. ------------------------------------------------------- Date: 2001-Jan-15 22:40 By: twouters Comment: I've checked in a fix in revision 1.23 of Lib/nntplib.py. It should work, but I haven't been able to test it for the case it fixes. Mogul, maybe you can test this ? You should be able to grab the nntplib.py file from the CVS tree (using a CVS client, or the SourceForge CVSWeb page. Just replace the old nntplib.py in Mailman/pythonlib with the new one. Barry, if you are going to release a Mailman 2.0.2, you probably want to grab this revision and dump it in pythonlib/ -- it should work with Python 1.5.2. ------------------------------------------------------- Date: 2001-Jan-15 15:28 By: twouters Comment: Yes, after consulting with two INN/NNTP experts (or at least practitioners :) I'm now sure of my case. Some versions/installations/configurations of INN need 'mode reader' *before* authinfo, because 'mode reader' simply spawns 'nnrpd', losing the previously passed authinfo. I'll check in the workaround I suggested (try mode reader, catch autherror and send authinfo (if any)) sometime tomorrow or tonight. ------------------------------------------------------- Date: 2001-Jan-03 15:52 By: twouters Comment: It's not so simple :-( I already forgot all this stuff again, but here's what I remember: The reader-mode isn't covered by the RFC on NNTP (which is pretty old) but is basically yet another addition by INN (IIRC, that is). We had one particular setup where readmode really was necessary before anything else, including, IIRC, authinfo. That was because the nnrpd that could handle all that wasn't spawned until you gave the 'mode reader' command, and it couldn't pass that info. However, I need to doublecheck to be sure. I think we dropped most of that intricate setup when we built our new set of top-of-the-line newsservers using Diablo rather than INN. I'll consult with a couple of local news guru's tomorrow, see if I'm not remembering wrong. If I'm not, we may have to do some dancing around by sending readermode, catching autherror, and re-sending after authinfo in that case. ------------------------------------------------------- Date: 2001-Jan-03 14:08 By: gvanrossum Comment: Thomas, you seem to be the author of the readermode code. I was going to just check in the suggested change, but when I read the CVS logs, it mentioned that "mode reader" was sent before authentication, so perhaps there's a reason. If you agree with the suggestion here, please go ahead and check it in -- no need to go through the patch manager. ------------------------------------------------------- Date: 2001-Jan-02 22:30 By: bwarsaw Comment: This is more accurately a bug in Python's nntplib.py ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=123625&group_id=5470 From noreply@sourceforge.net Tue Jan 16 09:07:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 01:07:59 -0800 Subject: [Python-bugs-list] [Bug #128830] re is greedy with non-greedy operator Message-ID: Bug #128830, was updated on 2001-Jan-15 03:31 Here is a current snapshot of the bug. Project: Python Category: Regular Expressions Status: Closed Resolution: Wont Fix Bug Group: Not a Bug Priority: 5 Submitted by: beroul Assigned to : effbot Summary: re is greedy with non-greedy operator Details: In the program below, the pattern "" is used to match an SGML comment. Despite the use of the non-greedy operator '?', re fails to find the shortest possible match, which would be the comment preceding " """ element_pattern = re.compile(r"(?P\s+)" r"(?P)", re.DOTALL) match = element_pattern.search(dtd_text) if match: print "Matched comment:" print "----------------" print match.group("comment") print "Matched tag text:" print "-----------------" print match.group("tag_text") else: print "No match found." Follow-Ups: Date: 2001-Jan-16 01:07 By: effbot Comment: You forgot to read the documentation for the search method: "Scan through string looking for A LOCATION WHERE THIS REGULAR EXPRESSION PRODUCES A MATCH, and return a corresponding MatchObject instance" (my emphasis). The "*?" construct does exactly what the documentation says: it matches as few characters as possible, at THAT location. But sure, the documentation can always be improved. ------------------------------------------------------- Date: 2001-Jan-15 17:10 By: beroul Comment: OK, in that case, it might be helpful to clarify the documentation, which says that when you use ".*?", "as few characters as possible will be matched", i.e. that you will in fact get the shortest possible match. ------------------------------------------------------- Date: 2001-Jan-15 13:50 By: tim_one Comment: FYI, POSIX semantics also matches at the leftmost-possible position (and then finds the longest (or shortest) possible match at that point, without regard to the ordering of alternatives etc -- it's the latter point where the semantics differ from Perl/Python/Emacs/etc). I don't know of any regexp implementation that acts the way beroul expected. He could use re.findall() to find all the comments and then pick the shortest himself, though. ------------------------------------------------------- Date: 2001-Jan-15 09:04 By: effbot Comment: Python's RE search method doesn't look for the shortest possible match, it looks for the *first* possible match. (or in other words, Python provide Perl-style semantics, not POSIX semantics) ------------------------------------------------------- Date: 2001-Jan-15 03:49 By: beroul Comment: Actually, here's a minimal example: given the string "foo", the pattern "<.*?>foo" will match the entire string, when it should match only "foo". ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128830&group_id=5470 From noreply@sourceforge.net Tue Jan 16 11:54:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 03:54:13 -0800 Subject: [Python-bugs-list] [Bug #128921] string.count crashes on Unicode Message-ID: Bug #128921, was updated on 2001-Jan-15 12:43 Here is a current snapshot of the bug. Project: Python Category: Unicode Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: nobody Assigned to : lemburg Summary: string.count crashes on Unicode Details: 'hello world'.count(u'foo') Follow-Ups: Date: 2001-Jan-16 03:54 By: lemburg Comment: Modified patch checked in. ------------------------------------------------------- Date: 2001-Jan-15 16:33 By: mwh Comment: I've just submitted patch #103249 which I believe fixes this (and another problem to do with propogating exceptions properly). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128921&group_id=5470 From noreply@sourceforge.net Tue Jan 16 13:28:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 05:28:53 -0800 Subject: [Python-bugs-list] [Bug #128973] OpenBSD Problems with _funlockfile in fileobject.c Message-ID: Bug #128973, was updated on 2001-Jan-15 21:12 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: jpettit Assigned to : nobody Summary: OpenBSD Problems with _funlockfile in fileobject.c Details: When I compile the current CVS version of Python on OpenBSD 2.8, I get the following linker error: ld: _funlockfile: non-function jmpslot collect2: ld returned 1 exit status *** Error code 1 This function was first added to Python in version 2.97 of "fileobject.c". Follow-Ups: Date: 2001-Jan-16 05:28 By: gvanrossum Comment: It's gotta be more complicated that that. The configure script has a test program that calls flockfile(), getc_unlocked(), and funlockfile(). Only if this test program links successfully does it decide to use getc_unlocked(). (Making the test depend on successfully *running* it shouldn't make a difference -- the user here got a link-time error.) jpettit, is there a way you could find out why the configure test succeeds but then you get a link error linking Python? I'll also ask Thomas Wouters to look into this. ------------------------------------------------------- Date: 2001-Jan-15 22:19 By: tim_one Comment: Ho ho ho: so this means some flavor of Unix has getc_unlocked() but not the flockfile() and funlockfile() that are supposed to come with it? Man, Windows looks better every day -- and so does the getline_via_fgets() hack ... ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128973&group_id=5470 From noreply@sourceforge.net Tue Jan 16 13:36:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 05:36:21 -0800 Subject: [Python-bugs-list] [Bug #129000] struct should handle terminated strings Message-ID: Bug #129000, was updated on 2001-Jan-16 05:36 Here is a current snapshot of the bug. Project: Python Category: Extension Modules Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Submitted by: jahs Assigned to : nobody Summary: struct should handle terminated strings Details: Currently, python only handles fixed length strings and Pascal strings. It would be nice if struct could handle null-terminated strings, perhaps using "n" to denote them. A more general solution would be to allow arbitrary terminators for terminated strings. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129000&group_id=5470 From noreply@sourceforge.net Tue Jan 16 14:18:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 06:18:51 -0800 Subject: [Python-bugs-list] [Bug #128965] Crash on Windows (no current thread) with gadfly Message-ID: Bug #128965, was updated on 2001-Jan-15 18:33 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: 3rd Party Priority: 3 Submitted by: nobody Assigned to : tim_one Summary: Crash on Windows (no current thread) with gadfly Details: Occurs when attempting to use gadly: > Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32 > Type "copyright", "credits" or "license" for more information. > >>> import sys > >>> gadflydir=r"c:\program files\python20\lib\gadfly" > >>> sys.path.append(gadflydir) > >>> from gadfly import gadfly > >>> connection=gadfly() > >>> connection.startup("mydatabase", r"c:\data") > >>> cursor = connection.cursor() > >>> cursor.execute("create table ph(nm varchar, ph varchar)") > Fatal Python error: PyThreadState_Get: no current thread > > abnormal program termination > Follow-Ups: Date: 2001-Jan-16 06:18 By: gvanrossum Comment: The problem is not that Python for Windows hasn't been built with threads (as the subject originally suggested). But I don't know what the problem *is* -- it could well be a bug in gadfly, or it could be a Python bug triggered by gadfly. Assigning this to Tim, our universal Windows scapegoat. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128965&group_id=5470 From noreply@sourceforge.net Tue Jan 16 14:20:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 06:20:33 -0800 Subject: [Python-bugs-list] [Bug #129000] struct should handle terminated strings Message-ID: Bug #129000, was updated on 2001-Jan-16 05:36 Here is a current snapshot of the bug. Project: Python Category: Extension Modules Status: Closed Resolution: Wont Fix Bug Group: Feature Request Priority: 5 Submitted by: jahs Assigned to : gvanrossum Summary: struct should handle terminated strings Details: Currently, python only handles fixed length strings and Pascal strings. It would be nice if struct could handle null-terminated strings, perhaps using "n" to denote them. A more general solution would be to allow arbitrary terminators for terminated strings. Follow-Ups: Date: 2001-Jan-16 06:20 By: gvanrossum Comment: Decoding variable-lenth strings is not possible with the struct module. If the string space is fixed-length but you want it truncated at the first \0, I suggest that you write a little helper routine yourself. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129000&group_id=5470 From noreply@sourceforge.net Tue Jan 16 17:56:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 09:56:33 -0800 Subject: [Python-bugs-list] [Bug #128973] OpenBSD Problems with _funlockfile in fileobject.c Message-ID: Bug #128973, was updated on 2001-Jan-15 21:12 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: jpettit Assigned to : nobody Summary: OpenBSD Problems with _funlockfile in fileobject.c Details: When I compile the current CVS version of Python on OpenBSD 2.8, I get the following linker error: ld: _funlockfile: non-function jmpslot collect2: ld returned 1 exit status *** Error code 1 This function was first added to Python in version 2.97 of "fileobject.c". Follow-Ups: Date: 2001-Jan-16 09:56 By: jpettit Comment: I'd be happy to help however I can. However, autoconf is black magic to me. I think that funlockfile is supposed to be available...there is even a man page dated 20 August 1998. This may be another case of OpenBSD improperly integrating components from the other BSDs. Please let me know what I can do. ------------------------------------------------------- Date: 2001-Jan-16 05:28 By: gvanrossum Comment: It's gotta be more complicated that that. The configure script has a test program that calls flockfile(), getc_unlocked(), and funlockfile(). Only if this test program links successfully does it decide to use getc_unlocked(). (Making the test depend on successfully *running* it shouldn't make a difference -- the user here got a link-time error.) jpettit, is there a way you could find out why the configure test succeeds but then you get a link error linking Python? I'll also ask Thomas Wouters to look into this. ------------------------------------------------------- Date: 2001-Jan-15 22:19 By: tim_one Comment: Ho ho ho: so this means some flavor of Unix has getc_unlocked() but not the flockfile() and funlockfile() that are supposed to come with it? Man, Windows looks better every day -- and so does the getline_via_fgets() hack ... ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128973&group_id=5470 From noreply@sourceforge.net Tue Jan 16 19:00:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 11:00:17 -0800 Subject: [Python-bugs-list] [Bug #128973] OpenBSD Problems with _funlockfile in fileobject.c Message-ID: Bug #128973, was updated on 2001-Jan-15 21:12 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: jpettit Assigned to : nobody Summary: OpenBSD Problems with _funlockfile in fileobject.c Details: When I compile the current CVS version of Python on OpenBSD 2.8, I get the following linker error: ld: _funlockfile: non-function jmpslot collect2: ld returned 1 exit status *** Error code 1 This function was first added to Python in version 2.97 of "fileobject.c". Follow-Ups: Date: 2001-Jan-16 11:00 By: twouters Comment: Unfortunately, I don't have access to OpenBSD, just FreeBSD and BSDI. flockfile/funlockfile both work fine there. I suspect it's a header/library problem: maybe we need to include a separate header/library, which we for some reason do in the configure process, but not in the linking of Python (or maybe it needs additional magic to link together with other libraries, I don't know.) jpettit, can you check the manpage for funlockfile to see what headerfiles should be included, and perhaps what to link with ? Also, are you compiling threaded or unthreaded ? There is a good chance the flockfile/funlockfile functions are only available in threaded code, or maybe Python is being compiled half-threaded for some reason. Checking to see the difference between what config.log and 'make' say might give some hints, too. Or it could just be an OS bug :P We should be able to figure it out though: if Python can't *compile* with those functions, neither should configure. ------------------------------------------------------- Date: 2001-Jan-16 09:56 By: jpettit Comment: I'd be happy to help however I can. However, autoconf is black magic to me. I think that funlockfile is supposed to be available...there is even a man page dated 20 August 1998. This may be another case of OpenBSD improperly integrating components from the other BSDs. Please let me know what I can do. ------------------------------------------------------- Date: 2001-Jan-16 05:28 By: gvanrossum Comment: It's gotta be more complicated that that. The configure script has a test program that calls flockfile(), getc_unlocked(), and funlockfile(). Only if this test program links successfully does it decide to use getc_unlocked(). (Making the test depend on successfully *running* it shouldn't make a difference -- the user here got a link-time error.) jpettit, is there a way you could find out why the configure test succeeds but then you get a link error linking Python? I'll also ask Thomas Wouters to look into this. ------------------------------------------------------- Date: 2001-Jan-15 22:19 By: tim_one Comment: Ho ho ho: so this means some flavor of Unix has getc_unlocked() but not the flockfile() and funlockfile() that are supposed to come with it? Man, Windows looks better every day -- and so does the getline_via_fgets() hack ... ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128973&group_id=5470 From noreply@sourceforge.net Tue Jan 16 19:58:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 11:58:20 -0800 Subject: [Python-bugs-list] [Bug #128973] OpenBSD Problems with _funlockfile in fileobject.c Message-ID: Bug #128973, was updated on 2001-Jan-15 21:12 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: jpettit Assigned to : nobody Summary: OpenBSD Problems with _funlockfile in fileobject.c Details: When I compile the current CVS version of Python on OpenBSD 2.8, I get the following linker error: ld: _funlockfile: non-function jmpslot collect2: ld returned 1 exit status *** Error code 1 This function was first added to Python in version 2.97 of "fileobject.c". Follow-Ups: Date: 2001-Jan-16 11:58 By: jpettit Comment: The man page doesn't seem to specify a particular library to link against. It only says to include stdio.h. I'm building Python without any special flags. I thought threads were enabled by default, but just for good measure, I ran configure with --with-threads and got the same results. I don't see any reference to flockfile/funlockfile in config.log. ------------------------------------------------------- Date: 2001-Jan-16 11:00 By: twouters Comment: Unfortunately, I don't have access to OpenBSD, just FreeBSD and BSDI. flockfile/funlockfile both work fine there. I suspect it's a header/library problem: maybe we need to include a separate header/library, which we for some reason do in the configure process, but not in the linking of Python (or maybe it needs additional magic to link together with other libraries, I don't know.) jpettit, can you check the manpage for funlockfile to see what headerfiles should be included, and perhaps what to link with ? Also, are you compiling threaded or unthreaded ? There is a good chance the flockfile/funlockfile functions are only available in threaded code, or maybe Python is being compiled half-threaded for some reason. Checking to see the difference between what config.log and 'make' say might give some hints, too. Or it could just be an OS bug :P We should be able to figure it out though: if Python can't *compile* with those functions, neither should configure. ------------------------------------------------------- Date: 2001-Jan-16 09:56 By: jpettit Comment: I'd be happy to help however I can. However, autoconf is black magic to me. I think that funlockfile is supposed to be available...there is even a man page dated 20 August 1998. This may be another case of OpenBSD improperly integrating components from the other BSDs. Please let me know what I can do. ------------------------------------------------------- Date: 2001-Jan-16 05:28 By: gvanrossum Comment: It's gotta be more complicated that that. The configure script has a test program that calls flockfile(), getc_unlocked(), and funlockfile(). Only if this test program links successfully does it decide to use getc_unlocked(). (Making the test depend on successfully *running* it shouldn't make a difference -- the user here got a link-time error.) jpettit, is there a way you could find out why the configure test succeeds but then you get a link error linking Python? I'll also ask Thomas Wouters to look into this. ------------------------------------------------------- Date: 2001-Jan-15 22:19 By: tim_one Comment: Ho ho ho: so this means some flavor of Unix has getc_unlocked() but not the flockfile() and funlockfile() that are supposed to come with it? Man, Windows looks better every day -- and so does the getline_via_fgets() hack ... ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128973&group_id=5470 From noreply@sourceforge.net Tue Jan 16 21:18:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 13:18:07 -0800 Subject: [Python-bugs-list] [Bug #128251] Windows mmap docs need cleaning Message-ID: Bug #128251, was updated on 2001-Jan-09 21:14 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 6 Submitted by: tim_one Assigned to : akuchling Summary: Windows mmap docs need cleaning Details: WRT the docs for the Windows flavor of mmap.mmap(): 1) Doc needed: The file *must* be opened for update (r+, w+, rb+ or wb+). That's because CreateFileMapping is called with PAGE_READWRITE, and that won't let you increase permissions over the original open mode. Violating this yields baffling "The parameter is wrong" Windows errors from mmap.mmap(). 2) Doc needed: Passing a size of 0 makes the maximum size of the mapping the actual current size of the file. Don't know whether that's also true on Unices (ask AMK?); on Windows it's intentional; and it's handy to know so it's worth documenting. 3) Doc bug: The docs read as if omitting the optional tagname is different than supplying a tagname of None. I don't believe that's true; needs mild rewording. Fred and AMK and c.l.py got a longer version of this msg. I think the example of using mmap with re would be worth including too (but it would be nice to have an example that isn't Windows-specific! someone should try that on Linux too, and fiddle as needed). Follow-Ups: Date: 2001-Jan-16 13:18 By: akuchling Comment: As far as I can tell, length==0 is an error on Unix. It certainly doesn't seem to mean anything special on Unix. ------------------------------------------------------- Date: 2001-Jan-11 14:51 By: fdrake Comment: I've updated the documentation according to Tim's comments in Doc/lib/libmmap.tex revision 1.4. Andrew: do you know anything about passing a length of zero on Unix? I wasn't able to find anything in the mmap() man page, and don't have ready access to any other reference material at this time. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128251&group_id=5470 From noreply@sourceforge.net Wed Jan 17 01:48:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 17:48:56 -0800 Subject: [Python-bugs-list] [Bug #128965] Crash on Windows (no current thread) with gadfly Message-ID: Bug #128965, was updated on 2001-Jan-15 18:33 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: 3rd Party Priority: 3 Submitted by: nobody Assigned to : tim_one Summary: Crash on Windows (no current thread) with gadfly Details: Occurs when attempting to use gadly: > Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32 > Type "copyright", "credits" or "license" for more information. > >>> import sys > >>> gadflydir=r"c:\program files\python20\lib\gadfly" > >>> sys.path.append(gadflydir) > >>> from gadfly import gadfly > >>> connection=gadfly() > >>> connection.startup("mydatabase", r"c:\data") > >>> cursor = connection.cursor() > >>> cursor.execute("create table ph(nm varchar, ph varchar)") > Fatal Python error: PyThreadState_Get: no current thread > > abnormal program termination > Follow-Ups: Date: 2001-Jan-16 17:48 By: tim_one Comment: We don't write, maintain or even distribute gadfly. So unless the anonymous submitter resurfaces to explain where they got gadfly, and what Aaron (gadfly's author) had to say about it, I'm going to close this. ------------------------------------------------------- Date: 2001-Jan-16 06:18 By: gvanrossum Comment: The problem is not that Python for Windows hasn't been built with threads (as the subject originally suggested). But I don't know what the problem *is* -- it could well be a bug in gadfly, or it could be a Python bug triggered by gadfly. Assigning this to Tim, our universal Windows scapegoat. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128965&group_id=5470 From noreply@sourceforge.net Wed Jan 17 02:29:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jan 2001 18:29:03 -0800 Subject: [Python-bugs-list] [Bug #116388] cStringIO rejects Unicode strings Message-ID: Bug #116388, was updated on 2000-Oct-08 17:42 Here is a current snapshot of the bug. Project: Python Category: Unicode Status: Open Resolution: Later Bug Group: Feature Request Priority: 3 Submitted by: prescod Assigned to : fdrake Summary: cStringIO rejects Unicode strings Details: >>> import cStringIO >>> s=cStringIO.StringIO(u"abcdefgh") Traceback (innermost last): File "", line 1, in ? s=cStringIO.StringIO(u"abcdefgh") TypeError: expected string, unicode found Follow-Ups: Date: 2001-Jan-16 18:29 By: fdrake Comment: Lowered priority to reflect my previous comments; I don't think I'll have time to do this for Python 2.1. ------------------------------------------------------- Date: 2001-Jan-10 08:07 By: fdrake Comment: Status: Jim said I can work on it, but the priority isn't very high for him. ------------------------------------------------------- Date: 2001-Jan-07 19:56 By: fdrake Comment: Ok, ok, ok... I've sent a prod to appropriate people. This *should* be interesting to have done. ------------------------------------------------------- Date: 2000-Dec-12 13:00 By: gvanrossum Comment: Assigned to Fred -- maybe you can prod Jim into looking into this. ------------------------------------------------------- Date: 2000-Oct-09 01:34 By: lemburg Comment: I've marked this as feature request since making the standard lib Unicode compatible is a post-2.0 project (probably a good one for 2.1). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=116388&group_id=5470 From noreply@sourceforge.net Wed Jan 17 20:13:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 12:13:47 -0800 Subject: [Python-bugs-list] [Bug #129173] setup.py tries to build pyexpat in the absence of xmlparse.h Message-ID: Bug #129173, was updated on 2001-Jan-17 12:13 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: montanaro Assigned to : nobody Summary: setup.py tries to build pyexpat in the absence of xmlparse.h Details: Using the latest version of Andrew's setup.py, I get the following build failure: building 'pyexpat' extension gcc -g -O2 -Wall -Wstrict-prototypes -fPIC -fpic -I. -I/home/beluga/skip/src/python/dist/src/./Include -IInclude/ -c /home/beluga/skip/src/python/dist/src/Modules/pyexpat.c -o build/temp.linux-i686-2.1/pyexpat.o /home/beluga/skip/src/python/dist/src/Modules/pyexpat.c:5: xmlparse.h: No such file or directory error: command 'gcc' failed with exit status 1 Looks like it fails to properly test the prerequisites for building the pyexpat module. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129173&group_id=5470 From noreply@sourceforge.net Wed Jan 17 20:14:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 12:14:57 -0800 Subject: [Python-bugs-list] [Bug #129173] setup.py tries to build pyexpat in the absence of xmlparse.h Message-ID: Bug #129173, was updated on 2001-Jan-17 12:13 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: montanaro Assigned to : akuchling Summary: setup.py tries to build pyexpat in the absence of xmlparse.h Details: Using the latest version of Andrew's setup.py, I get the following build failure: building 'pyexpat' extension gcc -g -O2 -Wall -Wstrict-prototypes -fPIC -fpic -I. -I/home/beluga/skip/src/python/dist/src/./Include -IInclude/ -c /home/beluga/skip/src/python/dist/src/Modules/pyexpat.c -o build/temp.linux-i686-2.1/pyexpat.o /home/beluga/skip/src/python/dist/src/Modules/pyexpat.c:5: xmlparse.h: No such file or directory error: command 'gcc' failed with exit status 1 Looks like it fails to properly test the prerequisites for building the pyexpat module. Follow-Ups: Date: 2001-Jan-17 12:14 By: montanaro Comment: assigned to AMK since this is his baby... ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129173&group_id=5470 From noreply@sourceforge.net Wed Jan 17 20:30:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 12:30:14 -0800 Subject: [Python-bugs-list] [Bug #129173] setup.py tries to build pyexpat in the absence of xmlparse.h Message-ID: Bug #129173, was updated on 2001-Jan-17 12:13 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: montanaro Assigned to : akuchling Summary: setup.py tries to build pyexpat in the absence of xmlparse.h Details: Using the latest version of Andrew's setup.py, I get the following build failure: building 'pyexpat' extension gcc -g -O2 -Wall -Wstrict-prototypes -fPIC -fpic -I. -I/home/beluga/skip/src/python/dist/src/./Include -IInclude/ -c /home/beluga/skip/src/python/dist/src/Modules/pyexpat.c -o build/temp.linux-i686-2.1/pyexpat.o /home/beluga/skip/src/python/dist/src/Modules/pyexpat.c:5: xmlparse.h: No such file or directory error: command 'gcc' failed with exit status 1 Looks like it fails to properly test the prerequisites for building the pyexpat module. Follow-Ups: Date: 2001-Jan-17 12:30 By: akuchling Comment: This means you must have a libexpat.a installed somewhere, but not xmlparse.h. I used a beta of Expat 1.2, which installs itself normally, so this didn't happen. There's a '#if HAVE_EXPAT_H' test in pyexpat.c, but configure doesn't check for expat.h. I think I'll change setup.py to check for expat.h and xmlpath.h in that order. ------------------------------------------------------- Date: 2001-Jan-17 12:14 By: montanaro Comment: assigned to AMK since this is his baby... ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129173&group_id=5470 From noreply@sourceforge.net Wed Jan 17 20:51:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 12:51:54 -0800 Subject: [Python-bugs-list] [Bug #129173] setup.py tries to build pyexpat in the absence of xmlparse.h Message-ID: Bug #129173, was updated on 2001-Jan-17 12:13 Here is a current snapshot of the bug. Project: Python Category: Build Status: Closed Resolution: Fixed Bug Group: Platform-specific Priority: 5 Submitted by: montanaro Assigned to : akuchling Summary: setup.py tries to build pyexpat in the absence of xmlparse.h Details: Using the latest version of Andrew's setup.py, I get the following build failure: building 'pyexpat' extension gcc -g -O2 -Wall -Wstrict-prototypes -fPIC -fpic -I. -I/home/beluga/skip/src/python/dist/src/./Include -IInclude/ -c /home/beluga/skip/src/python/dist/src/Modules/pyexpat.c -o build/temp.linux-i686-2.1/pyexpat.o /home/beluga/skip/src/python/dist/src/Modules/pyexpat.c:5: xmlparse.h: No such file or directory error: command 'gcc' failed with exit status 1 Looks like it fails to properly test the prerequisites for building the pyexpat module. Follow-Ups: Date: 2001-Jan-17 12:51 By: akuchling Comment: Fixed in revision 1.4 of setup.py. ------------------------------------------------------- Date: 2001-Jan-17 12:30 By: akuchling Comment: This means you must have a libexpat.a installed somewhere, but not xmlparse.h. I used a beta of Expat 1.2, which installs itself normally, so this didn't happen. There's a '#if HAVE_EXPAT_H' test in pyexpat.c, but configure doesn't check for expat.h. I think I'll change setup.py to check for expat.h and xmlpath.h in that order. ------------------------------------------------------- Date: 2001-Jan-17 12:14 By: montanaro Comment: assigned to AMK since this is his baby... ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129173&group_id=5470 From noreply@sourceforge.net Wed Jan 17 21:57:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 13:57:20 -0800 Subject: [Python-bugs-list] [Bug #129179] Memory leak on repeated reloads Message-ID: Bug #129179, was updated on 2001-Jan-17 13:57 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: cgw Assigned to : nobody Summary: Memory leak on repeated reloads Details: boo.py: ========== Class Boo: pass a = [1] b = Boo() def testit(): try: divmod(a,b) except TypeError, msg: print msg testit() =========== import boo while 1: reload(boo) For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129179&group_id=5470 From noreply@sourceforge.net Thu Jan 18 00:46:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 16:46:28 -0800 Subject: [Python-bugs-list] [Bug #129193] make clean & make test failures with setup.py Message-ID: Bug #129193, was updated on 2001-Jan-17 16:46 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: montanaro Assigned to : nobody Summary: make clean & make test failures with setup.py Details: Building with setup.py has a couple problems. First, when executing "make clean", the .o and .so files in build/{lib,temp}* are not deleted. Second, when executing "make test" PYTHONPATH is not set to the build/lib* directory, so the python executable can't import any of them. I would try fixing this myself, but I don't know how to compute the names of the relevant subdirectories of build. I assume that something in distutils computes it. That may lead to a chicken and egg situation. If you want to execute "make clean" before you have a viable python executable you won't be able to run setup.py in any fashion to compute it. Alternatively, you could just clean by "rm -r build/*". If that's the only alternative, I'd suggest canning the architecture-specific directory names in build. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129193&group_id=5470 From noreply@sourceforge.net Thu Jan 18 00:47:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 16:47:19 -0800 Subject: [Python-bugs-list] [Bug #129193] make clean & make test failures with setup.py Message-ID: Bug #129193, was updated on 2001-Jan-17 16:46 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: montanaro Assigned to : akuchling Summary: make clean & make test failures with setup.py Details: Building with setup.py has a couple problems. First, when executing "make clean", the .o and .so files in build/{lib,temp}* are not deleted. Second, when executing "make test" PYTHONPATH is not set to the build/lib* directory, so the python executable can't import any of them. I would try fixing this myself, but I don't know how to compute the names of the relevant subdirectories of build. I assume that something in distutils computes it. That may lead to a chicken and egg situation. If you want to execute "make clean" before you have a viable python executable you won't be able to run setup.py in any fashion to compute it. Alternatively, you could just clean by "rm -r build/*". If that's the only alternative, I'd suggest canning the architecture-specific directory names in build. Follow-Ups: Date: 2001-Jan-17 16:47 By: montanaro Comment: again, it's Andrew's sandbox... ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129193&group_id=5470 From noreply@sourceforge.net Thu Jan 18 03:43:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 19:43:16 -0800 Subject: [Python-bugs-list] [Bug #129179] Memory leak on repeated reloads Message-ID: Bug #129179, was updated on 2001-Jan-17 13:57 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: cgw Assigned to : bwarsaw Summary: Memory leak on repeated reloads Details: boo.py: ========== Class Boo: pass a = [1] b = Boo() def testit(): try: divmod(a,b) except TypeError, msg: print msg testit() =========== import boo while 1: reload(boo) For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129179&group_id=5470 From noreply@sourceforge.net Thu Jan 18 06:05:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 22:05:37 -0800 Subject: [Python-bugs-list] [Bug #129205] simple typo Message-ID: Bug #129205, was updated on 2001-Jan-17 22:05 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : nobody Summary: simple typo Details: In the text below, "names to hid" should be "names to hide". 6.7.1 The dircmp class dircmp (a, b[, ignore[, hide]]) Construct a new directory comparison object, to compare the directories a and b. ignore is a list of names to ignore, and defaults to ['RCS', 'CVS', 'tags']. hide is a list of names to hid, and defaults to [os.curdir, os.pardir]. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129205&group_id=5470 From noreply@sourceforge.net Thu Jan 18 06:29:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 22:29:19 -0800 Subject: [Python-bugs-list] [Bug #129208] Doc and code mismatch Message-ID: Bug #129208, was updated on 2001-Jan-17 22:29 Here is a current snapshot of the bug. Project: Python Category: IDLE Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : nobody Summary: Doc and code mismatch Details: The help file mentions IdlePrefs.py, but the code includes no such file. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129208&group_id=5470 From noreply@sourceforge.net Thu Jan 18 06:31:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jan 2001 22:31:21 -0800 Subject: [Python-bugs-list] [Bug #129205] simple typo Message-ID: Bug #129205, was updated on 2001-Jan-17 22:05 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : nobody Summary: simple typo Details: In the text below, "names to hid" should be "names to hide". 6.7.1 The dircmp class dircmp (a, b[, ignore[, hide]]) Construct a new directory comparison object, to compare the directories a and b. ignore is a list of names to ignore, and defaults to ['RCS', 'CVS', 'tags']. hide is a list of names to hid, and defaults to [os.curdir, os.pardir]. Follow-Ups: Date: 2001-Jan-17 22:31 By: cpr Comment: (This was mine, sorry--finally created a sourceforge account.) --Chris Ryland ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129205&group_id=5470 From noreply@sourceforge.net Thu Jan 18 10:40:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 02:40:14 -0800 Subject: [Python-bugs-list] [Bug #129193] make clean & make test failures with setup.py Message-ID: Bug #129193, was updated on 2001-Jan-17 16:46 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: montanaro Assigned to : akuchling Summary: make clean & make test failures with setup.py Details: Building with setup.py has a couple problems. First, when executing "make clean", the .o and .so files in build/{lib,temp}* are not deleted. Second, when executing "make test" PYTHONPATH is not set to the build/lib* directory, so the python executable can't import any of them. I would try fixing this myself, but I don't know how to compute the names of the relevant subdirectories of build. I assume that something in distutils computes it. That may lead to a chicken and egg situation. If you want to execute "make clean" before you have a viable python executable you won't be able to run setup.py in any fashion to compute it. Alternatively, you could just clean by "rm -r build/*". If that's the only alternative, I'd suggest canning the architecture-specific directory names in build. Follow-Ups: Date: 2001-Jan-18 02:40 By: montanaro Comment: Here's a possible fix for the make test problem. *** /tmp/Makefile.in.~1.109~ Thu Jan 18 04:38:08 2001 --- /tmp/Makefile.in Thu Jan 18 04:38:08 2001 *************** *** 216,223 **** TESTPYTHON= ./python$(EXE) -tt test: all -rm -f $(srcdir)/Lib/test/*.py[co] ! -PYTHONPATH= $(TESTPYTHON) $(TESTPROG) $(TESTOPTS) ! PYTHONPATH= $(TESTPYTHON) $(TESTPROG) $(TESTOPTS) # Install everything install: altinstall bininstall maninstall --- 216,223 ---- TESTPYTHON= ./python$(EXE) -tt test: all -rm -f $(srcdir)/Lib/test/*.py[co] ! -PYTHONPATH=$(srcdir)/build/lib.`./python$(EXE) -c 'import sys ; from distutils.util import get_platform ; print get_platform()+"-"+sys.version[0:3]'` $(TESTPYTHON) $(TESTPROG) $(TESTOPTS) ! PYTHONPATH=$(srcdir)/build/lib.`./python$(EXE) -c 'import sys ; from distutils.util import get_platform ; print get_platform()+"-"+sys.version[0:3]'` $(TESTPYTHON) $(TESTPROG) $(TESTOPTS) # Install everything install: altinstall bininstall maninstall ------------------------------------------------------- Date: 2001-Jan-17 16:47 By: montanaro Comment: again, it's Andrew's sandbox... ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129193&group_id=5470 From noreply@sourceforge.net Thu Jan 18 10:44:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 02:44:17 -0800 Subject: [Python-bugs-list] [Bug #129205] simple typo Message-ID: Bug #129205, was updated on 2001-Jan-17 22:05 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: nobody Assigned to : nobody Summary: simple typo Details: In the text below, "names to hid" should be "names to hide". 6.7.1 The dircmp class dircmp (a, b[, ignore[, hide]]) Construct a new directory comparison object, to compare the directories a and b. ignore is a list of names to ignore, and defaults to ['RCS', 'CVS', 'tags']. hide is a list of names to hid, and defaults to [os.curdir, os.pardir]. Follow-Ups: Date: 2001-Jan-18 02:44 By: montanaro Comment: checked in the change - thanks. ------------------------------------------------------- Date: 2001-Jan-17 22:31 By: cpr Comment: (This was mine, sorry--finally created a sourceforge account.) --Chris Ryland ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129205&group_id=5470 From noreply@sourceforge.net Thu Jan 18 13:20:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 05:20:43 -0800 Subject: [Python-bugs-list] [Bug #129234] Various typo in the API ref manual Message-ID: Bug #129234, was updated on 2001-Jan-18 05:20 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: gcivario Assigned to : nobody Summary: Various typo in the API ref manual Details: Those typo are present on the version 1.103 of the release 2.0 of the manual. * Page 14 in function PyErr_Format: \var{fmt} used insted of \var{format} * Page 15 in function PyErr_Warn: found NULL instead of \NULL{} * Page 17 in function Py_FdIsInteractive: \var{name} found instead of \var{filename} * Page 22 in function PyObject_CallObject and PyObject_CallFunction: replace o with callable_object * Page 22 in function PyObject_CallMethode: in the equivalent Python statement, change method with m * Page 24 in function PyNumber_And: remplace \& with \&\ * Page 24 in function PyNumber_InPlacePower: add a '\' before 'var{o3} * Page 24 in function PyNumber_AndInPlace: there is \var{o2} 2 times * Page 26 in function PySequence_DelItem: replace \var{v} with \var{o} * Page 29 in the 3° line: replace the '.' after 'exemple' with a ',' Regards Gilles Civario For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129234&group_id=5470 From noreply@sourceforge.net Thu Jan 18 15:16:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 07:16:23 -0800 Subject: [Python-bugs-list] [Bug #129193] make clean & make test failures with setup.py Message-ID: Bug #129193, was updated on 2001-Jan-17 16:46 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: montanaro Assigned to : akuchling Summary: make clean & make test failures with setup.py Details: Building with setup.py has a couple problems. First, when executing "make clean", the .o and .so files in build/{lib,temp}* are not deleted. Second, when executing "make test" PYTHONPATH is not set to the build/lib* directory, so the python executable can't import any of them. I would try fixing this myself, but I don't know how to compute the names of the relevant subdirectories of build. I assume that something in distutils computes it. That may lead to a chicken and egg situation. If you want to execute "make clean" before you have a viable python executable you won't be able to run setup.py in any fashion to compute it. Alternatively, you could just clean by "rm -r build/*". If that's the only alternative, I'd suggest canning the architecture-specific directory names in build. Follow-Ups: Date: 2001-Jan-18 07:16 By: akuchling Comment: The big ugly python -c invocation is annoying, but I see no way around it, since the Distutils does some work to compute the platform string; it's not just $(MACHDEP). A sneaky trick might be to just expand build/lib.* and use that. ------------------------------------------------------- Date: 2001-Jan-18 02:40 By: montanaro Comment: Here's a possible fix for the make test problem. *** /tmp/Makefile.in.~1.109~ Thu Jan 18 04:38:08 2001 --- /tmp/Makefile.in Thu Jan 18 04:38:08 2001 *************** *** 216,223 **** TESTPYTHON= ./python$(EXE) -tt test: all -rm -f $(srcdir)/Lib/test/*.py[co] ! -PYTHONPATH= $(TESTPYTHON) $(TESTPROG) $(TESTOPTS) ! PYTHONPATH= $(TESTPYTHON) $(TESTPROG) $(TESTOPTS) # Install everything install: altinstall bininstall maninstall --- 216,223 ---- TESTPYTHON= ./python$(EXE) -tt test: all -rm -f $(srcdir)/Lib/test/*.py[co] ! -PYTHONPATH=$(srcdir)/build/lib.`./python$(EXE) -c 'import sys ; from distutils.util import get_platform ; print get_platform()+"-"+sys.version[0:3]'` $(TESTPYTHON) $(TESTPROG) $(TESTOPTS) ! PYTHONPATH=$(srcdir)/build/lib.`./python$(EXE) -c 'import sys ; from distutils.util import get_platform ; print get_platform()+"-"+sys.version[0:3]'` $(TESTPYTHON) $(TESTPROG) $(TESTOPTS) # Install everything install: altinstall bininstall maninstall ------------------------------------------------------- Date: 2001-Jan-17 16:47 By: montanaro Comment: again, it's Andrew's sandbox... ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129193&group_id=5470 From noreply@sourceforge.net Thu Jan 18 16:03:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 08:03:46 -0800 Subject: [Python-bugs-list] [Bug #129193] make clean & make test failures with setup.py Message-ID: Bug #129193, was updated on 2001-Jan-17 16:46 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: montanaro Assigned to : akuchling Summary: make clean & make test failures with setup.py Details: Building with setup.py has a couple problems. First, when executing "make clean", the .o and .so files in build/{lib,temp}* are not deleted. Second, when executing "make test" PYTHONPATH is not set to the build/lib* directory, so the python executable can't import any of them. I would try fixing this myself, but I don't know how to compute the names of the relevant subdirectories of build. I assume that something in distutils computes it. That may lead to a chicken and egg situation. If you want to execute "make clean" before you have a viable python executable you won't be able to run setup.py in any fashion to compute it. Alternatively, you could just clean by "rm -r build/*". If that's the only alternative, I'd suggest canning the architecture-specific directory names in build. Follow-Ups: Date: 2001-Jan-18 08:03 By: akuchling Comment: Patch #103313 has been submitted to fix "make test". ------------------------------------------------------- Date: 2001-Jan-18 07:16 By: akuchling Comment: The big ugly python -c invocation is annoying, but I see no way around it, since the Distutils does some work to compute the platform string; it's not just $(MACHDEP). A sneaky trick might be to just expand build/lib.* and use that. ------------------------------------------------------- Date: 2001-Jan-18 02:40 By: montanaro Comment: Here's a possible fix for the make test problem. *** /tmp/Makefile.in.~1.109~ Thu Jan 18 04:38:08 2001 --- /tmp/Makefile.in Thu Jan 18 04:38:08 2001 *************** *** 216,223 **** TESTPYTHON= ./python$(EXE) -tt test: all -rm -f $(srcdir)/Lib/test/*.py[co] ! -PYTHONPATH= $(TESTPYTHON) $(TESTPROG) $(TESTOPTS) ! PYTHONPATH= $(TESTPYTHON) $(TESTPROG) $(TESTOPTS) # Install everything install: altinstall bininstall maninstall --- 216,223 ---- TESTPYTHON= ./python$(EXE) -tt test: all -rm -f $(srcdir)/Lib/test/*.py[co] ! -PYTHONPATH=$(srcdir)/build/lib.`./python$(EXE) -c 'import sys ; from distutils.util import get_platform ; print get_platform()+"-"+sys.version[0:3]'` $(TESTPYTHON) $(TESTPROG) $(TESTOPTS) ! PYTHONPATH=$(srcdir)/build/lib.`./python$(EXE) -c 'import sys ; from distutils.util import get_platform ; print get_platform()+"-"+sys.version[0:3]'` $(TESTPYTHON) $(TESTPROG) $(TESTOPTS) # Install everything install: altinstall bininstall maninstall ------------------------------------------------------- Date: 2001-Jan-17 16:47 By: montanaro Comment: again, it's Andrew's sandbox... ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129193&group_id=5470 From noreply@sourceforge.net Thu Jan 18 19:26:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 11:26:06 -0800 Subject: [Python-bugs-list] [Bug #129288] urllib.quote et al do lowercase %xx Message-ID: Bug #129288, was updated on 2001-Jan-18 11:26 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : nobody Summary: urllib.quote et al do lowercase %xx Details: The python 2.0 urllib has %%%x as a format when quoting forbidden characters. There are scripts out there that break with lower case, therefore I guess %%%X should be used. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129288&group_id=5470 From noreply@sourceforge.net Thu Jan 18 20:41:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 12:41:15 -0800 Subject: [Python-bugs-list] [Bug #129293] zlib library used for binary win32 distribution can crash Message-ID: Bug #129293, was updated on 2001-Jan-18 12:41 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: greg Assigned to : nobody Summary: zlib library used for binary win32 distribution can crash Details: The zlib .lib or .dll that is used for the binary distribution of python 2.0 (both from python.org and in activestate's "build 202" of python 2.0) contains a bug that only seems to show up on some people's win98 systems. When it does, it appears to be nasty and cause windows crashes (overwriting other memory, etc..?). I was able to fix it by building my own copy of the zlib library from sources and linking the zlib module against that. Using the win32 binary distribution of the zlib lib/dlls that is easily findable via a web search seems to cause the problem (I suspect that is the package used in the distribution build?). I can provide both broken and working zlib.pyd files as well as source archives I found and used to build zlib if desired. I used MSVC++ 6.0 sp4 to build. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129293&group_id=5470 From noreply@sourceforge.net Thu Jan 18 18:53:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 10:53:44 -0800 Subject: [Python-bugs-list] [Bug #129280] Weird build directory on BSDI Message-ID: Bug #129280, was updated on 2001-Jan-18 10:53 Here is a current snapshot of the bug. Project: Python Category: Distutils Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: akuchling Assigned to : nobody Summary: Weird build directory on BSDI Details: Reported on python-dev by Thomas Wouters: I also noticed something funny: BSDI calls itself 'BSD/OS ', so distutils actually makes a directory called 'lib.bsd' and 'temp.bsd', with inside those a directory 'os--i386-2.1'. Is that a distutils bug, a setup.py bug, or intentional behaviour of one of the two ? [I think this is a Distutils buglet; util.get_platform() should remove weird characters from the output of uname. --amk] For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129280&group_id=5470 From noreply@sourceforge.net Thu Jan 18 18:53:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 10:53:57 -0800 Subject: [Python-bugs-list] [Bug #129280] Weird build directory on BSDI Message-ID: Bug #129280, was updated on 2001-Jan-18 10:53 Here is a current snapshot of the bug. Project: Python Category: Distutils Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: akuchling Assigned to : gward Summary: Weird build directory on BSDI Details: Reported on python-dev by Thomas Wouters: I also noticed something funny: BSDI calls itself 'BSD/OS ', so distutils actually makes a directory called 'lib.bsd' and 'temp.bsd', with inside those a directory 'os--i386-2.1'. Is that a distutils bug, a setup.py bug, or intentional behaviour of one of the two ? [I think this is a Distutils buglet; util.get_platform() should remove weird characters from the output of uname. --amk] For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129280&group_id=5470 From noreply@sourceforge.net Thu Jan 18 21:34:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 13:34:42 -0800 Subject: [Python-bugs-list] [Bug #129193] make clean & make test failures with setup.py Message-ID: Bug #129193, was updated on 2001-Jan-17 16:46 Here is a current snapshot of the bug. Project: Python Category: Build Status: Closed Resolution: Fixed Bug Group: Platform-specific Priority: 5 Submitted by: montanaro Assigned to : akuchling Summary: make clean & make test failures with setup.py Details: Building with setup.py has a couple problems. First, when executing "make clean", the .o and .so files in build/{lib,temp}* are not deleted. Second, when executing "make test" PYTHONPATH is not set to the build/lib* directory, so the python executable can't import any of them. I would try fixing this myself, but I don't know how to compute the names of the relevant subdirectories of build. I assume that something in distutils computes it. That may lead to a chicken and egg situation. If you want to execute "make clean" before you have a viable python executable you won't be able to run setup.py in any fashion to compute it. Alternatively, you could just clean by "rm -r build/*". If that's the only alternative, I'd suggest canning the architecture-specific directory names in build. Follow-Ups: Date: 2001-Jan-18 13:34 By: akuchling Comment: Patch #103313 was checked in, which should fix the "make test" failure; "make clean" was fixed by an earlier checkin (no patch #). Marking fixed. ------------------------------------------------------- Date: 2001-Jan-18 08:03 By: akuchling Comment: Patch #103313 has been submitted to fix "make test". ------------------------------------------------------- Date: 2001-Jan-18 07:16 By: akuchling Comment: The big ugly python -c invocation is annoying, but I see no way around it, since the Distutils does some work to compute the platform string; it's not just $(MACHDEP). A sneaky trick might be to just expand build/lib.* and use that. ------------------------------------------------------- Date: 2001-Jan-18 02:40 By: montanaro Comment: Here's a possible fix for the make test problem. *** /tmp/Makefile.in.~1.109~ Thu Jan 18 04:38:08 2001 --- /tmp/Makefile.in Thu Jan 18 04:38:08 2001 *************** *** 216,223 **** TESTPYTHON= ./python$(EXE) -tt test: all -rm -f $(srcdir)/Lib/test/*.py[co] ! -PYTHONPATH= $(TESTPYTHON) $(TESTPROG) $(TESTOPTS) ! PYTHONPATH= $(TESTPYTHON) $(TESTPROG) $(TESTOPTS) # Install everything install: altinstall bininstall maninstall --- 216,223 ---- TESTPYTHON= ./python$(EXE) -tt test: all -rm -f $(srcdir)/Lib/test/*.py[co] ! -PYTHONPATH=$(srcdir)/build/lib.`./python$(EXE) -c 'import sys ; from distutils.util import get_platform ; print get_platform()+"-"+sys.version[0:3]'` $(TESTPYTHON) $(TESTPROG) $(TESTOPTS) ! PYTHONPATH=$(srcdir)/build/lib.`./python$(EXE) -c 'import sys ; from distutils.util import get_platform ; print get_platform()+"-"+sys.version[0:3]'` $(TESTPYTHON) $(TESTPROG) $(TESTOPTS) # Install everything install: altinstall bininstall maninstall ------------------------------------------------------- Date: 2001-Jan-17 16:47 By: montanaro Comment: again, it's Andrew's sandbox... ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129193&group_id=5470 From noreply@sourceforge.net Thu Jan 18 21:44:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 13:44:05 -0800 Subject: [Python-bugs-list] [Bug #123225] asyncore.py should use select.poll(), not "import poll" Message-ID: Bug #123225, was updated on 2000-Nov-22 20:41 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: Later Bug Group: Not a Bug Priority: 5 Submitted by: nobody Assigned to : jhylton Summary: asyncore.py should use select.poll(), not "import poll" Details: The Python2.0 asyncore module is able to use the poll system call (claimed to be much more efficient than select for large numbers of requests), however, it tries to "import poll", which fails (there is no pollmodule supplied with Python2.0), whereas it could use the poll available with the select module (select.poll()). Follow-Ups: Date: 2001-Jan-18 13:44 By: akuchling Comment: The patch is archived at http://www.egroups.com/message/medusa/262 . Still no word from Sam Rushing on whether he accepted it. ------------------------------------------------------- Date: 2000-Dec-22 06:43 By: akuchling Comment: A patch to use Python 2.0's select.poll() has been sent off to the medusa@egroups.com mailing list. Assuming the patch is accepted, this bug will be fixed when we pick up the latest version of asyncore.py before Python 2.1 is finalized. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=123225&group_id=5470 From noreply@sourceforge.net Fri Jan 19 03:25:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 19:25:39 -0800 Subject: [Python-bugs-list] [Bug #129293] zlib library used for binary win32 distribution can crash Message-ID: Bug #129293, was updated on 2001-Jan-18 12:41 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: greg Assigned to : tim_one Summary: zlib library used for binary win32 distribution can crash Details: The zlib .lib or .dll that is used for the binary distribution of python 2.0 (both from python.org and in activestate's "build 202" of python 2.0) contains a bug that only seems to show up on some people's win98 systems. When it does, it appears to be nasty and cause windows crashes (overwriting other memory, etc..?). I was able to fix it by building my own copy of the zlib library from sources and linking the zlib module against that. Using the win32 binary distribution of the zlib lib/dlls that is easily findable via a web search seems to cause the problem (I suspect that is the package used in the distribution build?). I can provide both broken and working zlib.pyd files as well as source archives I found and used to build zlib if desired. I used MSVC++ 6.0 sp4 to build. Follow-Ups: Date: 2001-Jan-18 19:25 By: gvanrossum Comment: Thanks! Doubt this comes in time for 2.1a1, but we'll gladly accept your services. I'll defer to our Windows cleaner, Tim, to take action on this. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129293&group_id=5470 From noreply@sourceforge.net Fri Jan 19 03:28:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 19:28:42 -0800 Subject: [Python-bugs-list] [Bug #129288] urllib.quote et al do lowercase %xx Message-ID: Bug #129288, was updated on 2001-Jan-18 11:26 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: nobody Assigned to : gvanrossum Summary: urllib.quote et al do lowercase %xx Details: The python 2.0 urllib has %%%x as a format when quoting forbidden characters. There are scripts out there that break with lower case, therefore I guess %%%X should be used. Follow-Ups: Date: 2001-Jan-18 19:28 By: gvanrossum Comment: Agreed. Fixed in CVS, will be released with 2.1a1. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129288&group_id=5470 From noreply@sourceforge.net Fri Jan 19 03:28:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 19:28:56 -0800 Subject: [Python-bugs-list] [Bug #129234] Various typo in the API ref manual Message-ID: Bug #129234, was updated on 2001-Jan-18 05:20 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: gcivario Assigned to : fdrake Summary: Various typo in the API ref manual Details: Those typo are present on the version 1.103 of the release 2.0 of the manual. * Page 14 in function PyErr_Format: \var{fmt} used insted of \var{format} * Page 15 in function PyErr_Warn: found NULL instead of \NULL{} * Page 17 in function Py_FdIsInteractive: \var{name} found instead of \var{filename} * Page 22 in function PyObject_CallObject and PyObject_CallFunction: replace o with callable_object * Page 22 in function PyObject_CallMethode: in the equivalent Python statement, change method with m * Page 24 in function PyNumber_And: remplace \& with \&\ * Page 24 in function PyNumber_InPlacePower: add a '\' before 'var{o3} * Page 24 in function PyNumber_AndInPlace: there is \var{o2} 2 times * Page 26 in function PySequence_DelItem: replace \var{v} with \var{o} * Page 29 in the 3° line: replace the '.' after 'exemple' with a ',' Regards Gilles Civario For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129234&group_id=5470 From noreply@sourceforge.net Fri Jan 19 03:31:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 19:31:44 -0800 Subject: [Python-bugs-list] [Bug #129208] Doc and code mismatch Message-ID: Bug #129208, was updated on 2001-Jan-17 22:29 Here is a current snapshot of the bug. Project: Python Category: IDLE Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: nobody Assigned to : gvanrossum Summary: Doc and code mismatch Details: The help file mentions IdlePrefs.py, but the code includes no such file. Follow-Ups: Date: 2001-Jan-18 19:31 By: gvanrossum Comment: Thanks! That was old information; color prefs can now be edited in config.txt or ~/.idle. I've updated the help.txt file in the CVS tree. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129208&group_id=5470 From noreply@sourceforge.net Fri Jan 19 03:32:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 19:32:30 -0800 Subject: [Python-bugs-list] [Bug #128973] OpenBSD Problems with _funlockfile in fileobject.c Message-ID: Bug #128973, was updated on 2001-Jan-15 21:12 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: jpettit Assigned to : gvanrossum Summary: OpenBSD Problems with _funlockfile in fileobject.c Details: When I compile the current CVS version of Python on OpenBSD 2.8, I get the following linker error: ld: _funlockfile: non-function jmpslot collect2: ld returned 1 exit status *** Error code 1 This function was first added to Python in version 2.97 of "fileobject.c". Follow-Ups: Date: 2001-Jan-18 19:32 By: gvanrossum Comment: Alas, it seems that this will remain open in 2.1a1. Hopefully someone else will be able to fix it once the alpha1 release is out. ------------------------------------------------------- Date: 2001-Jan-16 11:58 By: jpettit Comment: The man page doesn't seem to specify a particular library to link against. It only says to include stdio.h. I'm building Python without any special flags. I thought threads were enabled by default, but just for good measure, I ran configure with --with-threads and got the same results. I don't see any reference to flockfile/funlockfile in config.log. ------------------------------------------------------- Date: 2001-Jan-16 11:00 By: twouters Comment: Unfortunately, I don't have access to OpenBSD, just FreeBSD and BSDI. flockfile/funlockfile both work fine there. I suspect it's a header/library problem: maybe we need to include a separate header/library, which we for some reason do in the configure process, but not in the linking of Python (or maybe it needs additional magic to link together with other libraries, I don't know.) jpettit, can you check the manpage for funlockfile to see what headerfiles should be included, and perhaps what to link with ? Also, are you compiling threaded or unthreaded ? There is a good chance the flockfile/funlockfile functions are only available in threaded code, or maybe Python is being compiled half-threaded for some reason. Checking to see the difference between what config.log and 'make' say might give some hints, too. Or it could just be an OS bug :P We should be able to figure it out though: if Python can't *compile* with those functions, neither should configure. ------------------------------------------------------- Date: 2001-Jan-16 09:56 By: jpettit Comment: I'd be happy to help however I can. However, autoconf is black magic to me. I think that funlockfile is supposed to be available...there is even a man page dated 20 August 1998. This may be another case of OpenBSD improperly integrating components from the other BSDs. Please let me know what I can do. ------------------------------------------------------- Date: 2001-Jan-16 05:28 By: gvanrossum Comment: It's gotta be more complicated that that. The configure script has a test program that calls flockfile(), getc_unlocked(), and funlockfile(). Only if this test program links successfully does it decide to use getc_unlocked(). (Making the test depend on successfully *running* it shouldn't make a difference -- the user here got a link-time error.) jpettit, is there a way you could find out why the configure test succeeds but then you get a link error linking Python? I'll also ask Thomas Wouters to look into this. ------------------------------------------------------- Date: 2001-Jan-15 22:19 By: tim_one Comment: Ho ho ho: so this means some flavor of Unix has getc_unlocked() but not the flockfile() and funlockfile() that are supposed to come with it? Man, Windows looks better every day -- and so does the getline_via_fgets() hack ... ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128973&group_id=5470 From noreply@sourceforge.net Fri Jan 19 03:33:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 19:33:09 -0800 Subject: [Python-bugs-list] [Bug #126706] many std modules assume string.letters is [a-zA-Z] Message-ID: Bug #126706, was updated on 2000-Dec-23 06:19 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : gvanrossum Summary: many std modules assume string.letters is [a-zA-Z] Details: there are many modules in the standard library that use string.letters to mean A-Za-z, but that assumption is incorrect when locales are in use. also the readline library seems to cause the locale to be set according to the current environment variables, even if i don't call locale.*: % python2.0 -c 'import string; print string.letters' abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ % python2.0 Python 2.0 (#3, Oct 19 2000, 01:42:41) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Type "copyright", "credits" or "license" for more information. >>> print string.letters abcdefghijklmnopqrstuvwxyzµßàáâãäåæçèéêëìíîïðñòóôõöøùúûüýþÿABCDEFGHIJKLMNOPQRSTUVWXYZÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖØÙÚÛÜÝÞ >>> here's what grep says on the standard library. most of these uses seem incorrect to me: % grep string.letters **/*.py Cookie.py:_LegalChars = string.letters + string.digits + "!#$%&'*+-.^_`|~"cmd.py:IDENTCHARS = string.letters + string.digits + '_' dospath.py: varchars = string.letters + string.digits + '_-' lib-old/codehack.py:identchars = string.letters + string.digits + '_' # Identifier characters ntpath.py: varchars = string.letters + string.digits + '_-' nturl2path.py: if len(comp) != 2 or comp[0][-1] not in string.letters: pipes.py:_safechars = string.letters + string.digits + '!@%_-+=:,./' # Safe unquoted pre.py: alphanum=string.letters+'_'+string.digits tokenize.py: namechars, numchars = string.letters + '_', string.digits urlparse.py:scheme_chars = string.letters + string.digits + '+-.' Follow-Ups: Date: 2001-Jan-18 19:33 By: gvanrossum Comment: Will look into this again after alpha1 is out -- no time before that. ------------------------------------------------------- Date: 2001-Jan-09 06:46 By: gvanrossum Comment: I agree that the string module should be extended with additional variables ascii_letters (and ascii_lowercase and ascii_uppercase and ascii_whitespace). ------------------------------------------------------- Date: 2001-Jan-01 10:08 By: lemburg Comment: The comment about readline calling setlocale() is unfortunately true (and causes some very subtle bugs in user code...). About the addition of more constants: I would rather like to see a database for these things which uses function calls much like the Unicode database (unicodedata). Since locales sometime matter, I think there should be an option to the functions which enables locale support (much like as for REs) on request. Default should be no locale support, since this is what most code expects anyway. ------------------------------------------------------- Date: 2000-Dec-30 19:36 By: akuchling Comment: The set of all letters, though, will be commonly used, though maybe we need an alphanumeric constant for A-Za-z0-9 + underscore. I like the .ascii_letters suggestion. ------------------------------------------------------- Date: 2000-Dec-30 18:26 By: fdrake Comment: Andrew, does it make sense to introduce new constants in string for this? It seems that each instance is referring to slightly different specifications or standards (documented or not), so perhaps the constants should be defined locally within each of the modules. This also avoids unnecessary dependencies. ------------------------------------------------------- Date: 2000-Dec-26 12:18 By: nobody Comment: string.ascii_letters etc is more precise than alphabet, imho. -- erno@iki.fi ------------------------------------------------------- Date: 2000-Dec-26 08:15 By: akuchling Comment: The docs for the string module say that, for example, string.lowercase is " A string containing all the characters that are considered lowercase letters." This implies that the strings are locale-aware; code that uses string.lowercase to mean only a-z is therefore in error. (.digits is not locale-aware.) Solution: I'd suggest adding new, not locale-aware, constants. string.alphabet, string.lower_alphabet, string.upper_alphabet, maybe? Code should then be changed to use these new constants. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=126706&group_id=5470 From noreply@sourceforge.net Fri Jan 19 03:37:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 19:37:05 -0800 Subject: [Python-bugs-list] [Bug #119486] fcntl.lockf() is broken Message-ID: Bug #119486, was updated on 2000-Oct-26 14:18 Here is a current snapshot of the bug. Project: Python Category: Extension Modules Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: flight Assigned to : gvanrossum Summary: fcntl.lockf() is broken Details: Another observation by James Troup : fcntl.lockf() seems to be severly `broken': it's acting like flock, not like lockf, and the code seems to be a copy/paste of flock. (registered in the Debian Bug Tracking System as bug #74777, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=74777). James includes a first start at filling in a correct lockf function. Looks like it needs some more work, therefore I don't submit it as patch. The patch is against 1.5.2, though there seem to be no changes in 2.0. These are James' words: fcntl.lockf() doesn't work as expected. fcntl.lockf(fd, FCNTL.F_TLOCK); will block.. looking at the source is exteremly confusing. fcntl.lockf() appears to want flock() style arguments?! It almost looks like someone cut'n'wasted from the fcntl_flock() function just above... Anyway, here is a patch which is IMO the Right Thing, i.e. fcnt.lockf() acting like libc lockf() and like it's documented to do... --- python-1.5.2/Modules/fcntlmodule.c.orig Sat Oct 14 15:46:40 2000 +++ python-1.5.2/Modules/fcntlmodule.c Sat Oct 14 18:31:44 2000 @@ -233,30 +233,12 @@ { int fd, code, ret, whence = 0; PyObject *lenobj = NULL, *startobj = NULL; + struct flock l; if (!PyArg_ParseTuple(args, "ii|OOi", &fd, &code, &lenobj, &startobj, &whence)) return NULL; -#ifndef LOCK_SH -#define LOCK_SH 1 /* shared lock */ -#define LOCK_EX 2 /* exclusive lock */ -#define LOCK_NB 4 /* don't block when locking */ -#define LOCK_UN 8 /* unlock */ -#endif - { - struct flock l; - if (code == LOCK_UN) - l.l_type = F_UNLCK; - else if (code & LOCK_SH) - l.l_type = F_RDLCK; - else if (code & LOCK_EX) - l.l_type = F_WRLCK; - else { - PyErr_SetString(PyExc_ValueError, - "unrecognized flock argument"); - return NULL; - } l.l_start = l.l_len = 0; if (startobj != NULL) { #if !defined(HAVE_LARGEFILE_SUPPORT) @@ -281,10 +263,48 @@ return NULL; } l.l_whence = whence; + switch (code) + { + case F_TEST: + /* Test the lock: return 0 if FD is unlocked or locked by this process; + return -1, set errno to EACCES, if another process holds the lock. */ + if (fcntl (fd, F_GETLK, &l) < 0) { + fprintf(stderr, "andrea: 1"); + PyErr_SetFromErrno(PyExc_IOError); + return NULL; + } + if (l.l_type == F_UNLCK || l.l_pid == getpid ()) { + fprintf(stderr, "andrea: 2"); + Py_INCREF(Py_None); + return Py_None; + } + fprintf(stderr, "andrea: 3"); + errno = EACCES; + PyErr_SetFromErrno(PyExc_IOError); + return NULL; + + case F_ULOCK: + l.l_type = F_UNLCK; + code = F_SETLK; + break; + case F_LOCK: + l.l_type = F_WRLCK; + code = F_SETLKW; + break; + case F_TLOCK: + l.l_type = F_WRLCK; + code = F_SETLK; + break; + + default: + PyErr_SetString(PyExc_ValueError, + "unrecognized flock argument"); + return NULL; + } Py_BEGIN_ALLOW_THREADS - ret = fcntl(fd, (code & LOCK_NB) ? F_SETLK : F_SETLKW, &l); + ret = fcntl(fd, code, &l); Py_END_ALLOW_THREADS - } + if (ret < 0) { PyErr_SetFromErrno(PyExc_IOError); return NULL; Follow-Ups: Date: 2001-Jan-18 19:37 By: gvanrossum Comment: I apologize. I should've looked into this earlier. Now I won't have time to look at it before releasing 2.1a1. I promise I'll come back to it later. ------------------------------------------------------- Date: 2000-Dec-19 17:19 By: akuchling Comment: Note that the docs say that lockf "is a wrapper around the \constant{FCNTL.F_SETLK} and \constant{FCNTL.F_SETLKW} \function{fcntl()} calls." Stevens's "Advanced Programming in the Unix Env." concurs, on page 367: "The System V lockf() is just an interface to fcntl()." However, none of us are serious Unix weenies. Unfortunately, the documented Python lockf() provides features above the libc lockf(), so using the system lockf() seems impossible unless we break backwards compatibility. Unfortunately none of us are serious Unix weenies, so writing a lockf() emulation that's completely correct everywhere might be very difficult. Troup's patch attempts to fix the emulation; I haven't looked at it closely. I'd suggest breaking backwards compatibility; if that's out, we should take a close look at the patch. ------------------------------------------------------- Date: 2000-Nov-24 01:32 By: sjoerd Comment: Yeah, I looked at it. In 1996. I don't think I looked at flock since then. Anyway, it compiles on my system (IRIX 6.5.2), and I don't think I will have time in the near future to look any further into this. ------------------------------------------------------- Date: 2000-Oct-26 14:29 By: gvanrossum Comment: Sjoerd, you once looked at this code. Can you comment on this? If you don't have time, please assign back to me. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=119486&group_id=5470 From noreply@sourceforge.net Fri Jan 19 03:38:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 19:38:28 -0800 Subject: [Python-bugs-list] [Bug #119772] Interactive InterPreter+ Thread -> core dump at exit Message-ID: Bug #119772, was updated on 2000-Oct-30 08:28 Here is a current snapshot of the bug. Project: Python Category: Threads Status: Open Resolution: None Bug Group: None Priority: 4 Submitted by: imbunche Assigned to : gvanrossum Summary: Interactive InterPreter+ Thread -> core dump at exit Details: The following code executes a thread that prints a message every second while the main thread shows a python shell. It will run fine and if one leaves the interpreter with python will exit cleanly. However if one press to kill the interactive interpreter and then exits python or press return a couple of time you get a core dump. My platform is: HP-UX te35 B.11.00 A 9000/785 2015352223 two-user license I am running Python 2.0 This is the code of the test program: #!/usr/local/bin/python import time, threading, whrandom, code, sys class MyThread(threading.Thread): """ reports once per second """ def run(self): while 1: print "alive ...." time.sleep(1) print self.getName(), "is DONE" if __name__ == '__main__': threadList = [] # Create MyThread() threads t = MyThread() t.setDaemon(1) t.start() # This is the main thread ... since there is only one other # thread and it is a 'daemon', killing the main thread kills # the whole thing. locals = sys.modules['__main__'].__dict__ code.interact(locals) Follow-Ups: Date: 2000-Oct-30 08:47 By: jhylton Comment: I can reproduce this on RH Linux, but not running Python under gdb. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=119772&group_id=5470 From noreply@sourceforge.net Fri Jan 19 03:41:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 19:41:33 -0800 Subject: [Python-bugs-list] [Bug #123225] asyncore.py should use select.poll(), not "import poll" Message-ID: Bug #123225, was updated on 2000-Nov-22 20:41 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: Later Bug Group: Not a Bug Priority: 5 Submitted by: nobody Assigned to : akuchling Summary: asyncore.py should use select.poll(), not "import poll" Details: The Python2.0 asyncore module is able to use the poll system call (claimed to be much more efficient than select for large numbers of requests), however, it tries to "import poll", which fails (there is no pollmodule supplied with Python2.0), whereas it could use the poll available with the select module (select.poll()). Follow-Ups: Date: 2001-Jan-18 19:41 By: gvanrossum Comment: Would it be really bad if we applied this without waiting for Sam? Maybe Sam is busy (after egroups was aquired by Yahoo I think he decided to move to the SF bay area and/or change jobs). Maybe he's not yet on the Python 2.x bandwagon. What's wrong with a (temporary) fork in the code? ------------------------------------------------------- Date: 2001-Jan-18 13:44 By: akuchling Comment: The patch is archived at http://www.egroups.com/message/medusa/262 . Still no word from Sam Rushing on whether he accepted it. ------------------------------------------------------- Date: 2000-Dec-22 06:43 By: akuchling Comment: A patch to use Python 2.0's select.poll() has been sent off to the medusa@egroups.com mailing list. Assuming the patch is accepted, this bug will be fixed when we pick up the latest version of asyncore.py before Python 2.1 is finalized. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=123225&group_id=5470 From noreply@sourceforge.net Fri Jan 19 03:43:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 19:43:40 -0800 Subject: [Python-bugs-list] [Bug #127699] Memory leaks using imp.load_module Message-ID: Bug #127699, was updated on 2001-Jan-05 12:30 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: cgw Assigned to : bwarsaw Summary: Memory leaks using imp.load_module Details: #!/usr/bin/env python import os import sys import imp print os.getpid() sys.path.append("/tmp") count = 0 while (count<1000): modname = "testmod%s" % count count = count + 1 filename = '/tmp/' + modname + '.py' f = open(filename, 'w') for x in range(10000): f.write('x%s=%s\n'%(x,x)) f.close() modinfo = imp.find_module(modname) print 'loading', modname m = apply(imp.load_module, ('testmod',) + modinfo) ## run "watch -n 1 ps up ## where is the pid printed out by this program Follow-Ups: Date: 2001-Jan-18 19:43 By: gvanrossum Comment: Barry...?!?! ------------------------------------------------------- Date: 2001-Jan-07 15:32 By: fdrake Comment: Assigned to Barry since he's the memory leak expert (& has the right tools). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=127699&group_id=5470 From noreply@sourceforge.net Fri Jan 19 03:45:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 19:45:52 -0800 Subject: [Python-bugs-list] [Bug #117608] test_largefile crashes or IRIX 6 Message-ID: Bug #117608, was updated on 2000-Oct-24 08:51 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: Works For Me Bug Group: Platform-specific Priority: 1 Submitted by: bbaxter Assigned to : gvanrossum Summary: test_largefile crashes or IRIX 6 Details: During "make test", test_largefile caused an error. Here's the result in python: % python python2.0/test/test_largefile.py create large file via seek (may be sparse file) ... Traceback (most recent call last): File "python2.0/test/test_largefile.py", line 60, in ? f.flush() IOError: [Errno 22] Invalid argument Here's the version I'm running: Python 2.0 (#5, Oct 24 2000, 09:51:57) [C] on irix6 Follow-Ups: Date: 2001-Jan-18 19:45 By: gvanrossum Comment: Lowering the priority; Sjoerd's theory sounds very plausible! Can the original submittor confirm this? Then we can close the bug report... Barry still can't do anything about this... ------------------------------------------------------- Date: 2000-Dec-13 09:09 By: sjoerd Comment: Assigned back to Barry so that he can deal with this further. I'm on vacation as of tomorrow. My guess is that the problem is a lack of disk space on the user's test machine. When you seek far away and write a byte on an SGI file system (EFS or XFS) the system actually allocates the blocks. There is no such thing as holes in files on the SGI file systems. I happen to have enough disk space available, so the test runs fine. I assume the submitter of the bug didn't have enough disk space available and so the flush couldn't complete. ------------------------------------------------------- Date: 2000-Dec-12 13:56 By: bwarsaw Comment: Reassigning because I have neither large file support nor an IRIX machine. Guido suggests that Sjoerd might have access to IRIX. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=117608&group_id=5470 From noreply@sourceforge.net Fri Jan 19 03:47:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 19:47:05 -0800 Subject: [Python-bugs-list] [Bug #121706] exceptions module cannot be imported in two interpreters Message-ID: Bug #121706, was updated on 2000-Nov-05 15:40 Here is a current snapshot of the bug. Project: Python Category: Extension Modules Status: Open Resolution: None Bug Group: None Priority: 6 Submitted by: mhagger Assigned to : bwarsaw Summary: exceptions module cannot be imported in two interpreters Details: If the exceptions module is imported in two separate interpreters within one process, the second import fails. The program below fails when linked with Python 2.0 on RedHat Linux 6.2 with the following message: Traceback (most recent call last): File "", line 1, in ? ImportError: Cannot re-init internal module exceptions Program source: #include char *cmd = "import exceptions"; int main() { Py_Initialize(); PyEval_InitThreads(); PyRun_SimpleString(cmd); Py_EndInterpreter(PyThreadState_Get()); Py_NewInterpreter(); PyRun_SimpleString(cmd); Py_Finalize(); } If the command is changed to "import sys" or "import os" there is no error message. Follow-Ups: Date: 2001-Jan-18 19:47 By: gvanrossum Comment: Barry, please look into this! ------------------------------------------------------- Date: 2000-Nov-13 12:14 By: gvanrossum Comment: Verified. For Barry to investigate! ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=121706&group_id=5470 From noreply@sourceforge.net Fri Jan 19 03:48:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 19:48:59 -0800 Subject: [Python-bugs-list] [Bug #116678] minidom doesn't raise exception for illegal children Message-ID: Bug #116678, was updated on 2000-Oct-11 19:30 Here is a current snapshot of the bug. Project: Python Category: XML Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: akuchling Assigned to : akuchling Summary: minidom doesn't raise exception for illegal children Details: Some types of DOM node such as Text can't have children. minidom doesn't check for this at all: from xml.dom import minidom doc = minidom.Document() text = doc.createTextNode('lorem ipsum') elem = doc.createElement('leaf') text.appendChild( elem ) print text.toxml() This outputs just 'lorem ipsum', but elem really is a child of text; Text.toxml() just isn't recursing because it doesn't expect to do so. Follow-Ups: Date: 2001-Jan-18 19:48 By: gvanrossum Comment: Nudge, nudge? Andrew? Anybody home? :) ------------------------------------------------------- Date: 2001-Jan-04 07:54 By: fdrake Comment: Andrew, didn't you mostly fix this? If you're done, please close the bug report. (One thing to check: it doesn't look like NamedNodeMap.setNamedItem() and .setNamedItemNS() check that the inserted node is an ATTRIBUTE_NODE; if not, HierarchyRequestErr should be raised.) Thanks for working on this! ------------------------------------------------------- Date: 2000-Dec-12 13:08 By: gvanrossum Comment: Reassigning to Fred so he can pressure Paul into doing something about this. ------------------------------------------------------- Date: 2000-Nov-23 08:07 By: akuchling Comment: Patch #102485 has been submitted to fix this. ------------------------------------------------------- Date: 2000-Nov-21 14:33 By: fdrake Comment: Oops, should re-categorize this as "XML" while I'm at it. ------------------------------------------------------- Date: 2000-Nov-21 14:33 By: fdrake Comment: >From the documentation, I'd expect the Pythonic "moral equivalents" to be raised, which would be a ValueError in the case of illegal node types. I'll even go so far as to say that ValueError should be raised when a second documentElement is appended, instead of a TypeError, to be more consistent with usage else where in the standard library: Pythonic style is to raise a ValueError when the type of a value is right (in this case, a DOM Node), but the specific value is not acceptable, either because it is illegal or because it cannot be accepted given existing state (like already having a documentElement). ------------------------------------------------------- Date: 2000-Oct-15 07:06 By: loewis Comment: I believe this is not a bug, but an intended deviation from the DOM spec. minidom (as the proposed documentation in patch 101821 explains) does not support the IDL exceptions of module DOM, so it cannot report errors about improper usage. ------------------------------------------------------- Date: 2000-Oct-12 20:02 By: fdrake Comment: This is a bug with detecting an improper use. It should be fixed, but need not be for Python 2.0. Correct use will not produce erroneous behavior. Reducing priority by one. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=116678&group_id=5470 From noreply@sourceforge.net Fri Jan 19 03:55:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 19:55:38 -0800 Subject: [Python-bugs-list] [Bug #129344] Section 7.1, Sentence makes no sense Message-ID: Bug #129344, was updated on 2001-Jan-18 19:55 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: andrewwhite Assigned to : nobody Summary: Section 7.1, Sentence makes no sense Details: From: http://www.python.org/doc/2.0/tut/node9.html Section 7.1 This sentence doesn't make sense to me. "The % operator interprets the left argument as a C much like a sprintf()-style format string to be applied to the right argument, and returns the string resulting from this formatting operation." As a C which is like a sprintf format string? Or is it supposed to be "a format string (much like C's sprintf) ..."? For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129344&group_id=5470 From noreply@sourceforge.net Fri Jan 19 03:58:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 19:58:03 -0800 Subject: [Python-bugs-list] [Bug #129345] Section 4.6, Minor grammatical error Message-ID: Bug #129345, was updated on 2001-Jan-18 19:58 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: andrewwhite Assigned to : nobody Summary: Section 4.6, Minor grammatical error Details: http://www.python.org/doc/2.0/tut/node6.html Tutorial, Section 4.6 ORIGINAL The return statement returns with a value from a function. return without an expression argument is used to return from the middle of a procedure (falling off the end also returns from a procedure), in which case the None value is returned. END which I don't think means what it says (which is that return from the middle of a proc returns None). Is suspect this would read better as: CHANGED ... from the middle of a procedure. Falling off the end also returns from a procedure, in which case the None value is returned. END For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129345&group_id=5470 From noreply@sourceforge.net Fri Jan 19 08:11:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 00:11:31 -0800 Subject: [Python-bugs-list] [Bug #125891] windows popen4 crashes python when not closed correctly Message-ID: Bug #125891, was updated on 2000-Dec-15 05:53 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: aisaksen Assigned to : mhammond Summary: windows popen4 crashes python when not closed correctly Details: If you don't close both the istream file and ostream file return values after calling popen4, then it crashes in somewhere in MSVCRT.DLL Try the code included in this file. If you call Crash(), then python will crash after about 500 times through the loop. NoCrash() works ok, because you close both of the results. This bug happens on both the www.python.org release, as well as the ActivePython build. I'm running Windows 2000, with Visual Studio 6.0 installed. This seems to be a Windows bug. It dies in a call to setvbuf. Recompiling with the HAS_SETVBUF undefined still causes the same crash. It would be nice if python prevented this from happening. Ideally, you should be able to close the pipes, because there is no longer a reference to them. -Aaron Isaksen -- begin code -- import os def Crash(): n = 0 while 1: p = os.popen4('dir') p[0].close() n +=1 print n def NoCrash(): n = 0 while 1: p = os.popen4('dir') p[0].close() p[1].close() n +=1 print n -- end code -- Follow-Ups: Date: 2001-Jan-19 00:11 By: tim_one Comment: Mark, got a clue? This is too painful for me: the NoCrash() case on my Win98SE box takes a full second for each popen4 call, while the Crash() case tries to pop up an infinite sequence of conagent.exe error boxes after just a few dozen (but much quicker ) calls; at that point the system gets too low on low-level resource to even open the Ctrl+Alt+Del box, and a reboot is the only way out. aisaksen, hate to say it, but I don't believe the popen family of functions will ever be robust under Windows; popen isn't a native Windows concept (it came from Unix), and MS's base support for it is simply hosed. Note that while Python may grow code to automagically close stuff when the object goes away, Python makes no guarantees about when (or even if) object destructors are called. So you should never rely on Python closing things for you. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=125891&group_id=5470 From noreply@sourceforge.net Fri Jan 19 08:17:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 00:17:32 -0800 Subject: [Python-bugs-list] [Bug #129293] zlib library used for binary win32 distribution can crash Message-ID: Bug #129293, was updated on 2001-Jan-18 12:41 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: greg Assigned to : mhammond Summary: zlib library used for binary win32 distribution can crash Details: The zlib .lib or .dll that is used for the binary distribution of python 2.0 (both from python.org and in activestate's "build 202" of python 2.0) contains a bug that only seems to show up on some people's win98 systems. When it does, it appears to be nasty and cause windows crashes (overwriting other memory, etc..?). I was able to fix it by building my own copy of the zlib library from sources and linking the zlib module against that. Using the win32 binary distribution of the zlib lib/dlls that is easily findable via a web search seems to cause the problem (I suspect that is the package used in the distribution build?). I can provide both broken and working zlib.pyd files as well as source archives I found and used to build zlib if desired. I used MSVC++ 6.0 sp4 to build. Follow-Ups: Date: 2001-Jan-19 00:17 By: greg Comment: Sorry, I don't have a good test case. I only know that the problem exhibits itself in a semi-identifiable manner by sometimes causing win98 on other people's boxes (in the behavior of all annoying bugs: not on any of my machines) to pop up an application error dialog pointing to the zlib dll. Rebuilding zlib from its sources and linking zlib.pyd using that fixed it. For reference: the application we saw this in was mojonation (also a sourceforge project). I'll dig out the exact source package we're using for the zlib library as well as how I built it tomorrow. The prebuilt winimage.com zlib113dll.zip that you mention sounds like the one that I can confirm does not work well. ------------------------------------------------------- Date: 2001-Jan-18 23:39 By: tim_one Comment: Mark, this rings a bell. Not the claim of a bug (first I ever heard of that -- greg, have a short & executable test case?), but that you were keen at one time to change how we did zlib. For 2.0, the DLL came from http://www.winimage.com/zLibDll/zlib133dll.zip and the rest from ftp://ftp.uu.net/graphics/png/src/zlib133.zip If we don't build it ourselves, we've got no handle on possible bugs (IMO). ------------------------------------------------------- Date: 2001-Jan-18 19:25 By: gvanrossum Comment: Thanks! Doubt this comes in time for 2.1a1, but we'll gladly accept your services. I'll defer to our Windows cleaner, Tim, to take action on this. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129293&group_id=5470 From noreply@sourceforge.net Fri Jan 19 07:39:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 18 Jan 2001 23:39:04 -0800 Subject: [Python-bugs-list] [Bug #129293] zlib library used for binary win32 distribution can crash Message-ID: Bug #129293, was updated on 2001-Jan-18 12:41 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: greg Assigned to : mhammond Summary: zlib library used for binary win32 distribution can crash Details: The zlib .lib or .dll that is used for the binary distribution of python 2.0 (both from python.org and in activestate's "build 202" of python 2.0) contains a bug that only seems to show up on some people's win98 systems. When it does, it appears to be nasty and cause windows crashes (overwriting other memory, etc..?). I was able to fix it by building my own copy of the zlib library from sources and linking the zlib module against that. Using the win32 binary distribution of the zlib lib/dlls that is easily findable via a web search seems to cause the problem (I suspect that is the package used in the distribution build?). I can provide both broken and working zlib.pyd files as well as source archives I found and used to build zlib if desired. I used MSVC++ 6.0 sp4 to build. Follow-Ups: Date: 2001-Jan-18 23:39 By: tim_one Comment: Mark, this rings a bell. Not the claim of a bug (first I ever heard of that -- greg, have a short & executable test case?), but that you were keen at one time to change how we did zlib. For 2.0, the DLL came from http://www.winimage.com/zLibDll/zlib133dll.zip and the rest from ftp://ftp.uu.net/graphics/png/src/zlib133.zip If we don't build it ourselves, we've got no handle on possible bugs (IMO). ------------------------------------------------------- Date: 2001-Jan-18 19:25 By: gvanrossum Comment: Thanks! Doubt this comes in time for 2.1a1, but we'll gladly accept your services. I'll defer to our Windows cleaner, Tim, to take action on this. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129293&group_id=5470 From noreply@sourceforge.net Fri Jan 19 09:58:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 01:58:01 -0800 Subject: [Python-bugs-list] [Bug #128475] mimetools.encode (sometimes) fails when called from a thread Message-ID: Bug #128475, was updated on 2001-Jan-11 11:05 Here is a current snapshot of the bug. Project: Python Category: Threads Status: Open Resolution: None Bug Group: None Priority: 7 Submitted by: nobody Assigned to : gvanrossum Summary: mimetools.encode (sometimes) fails when called from a thread Details: I used this script to test. The code of filesender.prepare_msgs is at the end of the report. ## import threading import filesender file = open('c:/windows/desktop/mp3/Aphex Twin - Bucephalus Bouncing Ball.mp3', 'rb') t1 = threading.Thread(target=filesender.prepare_msgs, args=(file,'a@b.c')) from cStringIO import StringIO data = StringIO() import mimetools t2=threading.Thread(target=mimetools.encode, args=(file,data,'base64')) import sys if '-t1' in sys.argv: t1.start() elif '-t2' in sys.argv: t2.start() else: filesender.prepare_msgs(file, 'a@b.c') ## Results of running it with -t1, -t2, and no options, on Windows: C:\Python20>python test.py -t1 preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 Fatal Python error: Interpreter not initialized (version mismatch?) abnormal program termination C:\Python20>python test.py -t1 preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 Fatal Python error: Interpreter not initialized (version mismatch?) abnormal program termination C:\Python20>python test.py -t2 Fatal Python error: Interpreter not initialized (version mismatch?) abnormal program termination C:\Python20>python test.py -t2 C:\Python20>python test.py preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 encoded got value data length is 7807732 Encoded Aphex Twin - Bucephalus Bouncing Ball.mp3 is too large, splitting into 2 parts C:\Python20>python test.py preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 encoded got value data length is 7807732 Encoded Aphex Twin - Bucephalus Bouncing Ball.mp3 is too large, splitting into 2 parts On Linux: wolfson@senator:~% python test.py preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 encoded got value data length is 7807732 Encoded Aphex Twin - Bucephalus Bouncing Ball.mp3 is too large, splitting into 2 p arts wolfson@senator:~% python test.py -t1 preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 Fatal Python error: Interpreter not initialized (version mismatch?) Abort wolfson@senator:~% python test.py -t1 preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 Fatal Python error: Interpreter not initialized (version mismatch?) Abort wolfson@senator:~% python test.py -t2 Fatal Python error: Interpreter not initialized (version mismatch?) Abort wolfson@senator:~% python test.py -t2 Fatal Python error: Interpreter not initialized (version mismatch?) Abort wolfson@senator:~% python test.py -t2 Fatal Python error: Interpreter not initialized (version mismatch?) Abort On Sun 5 it seems to always succeed. The code for filesender.prepare_msgs: def prepare_msgs(file, addressee): data = StringIO.StringIO() fn = getname(file) print 'preparing %s' % fn mimetools.encode(file, data, 'base64') print 'encoded' data = data.getvalue() print 'got value' datalen = len(data) print 'data length is %d' % datalen if datalen > MAX_MSG_SZ: numsplits = 1 + datalen / MAX_MSG_SZ print 'Encoded %s is too large, splitting into %d parts' % (fn,numsplits) msgs = [] for i in range(numsplits): thismsg, data = data[:MAX_MSG_SZ], data[MAX_MSG_SZ:] msgs.append(fmt_message(fn, addressee, thismsg, '(%d/%d)' % (i+1, numsplits), MSG)) return msgs return [fmt_message(fn, addressee, data, '', MSG)] Follow-Ups: Date: 2001-Jan-19 01:58 By: tim_one Comment: Guido, I took this out of the Platform-specific group because his/her test output shows the same failures on both Windows and Linux. I assume it works on Sun5 for him because you have to kick a Sun OS in the groin to make it switch threads. [Later: Also assigned to you so that you can try the tiny program below on Linux] [Later: boosted the priority too] Anonymous submitter, sorry, but this bug report is too confusing to make head or tail of. Could you please whittle this down to a self-contained, failing program that can be executed? As is, you're showing us both code that works (which isn't interesting) and code that doesn't (which is), and none of it can be executed anyway (e.g., MAX_MSG_SZ isn't defined, getname isn't defined, fmt_message isn't defined, ...). Later: like this: BIGFILE = "pcbuild.opt" # OK, it's not really big import threading, mimetools from cStringIO import StringIO file1 = open(BIGFILE, 'rb') data1 = StringIO() t1 = threading.Thread(target=mimetools.encode, args=(file1, data1, 'base64')) t1.start() Guido, that fails for me about 1 time in 5 under Win98SE, current CVS Python, like so: C:\Code\python\dist\src\PCbuild>python tran.py Fatal Python error: Interpreter not initialized (version mismatch?) abnormal program termination C:\Code\python\dist\src\PCbuild> In the debug build it craps out (with about the same frequency) in kernel32.dll (the secret bowels of Windows, which usually means running under the debugger is futile; but I'll try that anyway when I get up again). ------------------------------------------------------- Date: 2001-Jan-15 11:54 By: gvanrossum Comment: I'm assigning this to Tim, our all-purpose Windows cleaner. :-) Thread problems like this are notoriously hard to find, so don't hold your breath. Sorry! Setting the group to platform-specific since you mention it works fine on Sun5. ------------------------------------------------------- Date: 2001-Jan-13 08:13 By: nobody Comment: I'll get you! ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128475&group_id=5470 From noreply@sourceforge.net Fri Jan 19 14:33:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 06:33:55 -0800 Subject: [Python-bugs-list] [Bug #129379] LINKFORSHARED usage incorrently documented Message-ID: Bug #129379, was updated on 2001-Jan-19 06:33 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : nobody Summary: LINKFORSHARED usage incorrently documented Details: http://www.python.org/doc/2.0/ext/link-reqs.html says to get link-flags like this: >>> import distutils.sysconfig >>> distutils.sysconfig.LINKFORSHARED '-Xlinker -export-dynamic' But this does not work. The following line worked, although I'm not sure if it is Correct. >>> distutils.sysconfig.get_config_vars()['LINKFORSHARED'] /Jesper (jojo@virtutech.se) For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129379&group_id=5470 From noreply@sourceforge.net Fri Jan 19 15:19:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 07:19:52 -0800 Subject: [Python-bugs-list] [Bug #121930] Parameter mismatch exception tracebacks could be more helpfu Message-ID: Bug #121930, was updated on 2000-Nov-07 18:14 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Closed Resolution: None Bug Group: None Priority: 5 Submitted by: prescod Assigned to : jhylton Summary: Parameter mismatch exception tracebacks could be more helpfu Details: Here's an example of the problem: def foo(a,b,c,d,e,f,g,h,i,j): pass a=foo #10,00 lines of code #10,00 lines of code ... j=a # 10,000 lines of code def bar(): j() bar() Traceback (most recent call last): File "", line 1, in ? File "", line 1, in bar TypeError: not enough arguments; expected 10, got 0 Notice that there is *no indication* of the real source-location of the thing that I attempted to call (foo). As soon as there is a layer or two of indirection between function pointers and the code that calls them, it can get really confusing to try and figure out what code is being called. When the callee is Python it would be nice if there were some indication in the error message or traceback of the thing's real name and real source location. Guido says: > This could be fixed with special purpose code for this exception > (probably by setting up a dummy frame and using that). Follow-Ups: Date: 2001-Jan-19 07:19 By: jhylton Comment: This was already fixed, probably by Ping. ------------------------------------------------------- Date: 2000-Dec-18 22:39 By: gvanrossum Comment: Jeremy, I was wondering if you could have a look at this -- you may be able to make some changes in the function calling code since you are working on that anyway... ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=121930&group_id=5470 From noreply@sourceforge.net Fri Jan 19 15:45:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 07:45:24 -0800 Subject: [Python-bugs-list] [Bug #129344] Section 7.1, Sentence makes no sense Message-ID: Bug #129344, was updated on 2001-Jan-18 19:55 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: andrewwhite Assigned to : fdrake Summary: Section 7.1, Sentence makes no sense Details: From: http://www.python.org/doc/2.0/tut/node9.html Section 7.1 This sentence doesn't make sense to me. "The % operator interprets the left argument as a C much like a sprintf()-style format string to be applied to the right argument, and returns the string resulting from this formatting operation." As a C which is like a sprintf format string? Or is it supposed to be "a format string (much like C's sprintf) ..."? For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129344&group_id=5470 From noreply@sourceforge.net Fri Jan 19 15:45:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 07:45:48 -0800 Subject: [Python-bugs-list] [Bug #129345] Section 4.6, Minor grammatical error Message-ID: Bug #129345, was updated on 2001-Jan-18 19:58 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: andrewwhite Assigned to : fdrake Summary: Section 4.6, Minor grammatical error Details: http://www.python.org/doc/2.0/tut/node6.html Tutorial, Section 4.6 ORIGINAL The return statement returns with a value from a function. return without an expression argument is used to return from the middle of a procedure (falling off the end also returns from a procedure), in which case the None value is returned. END which I don't think means what it says (which is that return from the middle of a proc returns None). Is suspect this would read better as: CHANGED ... from the middle of a procedure. Falling off the end also returns from a procedure, in which case the None value is returned. END For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129345&group_id=5470 From noreply@sourceforge.net Fri Jan 19 16:13:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 08:13:46 -0800 Subject: [Python-bugs-list] [Bug #123225] asyncore.py should use select.poll(), not "import poll" Message-ID: Bug #123225, was updated on 2000-Nov-22 20:41 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: Later Bug Group: Not a Bug Priority: 5 Submitted by: nobody Assigned to : akuchling Summary: asyncore.py should use select.poll(), not "import poll" Details: The Python2.0 asyncore module is able to use the poll system call (claimed to be much more efficient than select for large numbers of requests), however, it tries to "import poll", which fails (there is no pollmodule supplied with Python2.0), whereas it could use the poll available with the select module (select.poll()). Follow-Ups: Date: 2001-Jan-19 08:13 By: akuchling Comment: I haven't really tested the patch (though I can make time for doing so before alpha2), and simply just don't like forking the code. I've pinged the mailing list, but have heard nothing yet. If Sam remains silent, I'll test the patch and then check it in. ------------------------------------------------------- Date: 2001-Jan-18 19:41 By: gvanrossum Comment: Would it be really bad if we applied this without waiting for Sam? Maybe Sam is busy (after egroups was aquired by Yahoo I think he decided to move to the SF bay area and/or change jobs). Maybe he's not yet on the Python 2.x bandwagon. What's wrong with a (temporary) fork in the code? ------------------------------------------------------- Date: 2001-Jan-18 13:44 By: akuchling Comment: The patch is archived at http://www.egroups.com/message/medusa/262 . Still no word from Sam Rushing on whether he accepted it. ------------------------------------------------------- Date: 2000-Dec-22 06:43 By: akuchling Comment: A patch to use Python 2.0's select.poll() has been sent off to the medusa@egroups.com mailing list. Assuming the patch is accepted, this bug will be fixed when we pick up the latest version of asyncore.py before Python 2.1 is finalized. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=123225&group_id=5470 From noreply@sourceforge.net Fri Jan 19 16:17:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 08:17:45 -0800 Subject: [Python-bugs-list] [Bug #116678] minidom doesn't raise exception for illegal children Message-ID: Bug #116678, was updated on 2000-Oct-11 19:30 Here is a current snapshot of the bug. Project: Python Category: XML Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: akuchling Assigned to : akuchling Summary: minidom doesn't raise exception for illegal children Details: Some types of DOM node such as Text can't have children. minidom doesn't check for this at all: from xml.dom import minidom doc = minidom.Document() text = doc.createTextNode('lorem ipsum') elem = doc.createElement('leaf') text.appendChild( elem ) print text.toxml() This outputs just 'lorem ipsum', but elem really is a child of text; Text.toxml() just isn't recursing because it doesn't expect to do so. Follow-Ups: Date: 2001-Jan-19 08:17 By: akuchling Comment: I still have to follow up on Fred's comment; will add it to the stack... ------------------------------------------------------- Date: 2001-Jan-18 19:48 By: gvanrossum Comment: Nudge, nudge? Andrew? Anybody home? :) ------------------------------------------------------- Date: 2001-Jan-04 07:54 By: fdrake Comment: Andrew, didn't you mostly fix this? If you're done, please close the bug report. (One thing to check: it doesn't look like NamedNodeMap.setNamedItem() and .setNamedItemNS() check that the inserted node is an ATTRIBUTE_NODE; if not, HierarchyRequestErr should be raised.) Thanks for working on this! ------------------------------------------------------- Date: 2000-Dec-12 13:08 By: gvanrossum Comment: Reassigning to Fred so he can pressure Paul into doing something about this. ------------------------------------------------------- Date: 2000-Nov-23 08:07 By: akuchling Comment: Patch #102485 has been submitted to fix this. ------------------------------------------------------- Date: 2000-Nov-21 14:33 By: fdrake Comment: Oops, should re-categorize this as "XML" while I'm at it. ------------------------------------------------------- Date: 2000-Nov-21 14:33 By: fdrake Comment: >From the documentation, I'd expect the Pythonic "moral equivalents" to be raised, which would be a ValueError in the case of illegal node types. I'll even go so far as to say that ValueError should be raised when a second documentElement is appended, instead of a TypeError, to be more consistent with usage else where in the standard library: Pythonic style is to raise a ValueError when the type of a value is right (in this case, a DOM Node), but the specific value is not acceptable, either because it is illegal or because it cannot be accepted given existing state (like already having a documentElement). ------------------------------------------------------- Date: 2000-Oct-15 07:06 By: loewis Comment: I believe this is not a bug, but an intended deviation from the DOM spec. minidom (as the proposed documentation in patch 101821 explains) does not support the IDL exceptions of module DOM, so it cannot report errors about improper usage. ------------------------------------------------------- Date: 2000-Oct-12 20:02 By: fdrake Comment: This is a bug with detecting an improper use. It should be fixed, but need not be for Python 2.0. Correct use will not produce erroneous behavior. Reducing priority by one. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=116678&group_id=5470 From noreply@sourceforge.net Fri Jan 19 16:58:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 08:58:27 -0800 Subject: [Python-bugs-list] [Bug #129379] LINKFORSHARED usage incorrently documented Message-ID: Bug #129379, was updated on 2001-Jan-19 06:33 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : fdrake Summary: LINKFORSHARED usage incorrently documented Details: http://www.python.org/doc/2.0/ext/link-reqs.html says to get link-flags like this: >>> import distutils.sysconfig >>> distutils.sysconfig.LINKFORSHARED '-Xlinker -export-dynamic' But this does not work. The following line worked, although I'm not sure if it is Correct. >>> distutils.sysconfig.get_config_vars()['LINKFORSHARED'] /Jesper (jojo@virtutech.se) For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129379&group_id=5470 From noreply@sourceforge.net Fri Jan 19 17:44:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 09:44:02 -0800 Subject: [Python-bugs-list] [Bug #125891] windows popen4 crashes python when not closed correctly Message-ID: Bug #125891, was updated on 2000-Dec-15 05:53 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: aisaksen Assigned to : mhammond Summary: windows popen4 crashes python when not closed correctly Details: If you don't close both the istream file and ostream file return values after calling popen4, then it crashes in somewhere in MSVCRT.DLL Try the code included in this file. If you call Crash(), then python will crash after about 500 times through the loop. NoCrash() works ok, because you close both of the results. This bug happens on both the www.python.org release, as well as the ActivePython build. I'm running Windows 2000, with Visual Studio 6.0 installed. This seems to be a Windows bug. It dies in a call to setvbuf. Recompiling with the HAS_SETVBUF undefined still causes the same crash. It would be nice if python prevented this from happening. Ideally, you should be able to close the pipes, because there is no longer a reference to them. -Aaron Isaksen -- begin code -- import os def Crash(): n = 0 while 1: p = os.popen4('dir') p[0].close() n +=1 print n def NoCrash(): n = 0 while 1: p = os.popen4('dir') p[0].close() p[1].close() n +=1 print n -- end code -- Follow-Ups: Date: 2001-Jan-19 09:44 By: mhammond Comment: I can repro this. It appears Python _never_ closes the file handles (the Win2k task manager shows the handle count for the process growing at a great rate). It happens for all popen calls. Although Python doesnt guarantee closing, the current implementation should not allow this to happen. I will look into this! ------------------------------------------------------- Date: 2001-Jan-19 00:11 By: tim_one Comment: Mark, got a clue? This is too painful for me: the NoCrash() case on my Win98SE box takes a full second for each popen4 call, while the Crash() case tries to pop up an infinite sequence of conagent.exe error boxes after just a few dozen (but much quicker ) calls; at that point the system gets too low on low-level resource to even open the Ctrl+Alt+Del box, and a reboot is the only way out. aisaksen, hate to say it, but I don't believe the popen family of functions will ever be robust under Windows; popen isn't a native Windows concept (it came from Unix), and MS's base support for it is simply hosed. Note that while Python may grow code to automagically close stuff when the object goes away, Python makes no guarantees about when (or even if) object destructors are called. So you should never rely on Python closing things for you. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=125891&group_id=5470 From noreply@sourceforge.net Fri Jan 19 17:48:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 09:48:54 -0800 Subject: [Python-bugs-list] [Bug #129293] zlib library used for binary win32 distribution can crash Message-ID: Bug #129293, was updated on 2001-Jan-18 12:41 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: greg Assigned to : mhammond Summary: zlib library used for binary win32 distribution can crash Details: The zlib .lib or .dll that is used for the binary distribution of python 2.0 (both from python.org and in activestate's "build 202" of python 2.0) contains a bug that only seems to show up on some people's win98 systems. When it does, it appears to be nasty and cause windows crashes (overwriting other memory, etc..?). I was able to fix it by building my own copy of the zlib library from sources and linking the zlib module against that. Using the win32 binary distribution of the zlib lib/dlls that is easily findable via a web search seems to cause the problem (I suspect that is the package used in the distribution build?). I can provide both broken and working zlib.pyd files as well as source archives I found and used to build zlib if desired. I used MSVC++ 6.0 sp4 to build. Follow-Ups: Date: 2001-Jan-19 09:48 By: mhammond Comment: It appears from the description that we could solve this by using the zlib sources, and building our own .dll from these sources. This guarantees the .h and .dll files etc are in synch, and allows us to have a single "zlib" directory. As Tim hinted, this is exactly what I tried to do around a year ago. The biggest problem is that it will "break" Python builds until people update their zlib directories. In particular, Guido commented something like "do what you want but dont break my build" - unfortunately, I can't promise that! I will submit a patch on this, but unfortunately, this wont be for a week or so. ------------------------------------------------------- Date: 2001-Jan-19 00:17 By: greg Comment: Sorry, I don't have a good test case. I only know that the problem exhibits itself in a semi-identifiable manner by sometimes causing win98 on other people's boxes (in the behavior of all annoying bugs: not on any of my machines) to pop up an application error dialog pointing to the zlib dll. Rebuilding zlib from its sources and linking zlib.pyd using that fixed it. For reference: the application we saw this in was mojonation (also a sourceforge project). I'll dig out the exact source package we're using for the zlib library as well as how I built it tomorrow. The prebuilt winimage.com zlib113dll.zip that you mention sounds like the one that I can confirm does not work well. ------------------------------------------------------- Date: 2001-Jan-18 23:39 By: tim_one Comment: Mark, this rings a bell. Not the claim of a bug (first I ever heard of that -- greg, have a short & executable test case?), but that you were keen at one time to change how we did zlib. For 2.0, the DLL came from http://www.winimage.com/zLibDll/zlib133dll.zip and the rest from ftp://ftp.uu.net/graphics/png/src/zlib133.zip If we don't build it ourselves, we've got no handle on possible bugs (IMO). ------------------------------------------------------- Date: 2001-Jan-18 19:25 By: gvanrossum Comment: Thanks! Doubt this comes in time for 2.1a1, but we'll gladly accept your services. I'll defer to our Windows cleaner, Tim, to take action on this. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129293&group_id=5470 From noreply@sourceforge.net Fri Jan 19 20:18:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 12:18:39 -0800 Subject: [Python-bugs-list] [Bug #125598] Confusing KeyError-Message when key is tuple of size 1 Message-ID: Bug #125598, was updated on 2000-Dec-13 02:38 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: murple Assigned to : gvanrossum Summary: Confusing KeyError-Message when key is tuple of size 1 Details: Following caused some confusion for me: >>> dic = {1:1,2:"bla"} >>> dic[1] 1 >>> b = (1,) #1000 lines of code >>> dic[b] Traceback (innermost last): File "", line 1, in ? KeyError: 1 # This should be KeyError: (1,) # because 1 is a valid key for dic >>> dic[(1,2)] Traceback (innermost last): File "", line 1, in ? KeyError: (1, 2) >>> Follow-Ups: Date: 2001-Jan-19 12:18 By: bwarsaw Comment: Assigning back to Guido for final pronouncement, but I think this should be resolved as "Won't Fix" and closed. ------------------------------------------------------- Date: 2000-Dec-13 15:54 By: bwarsaw Comment: I don't remember the exact details, but this is a byproduct of the backwards compatibility rules for Exception.__str__(). Specifically, if an exception is instantiated with a sequence of length 1, then str(exc) will return str(exc.args[0]). Note that exc.args contains the length-1 tuple it was instantiated with. This bites every built-in exception except EnvironmentError and SyntaxError, which define their own __str__(). Changing this may have unintended consequences, and I'm not sure if it's worth fixing. ------------------------------------------------------- Date: 2000-Dec-13 06:09 By: gvanrossum Comment: This seems a problem in exception reporting. I can reproduce it as follows: >>> raise KeyError, (1,) Traceback (most recent call last): File "", line 1, in ? KeyError: 1 >>> Assigned to Barry since he's the master of this code.] ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=125598&group_id=5470 From noreply@sourceforge.net Fri Jan 19 23:01:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 15:01:18 -0800 Subject: [Python-bugs-list] [Bug #129417] Negative numbers are grouped incorrectly Message-ID: Bug #129417, was updated on 2001-Jan-19 13:00 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : loewis Summary: Negative numbers are grouped incorrectly Details: >>> import locale >>> locale.setlocale(locale.LC_ALL,'') 'en' >>> print locale.format("%.2f", -100, 1) -,100.00 Linux 2.4.0 on Mandrake Linux 7.2, PIII-866. Hmmm. The problem is in locale.py. The (very simplistic) algorithm to add grouping characters only works for positive numbers. It can be re-written as: def format(f,val,grouping=0): """Formats a value in the same way that the % formatting would use, but takes the current locale into account. Grouping is applied if the third parameter is true.""" result = f % val fields = string.split(result, ".") if grouping: fields[0]=_group(fields[0]) if len(fields)==2: res = fields[0]+localeconv()['decimal_point']+fields[1] elif len(fields)==1: res = fields[0] else: raise Error, "Too many decimal points in result string" if val < 0: return '-'+res else: return res -Kevin Jacobs (jacobs@theopalgroup.com) Follow-Ups: Date: 2001-Jan-19 15:01 By: gvanrossum Comment: Martin, didn't you write that code originally? If you agree with the fix, just check it in. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129417&group_id=5470 From noreply@sourceforge.net Fri Jan 19 23:04:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 15:04:29 -0800 Subject: [Python-bugs-list] [Bug #128475] mimetools.encode (sometimes) fails when called from a thread Message-ID: Bug #128475, was updated on 2001-Jan-11 11:05 Here is a current snapshot of the bug. Project: Python Category: Threads Status: Open Resolution: None Bug Group: None Priority: 7 Submitted by: nobody Assigned to : gvanrossum Summary: mimetools.encode (sometimes) fails when called from a thread Details: I used this script to test. The code of filesender.prepare_msgs is at the end of the report. ## import threading import filesender file = open('c:/windows/desktop/mp3/Aphex Twin - Bucephalus Bouncing Ball.mp3', 'rb') t1 = threading.Thread(target=filesender.prepare_msgs, args=(file,'a@b.c')) from cStringIO import StringIO data = StringIO() import mimetools t2=threading.Thread(target=mimetools.encode, args=(file,data,'base64')) import sys if '-t1' in sys.argv: t1.start() elif '-t2' in sys.argv: t2.start() else: filesender.prepare_msgs(file, 'a@b.c') ## Results of running it with -t1, -t2, and no options, on Windows: C:\Python20>python test.py -t1 preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 Fatal Python error: Interpreter not initialized (version mismatch?) abnormal program termination C:\Python20>python test.py -t1 preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 Fatal Python error: Interpreter not initialized (version mismatch?) abnormal program termination C:\Python20>python test.py -t2 Fatal Python error: Interpreter not initialized (version mismatch?) abnormal program termination C:\Python20>python test.py -t2 C:\Python20>python test.py preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 encoded got value data length is 7807732 Encoded Aphex Twin - Bucephalus Bouncing Ball.mp3 is too large, splitting into 2 parts C:\Python20>python test.py preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 encoded got value data length is 7807732 Encoded Aphex Twin - Bucephalus Bouncing Ball.mp3 is too large, splitting into 2 parts On Linux: wolfson@senator:~% python test.py preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 encoded got value data length is 7807732 Encoded Aphex Twin - Bucephalus Bouncing Ball.mp3 is too large, splitting into 2 p arts wolfson@senator:~% python test.py -t1 preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 Fatal Python error: Interpreter not initialized (version mismatch?) Abort wolfson@senator:~% python test.py -t1 preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 Fatal Python error: Interpreter not initialized (version mismatch?) Abort wolfson@senator:~% python test.py -t2 Fatal Python error: Interpreter not initialized (version mismatch?) Abort wolfson@senator:~% python test.py -t2 Fatal Python error: Interpreter not initialized (version mismatch?) Abort wolfson@senator:~% python test.py -t2 Fatal Python error: Interpreter not initialized (version mismatch?) Abort On Sun 5 it seems to always succeed. The code for filesender.prepare_msgs: def prepare_msgs(file, addressee): data = StringIO.StringIO() fn = getname(file) print 'preparing %s' % fn mimetools.encode(file, data, 'base64') print 'encoded' data = data.getvalue() print 'got value' datalen = len(data) print 'data length is %d' % datalen if datalen > MAX_MSG_SZ: numsplits = 1 + datalen / MAX_MSG_SZ print 'Encoded %s is too large, splitting into %d parts' % (fn,numsplits) msgs = [] for i in range(numsplits): thismsg, data = data[:MAX_MSG_SZ], data[MAX_MSG_SZ:] msgs.append(fmt_message(fn, addressee, thismsg, '(%d/%d)' % (i+1, numsplits), MSG)) return msgs return [fmt_message(fn, addressee, data, '', MSG)] Follow-Ups: Date: 2001-Jan-19 15:04 By: gvanrossum Comment: Yes, fails for me too on Linux. ------------------------------------------------------- Date: 2001-Jan-19 01:58 By: tim_one Comment: Guido, I took this out of the Platform-specific group because his/her test output shows the same failures on both Windows and Linux. I assume it works on Sun5 for him because you have to kick a Sun OS in the groin to make it switch threads. [Later: Also assigned to you so that you can try the tiny program below on Linux] [Later: boosted the priority too] Anonymous submitter, sorry, but this bug report is too confusing to make head or tail of. Could you please whittle this down to a self-contained, failing program that can be executed? As is, you're showing us both code that works (which isn't interesting) and code that doesn't (which is), and none of it can be executed anyway (e.g., MAX_MSG_SZ isn't defined, getname isn't defined, fmt_message isn't defined, ...). Later: like this: BIGFILE = "pcbuild.opt" # OK, it's not really big import threading, mimetools from cStringIO import StringIO file1 = open(BIGFILE, 'rb') data1 = StringIO() t1 = threading.Thread(target=mimetools.encode, args=(file1, data1, 'base64')) t1.start() Guido, that fails for me about 1 time in 5 under Win98SE, current CVS Python, like so: C:\Code\python\dist\src\PCbuild>python tran.py Fatal Python error: Interpreter not initialized (version mismatch?) abnormal program termination C:\Code\python\dist\src\PCbuild> In the debug build it craps out (with about the same frequency) in kernel32.dll (the secret bowels of Windows, which usually means running under the debugger is futile; but I'll try that anyway when I get up again). ------------------------------------------------------- Date: 2001-Jan-15 11:54 By: gvanrossum Comment: I'm assigning this to Tim, our all-purpose Windows cleaner. :-) Thread problems like this are notoriously hard to find, so don't hold your breath. Sorry! Setting the group to platform-specific since you mention it works fine on Sun5. ------------------------------------------------------- Date: 2001-Jan-13 08:13 By: nobody Comment: I'll get you! ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128475&group_id=5470 From noreply@sourceforge.net Fri Jan 19 23:07:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 15:07:19 -0800 Subject: [Python-bugs-list] [Bug #125598] Confusing KeyError-Message when key is tuple of size 1 Message-ID: Bug #125598, was updated on 2000-Dec-13 02:38 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Closed Resolution: Wont Fix Bug Group: None Priority: 5 Submitted by: murple Assigned to : gvanrossum Summary: Confusing KeyError-Message when key is tuple of size 1 Details: Following caused some confusion for me: >>> dic = {1:1,2:"bla"} >>> dic[1] 1 >>> b = (1,) #1000 lines of code >>> dic[b] Traceback (innermost last): File "", line 1, in ? KeyError: 1 # This should be KeyError: (1,) # because 1 is a valid key for dic >>> dic[(1,2)] Traceback (innermost last): File "", line 1, in ? KeyError: (1, 2) >>> Follow-Ups: Date: 2001-Jan-19 15:07 By: gvanrossum Comment: I agree with Barry -- this is too hard to fix and hardly worth fixing, so let's close the bug report. Sorry! ------------------------------------------------------- Date: 2001-Jan-19 12:18 By: bwarsaw Comment: Assigning back to Guido for final pronouncement, but I think this should be resolved as "Won't Fix" and closed. ------------------------------------------------------- Date: 2000-Dec-13 15:54 By: bwarsaw Comment: I don't remember the exact details, but this is a byproduct of the backwards compatibility rules for Exception.__str__(). Specifically, if an exception is instantiated with a sequence of length 1, then str(exc) will return str(exc.args[0]). Note that exc.args contains the length-1 tuple it was instantiated with. This bites every built-in exception except EnvironmentError and SyntaxError, which define their own __str__(). Changing this may have unintended consequences, and I'm not sure if it's worth fixing. ------------------------------------------------------- Date: 2000-Dec-13 06:09 By: gvanrossum Comment: This seems a problem in exception reporting. I can reproduce it as follows: >>> raise KeyError, (1,) Traceback (most recent call last): File "", line 1, in ? KeyError: 1 >>> Assigned to Barry since he's the master of this code.] ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=125598&group_id=5470 From noreply@sourceforge.net Fri Jan 19 21:00:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 13:00:17 -0800 Subject: [Python-bugs-list] [Bug #129417] Negative numbers are grouped incorrectly Message-ID: Bug #129417, was updated on 2001-Jan-19 13:00 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : nobody Summary: Negative numbers are grouped incorrectly Details: >>> import locale >>> locale.setlocale(locale.LC_ALL,'') 'en' >>> print locale.format("%.2f", -100, 1) -,100.00 Linux 2.4.0 on Mandrake Linux 7.2, PIII-866. Hmmm. The problem is in locale.py. The (very simplistic) algorithm to add grouping characters only works for positive numbers. It can be re-written as: def format(f,val,grouping=0): """Formats a value in the same way that the % formatting would use, but takes the current locale into account. Grouping is applied if the third parameter is true.""" result = f % val fields = string.split(result, ".") if grouping: fields[0]=_group(fields[0]) if len(fields)==2: res = fields[0]+localeconv()['decimal_point']+fields[1] elif len(fields)==1: res = fields[0] else: raise Error, "Too many decimal points in result string" if val < 0: return '-'+res else: return res -Kevin Jacobs (jacobs@theopalgroup.com) For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129417&group_id=5470 From noreply@sourceforge.net Fri Jan 19 21:15:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 13:15:14 -0800 Subject: [Python-bugs-list] [Bug #129379] LINKFORSHARED usage incorrently documented Message-ID: Bug #129379, was updated on 2001-Jan-19 06:33 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: nobody Assigned to : fdrake Summary: LINKFORSHARED usage incorrently documented Details: http://www.python.org/doc/2.0/ext/link-reqs.html says to get link-flags like this: >>> import distutils.sysconfig >>> distutils.sysconfig.LINKFORSHARED '-Xlinker -export-dynamic' But this does not work. The following line worked, although I'm not sure if it is Correct. >>> distutils.sysconfig.get_config_vars()['LINKFORSHARED'] /Jesper (jojo@virtutech.se) Follow-Ups: Date: 2001-Jan-19 13:15 By: fdrake Comment: This is already corrected in the CVS version of the docuementation; the 2.1 alpha packages will contain the correction. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129379&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:31:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:31:49 -0800 Subject: [Python-bugs-list] [Bug #129344] Section 7.1, Sentence makes no sense Message-ID: Bug #129344, was updated on 2001-Jan-18 19:55 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: andrewwhite Assigned to : fdrake Summary: Section 7.1, Sentence makes no sense Details: From: http://www.python.org/doc/2.0/tut/node9.html Section 7.1 This sentence doesn't make sense to me. "The % operator interprets the left argument as a C much like a sprintf()-style format string to be applied to the right argument, and returns the string resulting from this formatting operation." As a C which is like a sprintf format string? Or is it supposed to be "a format string (much like C's sprintf) ..."? Follow-Ups: Date: 2001-Jan-19 14:31 By: fdrake Comment: This has already been fixed in the CVS version of the documentation; the fix will be included in the 2.1 alpha release packages. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129344&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:35:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:35:22 -0800 Subject: [Python-bugs-list] [Bug #129345] Section 4.6, Minor grammatical error Message-ID: Bug #129345, was updated on 2001-Jan-18 19:58 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: andrewwhite Assigned to : fdrake Summary: Section 4.6, Minor grammatical error Details: http://www.python.org/doc/2.0/tut/node6.html Tutorial, Section 4.6 ORIGINAL The return statement returns with a value from a function. return without an expression argument is used to return from the middle of a procedure (falling off the end also returns from a procedure), in which case the None value is returned. END which I don't think means what it says (which is that return from the middle of a proc returns None). Is suspect this would read better as: CHANGED ... from the middle of a procedure. Falling off the end also returns from a procedure, in which case the None value is returned. END Follow-Ups: Date: 2001-Jan-19 14:35 By: fdrake Comment: Actually that is correct, but confusing. Using "return" without an expression does cause None to be returned, regardless of where in the procedure it is used that way. Clarified in Doc/tut/tut.tex revision 1.125. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129345&group_id=5470 From noreply@sourceforge.net Fri Jan 19 22:49:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 14:49:03 -0800 Subject: [Python-bugs-list] [Bug #129234] Various typo in the API ref manual Message-ID: Bug #129234, was updated on 2001-Jan-18 05:20 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: gcivario Assigned to : fdrake Summary: Various typo in the API ref manual Details: Those typo are present on the version 1.103 of the release 2.0 of the manual. * Page 14 in function PyErr_Format: \var{fmt} used insted of \var{format} * Page 15 in function PyErr_Warn: found NULL instead of \NULL{} * Page 17 in function Py_FdIsInteractive: \var{name} found instead of \var{filename} * Page 22 in function PyObject_CallObject and PyObject_CallFunction: replace o with callable_object * Page 22 in function PyObject_CallMethode: in the equivalent Python statement, change method with m * Page 24 in function PyNumber_And: remplace \& with \&\ * Page 24 in function PyNumber_InPlacePower: add a '\' before 'var{o3} * Page 24 in function PyNumber_AndInPlace: there is \var{o2} 2 times * Page 26 in function PySequence_DelItem: replace \var{v} with \var{o} * Page 29 in the 3° line: replace the '.' after 'exemple' with a ',' Regards Gilles Civario Follow-Ups: Date: 2001-Jan-19 14:49 By: fdrake Comment: Fixed in Doc/api/api.tex revision 1.104. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129234&group_id=5470 From noreply@sourceforge.net Fri Jan 19 23:10:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 15:10:29 -0800 Subject: [Python-bugs-list] [Bug #128475] mimetools.encode (sometimes) fails when called from a thread Message-ID: Bug #128475, was updated on 2001-Jan-11 11:05 Here is a current snapshot of the bug. Project: Python Category: Threads Status: Open Resolution: None Bug Group: None Priority: 7 Submitted by: nobody Assigned to : gvanrossum Summary: mimetools.encode (sometimes) fails when called from a thread Details: I used this script to test. The code of filesender.prepare_msgs is at the end of the report. ## import threading import filesender file = open('c:/windows/desktop/mp3/Aphex Twin - Bucephalus Bouncing Ball.mp3', 'rb') t1 = threading.Thread(target=filesender.prepare_msgs, args=(file,'a@b.c')) from cStringIO import StringIO data = StringIO() import mimetools t2=threading.Thread(target=mimetools.encode, args=(file,data,'base64')) import sys if '-t1' in sys.argv: t1.start() elif '-t2' in sys.argv: t2.start() else: filesender.prepare_msgs(file, 'a@b.c') ## Results of running it with -t1, -t2, and no options, on Windows: C:\Python20>python test.py -t1 preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 Fatal Python error: Interpreter not initialized (version mismatch?) abnormal program termination C:\Python20>python test.py -t1 preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 Fatal Python error: Interpreter not initialized (version mismatch?) abnormal program termination C:\Python20>python test.py -t2 Fatal Python error: Interpreter not initialized (version mismatch?) abnormal program termination C:\Python20>python test.py -t2 C:\Python20>python test.py preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 encoded got value data length is 7807732 Encoded Aphex Twin - Bucephalus Bouncing Ball.mp3 is too large, splitting into 2 parts C:\Python20>python test.py preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 encoded got value data length is 7807732 Encoded Aphex Twin - Bucephalus Bouncing Ball.mp3 is too large, splitting into 2 parts On Linux: wolfson@senator:~% python test.py preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 encoded got value data length is 7807732 Encoded Aphex Twin - Bucephalus Bouncing Ball.mp3 is too large, splitting into 2 p arts wolfson@senator:~% python test.py -t1 preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 Fatal Python error: Interpreter not initialized (version mismatch?) Abort wolfson@senator:~% python test.py -t1 preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 Fatal Python error: Interpreter not initialized (version mismatch?) Abort wolfson@senator:~% python test.py -t2 Fatal Python error: Interpreter not initialized (version mismatch?) Abort wolfson@senator:~% python test.py -t2 Fatal Python error: Interpreter not initialized (version mismatch?) Abort wolfson@senator:~% python test.py -t2 Fatal Python error: Interpreter not initialized (version mismatch?) Abort On Sun 5 it seems to always succeed. The code for filesender.prepare_msgs: def prepare_msgs(file, addressee): data = StringIO.StringIO() fn = getname(file) print 'preparing %s' % fn mimetools.encode(file, data, 'base64') print 'encoded' data = data.getvalue() print 'got value' datalen = len(data) print 'data length is %d' % datalen if datalen > MAX_MSG_SZ: numsplits = 1 + datalen / MAX_MSG_SZ print 'Encoded %s is too large, splitting into %d parts' % (fn,numsplits) msgs = [] for i in range(numsplits): thismsg, data = data[:MAX_MSG_SZ], data[MAX_MSG_SZ:] msgs.append(fmt_message(fn, addressee, thismsg, '(%d/%d)' % (i+1, numsplits), MSG)) return msgs return [fmt_message(fn, addressee, data, '', MSG)] Follow-Ups: Date: 2001-Jan-19 15:10 By: gvanrossum Comment: I'm pretty sure it's because mimetools.encode imports base64, and doing that in the thread somehow screws things up. I'll look into it more later -- or Tim can aim his debugger at it (I won't get to this before the 2.1a1 release I'm afraid). ------------------------------------------------------- Date: 2001-Jan-19 15:04 By: gvanrossum Comment: Yes, fails for me too on Linux. ------------------------------------------------------- Date: 2001-Jan-19 01:58 By: tim_one Comment: Guido, I took this out of the Platform-specific group because his/her test output shows the same failures on both Windows and Linux. I assume it works on Sun5 for him because you have to kick a Sun OS in the groin to make it switch threads. [Later: Also assigned to you so that you can try the tiny program below on Linux] [Later: boosted the priority too] Anonymous submitter, sorry, but this bug report is too confusing to make head or tail of. Could you please whittle this down to a self-contained, failing program that can be executed? As is, you're showing us both code that works (which isn't interesting) and code that doesn't (which is), and none of it can be executed anyway (e.g., MAX_MSG_SZ isn't defined, getname isn't defined, fmt_message isn't defined, ...). Later: like this: BIGFILE = "pcbuild.opt" # OK, it's not really big import threading, mimetools from cStringIO import StringIO file1 = open(BIGFILE, 'rb') data1 = StringIO() t1 = threading.Thread(target=mimetools.encode, args=(file1, data1, 'base64')) t1.start() Guido, that fails for me about 1 time in 5 under Win98SE, current CVS Python, like so: C:\Code\python\dist\src\PCbuild>python tran.py Fatal Python error: Interpreter not initialized (version mismatch?) abnormal program termination C:\Code\python\dist\src\PCbuild> In the debug build it craps out (with about the same frequency) in kernel32.dll (the secret bowels of Windows, which usually means running under the debugger is futile; but I'll try that anyway when I get up again). ------------------------------------------------------- Date: 2001-Jan-15 11:54 By: gvanrossum Comment: I'm assigning this to Tim, our all-purpose Windows cleaner. :-) Thread problems like this are notoriously hard to find, so don't hold your breath. Sorry! Setting the group to platform-specific since you mention it works fine on Sun5. ------------------------------------------------------- Date: 2001-Jan-13 08:13 By: nobody Comment: I'll get you! ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128475&group_id=5470 From noreply@sourceforge.net Fri Jan 19 23:11:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 15:11:02 -0800 Subject: [Python-bugs-list] [Bug #128040] memory leak with multiple Py_Initialize/Py_Finalize calls Message-ID: Bug #128040, was updated on 2001-Jan-08 07:00 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: pbmtl Assigned to : gvanrossum Summary: memory leak with multiple Py_Initialize/Py_Finalize calls Details: I run script that use the win32 extension embedded in a server. When I call the Py_Finalize method, the memory is not free completely. Each time I run a script, my server uses more and more memory. I think the Patch #101713 talk about this problem. It seems that python have problem handling multiple Py_Initialize and Py_Finalise when extension are used. Follow-Ups: Date: 2001-Jan-19 15:11 By: gvanrossum Comment: One for Barry and Insure++! ------------------------------------------------------- Date: 2001-Jan-10 08:59 By: gvanrossum Comment: I agree with Mark that in the past we have been lax in addressing these kinds of problems. I do wish to fix these in the future! It's just hard to find all the leaks. In the past we had reports where a simple loop calling Py_Initialize() and Py_Finalize() with nothing in between would leak; we've fixed these. But now if you put real work in between it still seems to leak. I'll see if I can check in a test program in the Demo tree which Barry can then work on using Insure++. pbmtl, when you write that "the call to PyEval_CallObject will return an error", can you submit a separate bug report for that with enough details (e.g. C source code) so that we can reproduce the problem? This seems to be a separate bug, unrelated to leakage! ------------------------------------------------------- Date: 2001-Jan-10 06:17 By: pbmtl Comment: I agree with you that it's not that important when script are executed using PythonWin for example, because when PythonWin is closed, the memory is recover. But if you use python embedded in a server on a remote computer that is never supposed to be stopped, it's a real problem. The memory usage increase rapidly, Hundreds KB at each execution in my case. In fact, I can't call PyInitialize and PyFinalize for each script because if I do, the second script to be executed will not work correctly (the call to PyEval_CallObject will return an error). I use the Py_NewInterpreter and the Py_EndInterpreter. For my part, I think the script virtual machine should be responsable of the memory created by the scripts. Otherwise, there is no garanty that the PyFinalyze will free the memory correctly. Thanks ------------------------------------------------------- Date: 2001-Jan-09 21:20 By: tim_one Comment: Thank you, Mark! Since nobody is going to volunteer to do all this stuff, and everyone else will try to stop them if they did , I reassigned it to Guido -- it's never going to get done if he doesn't push for it (and if he doesn't think it's worth the effort, that's fine too, but that's his call). ------------------------------------------------------- Date: 2001-Jan-09 17:11 By: mhammond Comment: I dont believe this is Windows specific, nor specific to the Win32 extensions. I can confirm that Python does leak with multiple Init/Terms, as I had to change the COM extensions to only initialize once (and hence never finalize). It is definitely related to the referenced patch (#101713) This has been raised before, but there doesnt appear much enthusiasm for a fix. As far as I can tell, it would involve having Py_Finalize() correctly release _all_ memory allocated by Py_Initialize(). However, I have seen numerous people state that "one off" allocations that are not freed are not worth finding and freeing - however, if this bug wants a fix, then we must track them all down. I further note that the problem is not only in the Python core, but in extension modules. Modules need a reliable way to be told that Python is finalizing so they can free their own "one off" allocations. Various hacks have been proposed for this (eg, rely on ref-count semantics to ensure that a special object is destroyed as the module dict is cleared) but nothing "reasonable" has been proposed. Really not sure what I can do here. I am willing to do my bit in patching up the leaks, but would want a (fuzzy) commitment from python-dev that I wouldnt be doing it alone, and that it is seen as important. I have updated the bug description and platform appropriately, but haven't reallocated a new person. ------------------------------------------------------- Date: 2001-Jan-09 14:38 By: tim_one Comment: Reassigned to MarkH. Mark, sound familiar? ------------------------------------------------------- Date: 2001-Jan-08 18:02 By: gvanrossum Comment: Assigned to Tim. First task would be to request needed infromation from submitter. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128040&group_id=5470 From noreply@sourceforge.net Fri Jan 19 23:11:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 15:11:27 -0800 Subject: [Python-bugs-list] [Bug #117608] test_largefile crashes or IRIX 6 Message-ID: Bug #117608, was updated on 2000-Oct-24 08:51 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Closed Resolution: Works For Me Bug Group: Platform-specific Priority: 1 Submitted by: bbaxter Assigned to : gvanrossum Summary: test_largefile crashes or IRIX 6 Details: During "make test", test_largefile caused an error. Here's the result in python: % python python2.0/test/test_largefile.py create large file via seek (may be sparse file) ... Traceback (most recent call last): File "python2.0/test/test_largefile.py", line 60, in ? f.flush() IOError: [Errno 22] Invalid argument Here's the version I'm running: Python 2.0 (#5, Oct 24 2000, 09:51:57) [C] on irix6 Follow-Ups: Date: 2001-Jan-19 15:11 By: gvanrossum Comment: Closing now. ------------------------------------------------------- Date: 2001-Jan-18 19:45 By: gvanrossum Comment: Lowering the priority; Sjoerd's theory sounds very plausible! Can the original submittor confirm this? Then we can close the bug report... Barry still can't do anything about this... ------------------------------------------------------- Date: 2000-Dec-13 09:09 By: sjoerd Comment: Assigned back to Barry so that he can deal with this further. I'm on vacation as of tomorrow. My guess is that the problem is a lack of disk space on the user's test machine. When you seek far away and write a byte on an SGI file system (EFS or XFS) the system actually allocates the blocks. There is no such thing as holes in files on the SGI file systems. I happen to have enough disk space available, so the test runs fine. I assume the submitter of the bug didn't have enough disk space available and so the flush couldn't complete. ------------------------------------------------------- Date: 2000-Dec-12 13:56 By: bwarsaw Comment: Reassigning because I have neither large file support nor an IRIX machine. Guido suggests that Sjoerd might have access to IRIX. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=117608&group_id=5470 From noreply@sourceforge.net Fri Jan 19 23:11:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 15:11:39 -0800 Subject: [Python-bugs-list] [Bug #128040] memory leak with multiple Py_Initialize/Py_Finalize calls Message-ID: Bug #128040, was updated on 2001-Jan-08 07:00 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: pbmtl Assigned to : bwarsaw Summary: memory leak with multiple Py_Initialize/Py_Finalize calls Details: I run script that use the win32 extension embedded in a server. When I call the Py_Finalize method, the memory is not free completely. Each time I run a script, my server uses more and more memory. I think the Patch #101713 talk about this problem. It seems that python have problem handling multiple Py_Initialize and Py_Finalise when extension are used. Follow-Ups: Date: 2001-Jan-19 15:11 By: gvanrossum Comment: One for Barry and Insure++! ------------------------------------------------------- Date: 2001-Jan-10 08:59 By: gvanrossum Comment: I agree with Mark that in the past we have been lax in addressing these kinds of problems. I do wish to fix these in the future! It's just hard to find all the leaks. In the past we had reports where a simple loop calling Py_Initialize() and Py_Finalize() with nothing in between would leak; we've fixed these. But now if you put real work in between it still seems to leak. I'll see if I can check in a test program in the Demo tree which Barry can then work on using Insure++. pbmtl, when you write that "the call to PyEval_CallObject will return an error", can you submit a separate bug report for that with enough details (e.g. C source code) so that we can reproduce the problem? This seems to be a separate bug, unrelated to leakage! ------------------------------------------------------- Date: 2001-Jan-10 06:17 By: pbmtl Comment: I agree with you that it's not that important when script are executed using PythonWin for example, because when PythonWin is closed, the memory is recover. But if you use python embedded in a server on a remote computer that is never supposed to be stopped, it's a real problem. The memory usage increase rapidly, Hundreds KB at each execution in my case. In fact, I can't call PyInitialize and PyFinalize for each script because if I do, the second script to be executed will not work correctly (the call to PyEval_CallObject will return an error). I use the Py_NewInterpreter and the Py_EndInterpreter. For my part, I think the script virtual machine should be responsable of the memory created by the scripts. Otherwise, there is no garanty that the PyFinalyze will free the memory correctly. Thanks ------------------------------------------------------- Date: 2001-Jan-09 21:20 By: tim_one Comment: Thank you, Mark! Since nobody is going to volunteer to do all this stuff, and everyone else will try to stop them if they did , I reassigned it to Guido -- it's never going to get done if he doesn't push for it (and if he doesn't think it's worth the effort, that's fine too, but that's his call). ------------------------------------------------------- Date: 2001-Jan-09 17:11 By: mhammond Comment: I dont believe this is Windows specific, nor specific to the Win32 extensions. I can confirm that Python does leak with multiple Init/Terms, as I had to change the COM extensions to only initialize once (and hence never finalize). It is definitely related to the referenced patch (#101713) This has been raised before, but there doesnt appear much enthusiasm for a fix. As far as I can tell, it would involve having Py_Finalize() correctly release _all_ memory allocated by Py_Initialize(). However, I have seen numerous people state that "one off" allocations that are not freed are not worth finding and freeing - however, if this bug wants a fix, then we must track them all down. I further note that the problem is not only in the Python core, but in extension modules. Modules need a reliable way to be told that Python is finalizing so they can free their own "one off" allocations. Various hacks have been proposed for this (eg, rely on ref-count semantics to ensure that a special object is destroyed as the module dict is cleared) but nothing "reasonable" has been proposed. Really not sure what I can do here. I am willing to do my bit in patching up the leaks, but would want a (fuzzy) commitment from python-dev that I wouldnt be doing it alone, and that it is seen as important. I have updated the bug description and platform appropriately, but haven't reallocated a new person. ------------------------------------------------------- Date: 2001-Jan-09 14:38 By: tim_one Comment: Reassigned to MarkH. Mark, sound familiar? ------------------------------------------------------- Date: 2001-Jan-08 18:02 By: gvanrossum Comment: Assigned to Tim. First task would be to request needed infromation from submitter. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128040&group_id=5470 From noreply@sourceforge.net Sat Jan 20 00:15:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 16:15:01 -0800 Subject: [Python-bugs-list] [Bug #129417] Negative numbers are grouped incorrectly Message-ID: Bug #129417, was updated on 2001-Jan-19 13:00 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : loewis Summary: Negative numbers are grouped incorrectly Details: >>> import locale >>> locale.setlocale(locale.LC_ALL,'') 'en' >>> print locale.format("%.2f", -100, 1) -,100.00 Linux 2.4.0 on Mandrake Linux 7.2, PIII-866. Hmmm. The problem is in locale.py. The (very simplistic) algorithm to add grouping characters only works for positive numbers. It can be re-written as: def format(f,val,grouping=0): """Formats a value in the same way that the % formatting would use, but takes the current locale into account. Grouping is applied if the third parameter is true.""" result = f % val fields = string.split(result, ".") if grouping: fields[0]=_group(fields[0]) if len(fields)==2: res = fields[0]+localeconv()['decimal_point']+fields[1] elif len(fields)==1: res = fields[0] else: raise Error, "Too many decimal points in result string" if val < 0: return '-'+res else: return res -Kevin Jacobs (jacobs@theopalgroup.com) Follow-Ups: Date: 2001-Jan-19 16:15 By: nobody Comment: Oops. That will teach me to cut-and-paste without looking. result = f % val should be result = f % abs(val) -Kevin ------------------------------------------------------- Date: 2001-Jan-19 15:01 By: gvanrossum Comment: Martin, didn't you write that code originally? If you agree with the fix, just check it in. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129417&group_id=5470 From noreply@sourceforge.net Sat Jan 20 05:21:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 21:21:16 -0800 Subject: [Python-bugs-list] [Bug #128475] mimetools.encode (sometimes) fails when called from a thread Message-ID: Bug #128475, was updated on 2001-Jan-11 11:05 Here is a current snapshot of the bug. Project: Python Category: Threads Status: Open Resolution: None Bug Group: None Priority: 7 Submitted by: nobody Assigned to : tim_one Summary: mimetools.encode (sometimes) fails when called from a thread Details: I used this script to test. The code of filesender.prepare_msgs is at the end of the report. ## import threading import filesender file = open('c:/windows/desktop/mp3/Aphex Twin - Bucephalus Bouncing Ball.mp3', 'rb') t1 = threading.Thread(target=filesender.prepare_msgs, args=(file,'a@b.c')) from cStringIO import StringIO data = StringIO() import mimetools t2=threading.Thread(target=mimetools.encode, args=(file,data,'base64')) import sys if '-t1' in sys.argv: t1.start() elif '-t2' in sys.argv: t2.start() else: filesender.prepare_msgs(file, 'a@b.c') ## Results of running it with -t1, -t2, and no options, on Windows: C:\Python20>python test.py -t1 preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 Fatal Python error: Interpreter not initialized (version mismatch?) abnormal program termination C:\Python20>python test.py -t1 preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 Fatal Python error: Interpreter not initialized (version mismatch?) abnormal program termination C:\Python20>python test.py -t2 Fatal Python error: Interpreter not initialized (version mismatch?) abnormal program termination C:\Python20>python test.py -t2 C:\Python20>python test.py preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 encoded got value data length is 7807732 Encoded Aphex Twin - Bucephalus Bouncing Ball.mp3 is too large, splitting into 2 parts C:\Python20>python test.py preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 encoded got value data length is 7807732 Encoded Aphex Twin - Bucephalus Bouncing Ball.mp3 is too large, splitting into 2 parts On Linux: wolfson@senator:~% python test.py preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 encoded got value data length is 7807732 Encoded Aphex Twin - Bucephalus Bouncing Ball.mp3 is too large, splitting into 2 p arts wolfson@senator:~% python test.py -t1 preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 Fatal Python error: Interpreter not initialized (version mismatch?) Abort wolfson@senator:~% python test.py -t1 preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 Fatal Python error: Interpreter not initialized (version mismatch?) Abort wolfson@senator:~% python test.py -t2 Fatal Python error: Interpreter not initialized (version mismatch?) Abort wolfson@senator:~% python test.py -t2 Fatal Python error: Interpreter not initialized (version mismatch?) Abort wolfson@senator:~% python test.py -t2 Fatal Python error: Interpreter not initialized (version mismatch?) Abort On Sun 5 it seems to always succeed. The code for filesender.prepare_msgs: def prepare_msgs(file, addressee): data = StringIO.StringIO() fn = getname(file) print 'preparing %s' % fn mimetools.encode(file, data, 'base64') print 'encoded' data = data.getvalue() print 'got value' datalen = len(data) print 'data length is %d' % datalen if datalen > MAX_MSG_SZ: numsplits = 1 + datalen / MAX_MSG_SZ print 'Encoded %s is too large, splitting into %d parts' % (fn,numsplits) msgs = [] for i in range(numsplits): thismsg, data = data[:MAX_MSG_SZ], data[MAX_MSG_SZ:] msgs.append(fmt_message(fn, addressee, thismsg, '(%d/%d)' % (i+1, numsplits), MSG)) return msgs return [fmt_message(fn, addressee, data, '', MSG)] Follow-Ups: Date: 2001-Jan-19 21:21 By: tim_one Comment: Guido, I'm assuming that means you were able to get the small program to fail under Linux too. Under that assumption, I reassigned back to me. ------------------------------------------------------- Date: 2001-Jan-19 15:10 By: gvanrossum Comment: I'm pretty sure it's because mimetools.encode imports base64, and doing that in the thread somehow screws things up. I'll look into it more later -- or Tim can aim his debugger at it (I won't get to this before the 2.1a1 release I'm afraid). ------------------------------------------------------- Date: 2001-Jan-19 15:04 By: gvanrossum Comment: Yes, fails for me too on Linux. ------------------------------------------------------- Date: 2001-Jan-19 01:58 By: tim_one Comment: Guido, I took this out of the Platform-specific group because his/her test output shows the same failures on both Windows and Linux. I assume it works on Sun5 for him because you have to kick a Sun OS in the groin to make it switch threads. [Later: Also assigned to you so that you can try the tiny program below on Linux] [Later: boosted the priority too] Anonymous submitter, sorry, but this bug report is too confusing to make head or tail of. Could you please whittle this down to a self-contained, failing program that can be executed? As is, you're showing us both code that works (which isn't interesting) and code that doesn't (which is), and none of it can be executed anyway (e.g., MAX_MSG_SZ isn't defined, getname isn't defined, fmt_message isn't defined, ...). Later: like this: BIGFILE = "pcbuild.opt" # OK, it's not really big import threading, mimetools from cStringIO import StringIO file1 = open(BIGFILE, 'rb') data1 = StringIO() t1 = threading.Thread(target=mimetools.encode, args=(file1, data1, 'base64')) t1.start() Guido, that fails for me about 1 time in 5 under Win98SE, current CVS Python, like so: C:\Code\python\dist\src\PCbuild>python tran.py Fatal Python error: Interpreter not initialized (version mismatch?) abnormal program termination C:\Code\python\dist\src\PCbuild> In the debug build it craps out (with about the same frequency) in kernel32.dll (the secret bowels of Windows, which usually means running under the debugger is futile; but I'll try that anyway when I get up again). ------------------------------------------------------- Date: 2001-Jan-15 11:54 By: gvanrossum Comment: I'm assigning this to Tim, our all-purpose Windows cleaner. :-) Thread problems like this are notoriously hard to find, so don't hold your breath. Sorry! Setting the group to platform-specific since you mention it works fine on Sun5. ------------------------------------------------------- Date: 2001-Jan-13 08:13 By: nobody Comment: I'll get you! ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128475&group_id=5470 From noreply@sourceforge.net Sat Jan 20 06:36:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 19 Jan 2001 22:36:11 -0800 Subject: [Python-bugs-list] [Bug #129179] Memory leak on repeated reloads Message-ID: Bug #129179, was updated on 2001-Jan-17 13:57 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: cgw Assigned to : bwarsaw Summary: Memory leak on repeated reloads Details: boo.py: ========== Class Boo: pass a = [1] b = Boo() def testit(): try: divmod(a,b) except TypeError, msg: print msg testit() =========== import boo while 1: reload(boo) Follow-Ups: Date: 2001-Jan-19 22:36 By: bwarsaw Comment: Running top while executing this program shows no memory growth using the current CVS snapshot as of 20-Jan-2001, 1:34am EST. RH6.1. Charles, can you verify? If it's growing for you, I'll run it through Insure (but I'm currently Insuring another memory leak, which is why I've only done the top test for now). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129179&group_id=5470 From noreply@sourceforge.net Sat Jan 20 13:03:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 20 Jan 2001 05:03:07 -0800 Subject: [Python-bugs-list] [Bug #129475] How to validate a text box using Python Message-ID: Bug #129475, was updated on 2001-Jan-20 05:03 Here is a current snapshot of the bug. Project: Python Category: demos and tools Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Submitted by: nobody Assigned to : nobody Summary: How to validate a text box using Python Details: Please tell me how to validate a text box using python For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129475&group_id=5470 From noreply@sourceforge.net Sat Jan 20 14:22:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 20 Jan 2001 06:22:40 -0800 Subject: [Python-bugs-list] [Bug #124981] zlib decompress of sync-flushed data fails Message-ID: Bug #124981, was updated on 2000-Dec-07 23:25 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: abo Assigned to : akuchling Summary: zlib decompress of sync-flushed data fails Details: I'm not sure if this is just an undocumented limitation or a genuine bug. I'm using python 1.5.2 on winNT. A single decompress of a large amount (16K+) of compressed data that has been sync-flushed fails to produce all the data up to the sync-flush. The data remains inside the decompressor untill further compressed data or a final flush is issued. Note that the 'unused_data' attribute does not show that there is further data in the decompressor to process (it shows ''). A workaround is to decompress the data in smaller chunks. Note that compressing data in smaller chunks is not required, as the problem is in the decompressor, not the compressor. The following code demonstrates the problem, and raises an exception when the compressed data reaches 17K; from zlib import * from random import * # create compressor and decompressor c=compressobj(9) d=decompressobj() # try data sizes of 1-63K for l in range(1,64): # generate random data stream a='' for i in range(l*1024): a=a+chr(randint(0,255)) # compress, sync-flush, and decompress t=d.decompress(c.compress(a)+c.flush(Z_SYNC_FLUSH)) # if decompressed data is different to input data, barf, if len(t) != len(a): print len(a),len(t),len(d.unused_data) raise error Follow-Ups: Date: 2001-Jan-20 06:22 By: abo Comment: OK, Christmas is over, and I didn't really get a chance to look at it much. However, some preliminary testing of the zlib library suggests that it is _not_ in zlib. A c program that does the same compress/decompress of random data using steadily increasing block sizes does not show the same fault... I've noticed what might be a potential problem in the inflateInit2 call in PyZlib_decompressobj. The next_in and avail_in are not being initialized before it's called. The zlib manual says they should be init'ed because deflateInit will attempt to determine the compression method if it can. I'm not sure why this hasn't tripped already... does PyObject_New zero memory when it allocates things? I also think I've found the main problem... the PyZlib_objdecompress routine's main decompression loop thinks decompression is compelete when all available input has been processed. However, it is possible that all available input has been processed but there is more pending output. The code as it stands does correctly allocate more space when this occurs, but the loop terminates without calling inflate one more time. I'm putting together a patch tomorrow. Right now I'm going to bed... ------------------------------------------------------- Date: 2000-Dec-20 15:17 By: abo Comment: I have had a look at this in more detail (Python C interfacing is actually pretty easy :-). I dunno whether to go into details here, but I have noticed that inflate is being called with Z_NO_FLUSH when the zlib docs suggest Z_SYNC_FLUSH or Z_FINISH. However, the zlib implementation only treats Z_FINISH differently, so this should not make a difference (but it might in future versions of zlib). As you have said, .unused_data will only contain data if something is appended to a complete compressed object in the stream fed to a decompressor. Perhaps the docs need something to clarify this, perhaps in the form of an example? I am going to write some test progs to see if it's in zlib. At this stage I suspect that it is, and I'm hoping over christmas to get a patch done. ------------------------------------------------------- Date: 2000-Dec-19 11:48 By: akuchling Comment: .unused_data is really a red herring; the PyZlib_objdecompress() loops until zst->avail_in is zero, so .unused_data must always be zero by definition. (The attribute is there to support gzip-format files that may contain multiple compressed streams concatenated together.) I still have no idea what the documentation should say; "don't pass more than 16K of compressed data when you're expecting a sync-flush." I can't see a way to explain this coherently without a big long explanation that will confuse people who don't care about this problem. (Add a special note, or known bugs subsection, maybe?) A simple C test program should be written, in order to check if it's the zlib library itself that's doing this. ------------------------------------------------------- Date: 2000-Dec-18 20:13 By: fdrake Comment: Andrew, please summarize what doc changes are needed, or make the changes (whichever is easier for you is fine). ------------------------------------------------------- Date: 2000-Dec-12 15:18 By: abo Comment: Further comments... After looking at the C code, a few things became clear; I need to read more about C/Python interfacing, and the "unused_data" attribute will only contain data if additional data is fed to a de-compressor at the end of a complete compressed stream. The purpose of the "unused_data" attribute is not clear in the documentation, so that should probably be clarified (mind you, I am looking at pre-2.0 docs so maybe it already has?). The failure to produce all data up to a sync-flush is something else... I'm still looking into it. I'm not sure if it is an inherent limitation of zlib, something that needs to be fixed in zlib, or something that needs to be fixed in the python interface. If it is an inherent limitation, I'd like to characterise it a bit better before documenting it. If it is something that needs to be fixed in either zlib or the python interface, I'd like to fix it. Unfortunately, this is a bit beyond me at the moment, mainly in time, but also a bit in skill (need to read the python/C interfacing documentation). Maybe over the christmas holidays I'll get a chance to fix it. ------------------------------------------------------- Date: 2000-Dec-12 13:32 By: gvanrossum Comment: OK, assigned to Fred. You may ask Andrew what to write. :-) ------------------------------------------------------- Date: 2000-Dec-08 14:50 By: abo Comment: I'm not that sure I'm happy with it just being marked closed. AFAIKT, the implementation definitely doesn't do what the documentation says, so to save people like me time when they hit it, I'prefer the bug at least be assigned to documentation so that the limitation is documented. >From my reading of the documentation as it stands, the fact that there is more pending data in the decompressor should be indicated by it's "unused_data" attribute. The tests seem to show that "decompress()" is only processing 16K of compressed data each call, which would suggest that "unused_data" should contain the rest. However, in all my tests that attribute has always been empty. Perhaps the bug is in there somewhere? Another slight strangeness, even if "unused_data" did contain something, the only way to get it out is by feeding in more compressed data, or issuing a flush(), thus ending the decompression... I guess that since I've been bitten by this, it's up to me to fix it. I've got the source to 2.0 and I'll have a look and see if I can submit a patch. and I was coding this app in python to avoid coding in C :-) ------------------------------------------------------- Date: 2000-Dec-08 09:26 By: akuchling Comment: Python 2.0 demonstrates the problem, too. I'm not sure what this is: a zlibmodule bug/oversight or simply problems with zlib's API. Looking at zlib.h, it implies that you'd have to call inflate() with the flush parameter set to Z_SYNC_FLUSH to get the remaining data. Unfortunately this doesn't seem to help -- .flush() method doesn't support an argument, but when I patch zlibmodule.c to allow one, .flush(Z_SYNC_FLUSH) always fails with a -5: buffer error, perhaps because it expects there to be some new data. (The DEFAULTALLOC constant in zlibmodule.c is 16K, but this seems to be unrelated to the problem showing up with more than 16K of data, since changing DEFAULTALLOC to 32K or 1K makes no difference to the size of data at which the bug shows up.) In short, I have no idea what's at fault, or if it can or should be fixed. Unless you or someone else submits a patch, I'll just leave it alone, and mark this bug as closed and "Won't fix". ------------------------------------------------------- Date: 2000-Dec-08 07:44 By: gvanrossum Comment: I *think* this may have been fixed in Python 2.0. I'm assigning this to Andrew who can confirm that and close the bug report (if it is fixed). ------------------------------------------------------- Date: 2000-Dec-07 23:28 By: abo Comment: Argh... SF killed all my indents... sorry about that. You should be able to figure it out, but if not email me and I can send a copy. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=124981&group_id=5470 From noreply@sourceforge.net Sat Jan 20 16:51:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 20 Jan 2001 08:51:36 -0800 Subject: [Python-bugs-list] [Bug #117464] clash with BSD db when building Message-ID: Bug #117464, was updated on 2000-Oct-23 00:29 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: fleury Assigned to : twouters Summary: clash with BSD db when building Details: On RH7.0, beside the LONG_BIT issue, I came across a db.h missmatch. The preprocessor directive values used in bsddbmodule.c correspond to the /usr/include/db1/db.h file, but on my system, /usr/include/db.h points to db3/db.h which does not define the same set of values, and does not compile. Compiling with the old file works, but obviously it does not link... configure (with no options) ran trouble free. The system is: RedHat 7.0 gcc version 2.96 20000731 (yes with the LONG_BIT problem) Python 2.0 final release Regards, Pascal Follow-Ups: Date: 2001-Jan-20 08:51 By: twouters Comment: Apologies for not responding sooner, but I'm not sure how to fix this in autoconf, except for redoing the test entirely, and PEP-229 shows good promise for fixing this. The answer is pretty complicated anyway. db_185.h comes with BSDDB 2 and 3, and under RedHat 7, BSDDB 1, 2 and 3 can all be installed at the same time, in /usr/local/{db1,db2,db3}. I think the right fix would be to remove the autoconf stuff, and just check for the existance of db_185.h in /usr/include/db3 or /usr/include/db2, or the existance of db.h in /usr/include/db1, and then link with the right library (which can be libdb-3.1.so, libdb2.so and libdb1.so on my RedHat system. Confusing, isn't it ? :) I'll see if I can fix something up, unless someone else does it before me. ------------------------------------------------------- Date: 2001-Jan-02 09:13 By: montanaro Comment: Reassigned to Thomas Wouters because I think he has RH7.0. I can't test this directly and haven't had time to investigate. My apologies for waiting so long to slough this off to someone else. ------------------------------------------------------- Date: 2000-Nov-06 08:40 By: montanaro Comment: This is going to require a bit of effort. My current scheme for detecting whether bsddb can be built/linked or not relies on the presence or absence of db.h and/or db_185.h. If db_185.h is present, libdb v.2 is assumed. If only db.h is present, libdb v.1 is assumed. Now Sleepycat has libdb v.3, and on RH7 it appears you can have all three versions installed at once. I don't yet know if bsddbmodule.c can be built/linked with v.3 (seems likely, since db_185.h still existts), but even if it can, configure will have to grovel around in db.h looking for DB_VERSION_MAJOR. If it doesn't exist, we have v.1. If it does exist, its value will determine what version > 1 we have. I imagine for an autoconf whiz this will be a simple task, but it's more of a challenge than I have time for at the moment. Anyone want to take this on? ------------------------------------------------------- Date: 2000-Oct-23 18:13 By: fleury Comment: Well, I also tried at home, where I have a vanilla RH7.0 and it compiles perfectly. The reported bug was on a RH6.2->RH7.0 upgraded machine. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=117464&group_id=5470 From noreply@sourceforge.net Sat Jan 20 16:56:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 20 Jan 2001 08:56:27 -0800 Subject: [Python-bugs-list] [Bug #129475] How to validate a text box using Python Message-ID: Bug #129475, was updated on 2001-Jan-20 05:03 Here is a current snapshot of the bug. Project: Python Category: demos and tools Status: Closed Resolution: Invalid Bug Group: Not a Bug Priority: 5 Submitted by: nobody Assigned to : gvanrossum Summary: How to validate a text box using Python Details: Please tell me how to validate a text box using python Follow-Ups: Date: 2001-Jan-20 08:56 By: gvanrossum Comment: This is not a bug. Please mail questions to help@python.org. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129475&group_id=5470 From noreply@sourceforge.net Sun Jan 21 03:41:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 20 Jan 2001 19:41:07 -0800 Subject: [Python-bugs-list] [Bug #128475] mimetools.encode (sometimes) fails when called from a thread Message-ID: Bug #128475, was updated on 2001-Jan-11 11:05 Here is a current snapshot of the bug. Project: Python Category: Threads Status: Closed Resolution: Fixed Bug Group: None Priority: 7 Submitted by: nobody Assigned to : tim_one Summary: mimetools.encode (sometimes) fails when called from a thread Details: I used this script to test. The code of filesender.prepare_msgs is at the end of the report. ## import threading import filesender file = open('c:/windows/desktop/mp3/Aphex Twin - Bucephalus Bouncing Ball.mp3', 'rb') t1 = threading.Thread(target=filesender.prepare_msgs, args=(file,'a@b.c')) from cStringIO import StringIO data = StringIO() import mimetools t2=threading.Thread(target=mimetools.encode, args=(file,data,'base64')) import sys if '-t1' in sys.argv: t1.start() elif '-t2' in sys.argv: t2.start() else: filesender.prepare_msgs(file, 'a@b.c') ## Results of running it with -t1, -t2, and no options, on Windows: C:\Python20>python test.py -t1 preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 Fatal Python error: Interpreter not initialized (version mismatch?) abnormal program termination C:\Python20>python test.py -t1 preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 Fatal Python error: Interpreter not initialized (version mismatch?) abnormal program termination C:\Python20>python test.py -t2 Fatal Python error: Interpreter not initialized (version mismatch?) abnormal program termination C:\Python20>python test.py -t2 C:\Python20>python test.py preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 encoded got value data length is 7807732 Encoded Aphex Twin - Bucephalus Bouncing Ball.mp3 is too large, splitting into 2 parts C:\Python20>python test.py preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 encoded got value data length is 7807732 Encoded Aphex Twin - Bucephalus Bouncing Ball.mp3 is too large, splitting into 2 parts On Linux: wolfson@senator:~% python test.py preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 encoded got value data length is 7807732 Encoded Aphex Twin - Bucephalus Bouncing Ball.mp3 is too large, splitting into 2 p arts wolfson@senator:~% python test.py -t1 preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 Fatal Python error: Interpreter not initialized (version mismatch?) Abort wolfson@senator:~% python test.py -t1 preparing Aphex Twin - Bucephalus Bouncing Ball.mp3 Fatal Python error: Interpreter not initialized (version mismatch?) Abort wolfson@senator:~% python test.py -t2 Fatal Python error: Interpreter not initialized (version mismatch?) Abort wolfson@senator:~% python test.py -t2 Fatal Python error: Interpreter not initialized (version mismatch?) Abort wolfson@senator:~% python test.py -t2 Fatal Python error: Interpreter not initialized (version mismatch?) Abort On Sun 5 it seems to always succeed. The code for filesender.prepare_msgs: def prepare_msgs(file, addressee): data = StringIO.StringIO() fn = getname(file) print 'preparing %s' % fn mimetools.encode(file, data, 'base64') print 'encoded' data = data.getvalue() print 'got value' datalen = len(data) print 'data length is %d' % datalen if datalen > MAX_MSG_SZ: numsplits = 1 + datalen / MAX_MSG_SZ print 'Encoded %s is too large, splitting into %d parts' % (fn,numsplits) msgs = [] for i in range(numsplits): thismsg, data = data[:MAX_MSG_SZ], data[MAX_MSG_SZ:] msgs.append(fmt_message(fn, addressee, thismsg, '(%d/%d)' % (i+1, numsplits), MSG)) return msgs return [fmt_message(fn, addressee, data, '', MSG)] Follow-Ups: Date: 2001-Jan-20 19:41 By: tim_one Comment: Guido diagnosed the problem: a race between the main thread shutting down, and the spawned thread importing a C module that checked to see whether the interpreter was still initialized. In fact the interpreter is still reliably intact, but the "is initialized?" flag was getting cleared too early. Fixed in pythonrun.c rev 2.119 and atexit.py rev 1.4. ------------------------------------------------------- Date: 2001-Jan-19 21:21 By: tim_one Comment: Guido, I'm assuming that means you were able to get the small program to fail under Linux too. Under that assumption, I reassigned back to me. ------------------------------------------------------- Date: 2001-Jan-19 15:10 By: gvanrossum Comment: I'm pretty sure it's because mimetools.encode imports base64, and doing that in the thread somehow screws things up. I'll look into it more later -- or Tim can aim his debugger at it (I won't get to this before the 2.1a1 release I'm afraid). ------------------------------------------------------- Date: 2001-Jan-19 15:04 By: gvanrossum Comment: Yes, fails for me too on Linux. ------------------------------------------------------- Date: 2001-Jan-19 01:58 By: tim_one Comment: Guido, I took this out of the Platform-specific group because his/her test output shows the same failures on both Windows and Linux. I assume it works on Sun5 for him because you have to kick a Sun OS in the groin to make it switch threads. [Later: Also assigned to you so that you can try the tiny program below on Linux] [Later: boosted the priority too] Anonymous submitter, sorry, but this bug report is too confusing to make head or tail of. Could you please whittle this down to a self-contained, failing program that can be executed? As is, you're showing us both code that works (which isn't interesting) and code that doesn't (which is), and none of it can be executed anyway (e.g., MAX_MSG_SZ isn't defined, getname isn't defined, fmt_message isn't defined, ...). Later: like this: BIGFILE = "pcbuild.opt" # OK, it's not really big import threading, mimetools from cStringIO import StringIO file1 = open(BIGFILE, 'rb') data1 = StringIO() t1 = threading.Thread(target=mimetools.encode, args=(file1, data1, 'base64')) t1.start() Guido, that fails for me about 1 time in 5 under Win98SE, current CVS Python, like so: C:\Code\python\dist\src\PCbuild>python tran.py Fatal Python error: Interpreter not initialized (version mismatch?) abnormal program termination C:\Code\python\dist\src\PCbuild> In the debug build it craps out (with about the same frequency) in kernel32.dll (the secret bowels of Windows, which usually means running under the debugger is futile; but I'll try that anyway when I get up again). ------------------------------------------------------- Date: 2001-Jan-15 11:54 By: gvanrossum Comment: I'm assigning this to Tim, our all-purpose Windows cleaner. :-) Thread problems like this are notoriously hard to find, so don't hold your breath. Sorry! Setting the group to platform-specific since you mention it works fine on Sun5. ------------------------------------------------------- Date: 2001-Jan-13 08:13 By: nobody Comment: I'll get you! ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128475&group_id=5470 From noreply@sourceforge.net Sun Jan 21 07:20:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 20 Jan 2001 23:20:12 -0800 Subject: [Python-bugs-list] [Bug #125673] PyThreadState_Delete: invalid tstate (Unix only?) Message-ID: Bug #125673, was updated on 2000-Dec-13 08:25 Here is a current snapshot of the bug. Project: Python Category: Threads Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: gvanrossum Assigned to : gvanrossum Summary: PyThreadState_Delete: invalid tstate (Unix only?) Details: I am working on a simple couroutine/generator package using threads, to prototype the API. It seems to be working fine, except it is exposing a hard-to-find bug in the threadstate code. The following script[*] contains the API implementation and a simple example based on Tim's "fringe()" code. When I run the example, I *sometimes* get: Segmentation fault but *sometimes* I get: Fatal Python error: PyThreadState_Delete: invalid tstate Aborted and *sometimes* it succeeds. If I uncomment the raw_input("Exit?") line at the end I never get an error. The error behavior seems very fickle: making almost arbitrary changes to the code can trigger it or make it go away. When I run it under gdb, I cannot reproduce the problen, ever. (Haven't I heard this before?) The only clue is the fatal error message: it seems to be a race condition at thread termination. But how to debug this? _____ [*] I'm not including the script here. I can mail it to interested parties though. For my own reference: Subject: [Pycabal] Mysterious thread bug To: Date: Thu, 16 Nov 2000 16:21:12 -0500 Follow-Ups: Date: 2001-Jan-20 23:20 By: tim_one Comment: Guido, since we just fixed *a* thread termination problem (premature clearing of "initialized" in pythonrun.c), and I've never seen this fail on Windows, reassigning to you to see whether-- however unlikely it may seem --this problem has gone away by magic now. ------------------------------------------------------- Date: 2000-Dec-13 08:51 By: tim_one Comment: I was never able to provoke a problem on Windows using Guido's script, so changed Group to Platform-specific and added "(Linux only?)" to Summary. Here's the script; assigned to Greg under the hope he can provoke a problem: import thread class EarlyExit(Exception): pass class main_coroutine: def __init__(self): self.id = 0 self.caller = None self.value = None self.lock = thread.allocate_lock() self.lock.acquire() self.done = 0 def __call__(self, value=None): cur = current() assert cur is not self self.caller = cur self.value = value self.lock.release() cur.lock.acquire() if self.done: raise EarlyExit return cur.value all_coroutines = {thread.get_ident(): main_coroutine()} def current(): return all_coroutines[thread.get_ident()] def suspend(value=None): cur = current() caller = cur.caller assert caller and caller is not cur caller.value = value caller.lock.release() cur.lock.acquire() return cur.value nextid = 1 class coroutine(main_coroutine): def __init__(self, func, *args): global nextid self.id = nextid nextid = nextid + 1 self.caller = current() boot = thread.allocate_lock() boot.acquire() thread.start_new_thread(self.run, (boot, func, args)) boot.acquire() def run(self, boot, func, args): me = thread.get_ident() all_coroutines[me] = self self.lock = thread.allocate_lock() self.lock.acquire() self.done = 0 boot.release() self.lock.acquire() if self.value: print "Warning: initial value %s ignored" % `value` try: apply(func, args) finally: del all_coroutines[me] self.done = 1 self.caller.lock.release() def fringe(list): tl = type(list) for item in list: if type(item) is tl: fringe(item) else: suspend(item) def printinorder(list): c = coroutine(fringe, list) try: while 1: print c(), except EarlyExit: pass print if __name__ == '__main__': printinorder([1,2,3]) l = [1,2,[3,4,[5],6]] printinorder(l) #raw_input("Exit?") ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=125673&group_id=5470 From noreply@sourceforge.net Sun Jan 21 09:26:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 21 Jan 2001 01:26:30 -0800 Subject: [Python-bugs-list] [Bug #125673] PyThreadState_Delete: invalid tstate (Unix only?) Message-ID: Bug #125673, was updated on 2000-Dec-13 08:25 Here is a current snapshot of the bug. Project: Python Category: Threads Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: gvanrossum Assigned to : gvanrossum Summary: PyThreadState_Delete: invalid tstate (Unix only?) Details: I am working on a simple couroutine/generator package using threads, to prototype the API. It seems to be working fine, except it is exposing a hard-to-find bug in the threadstate code. The following script[*] contains the API implementation and a simple example based on Tim's "fringe()" code. When I run the example, I *sometimes* get: Segmentation fault but *sometimes* I get: Fatal Python error: PyThreadState_Delete: invalid tstate Aborted and *sometimes* it succeeds. If I uncomment the raw_input("Exit?") line at the end I never get an error. The error behavior seems very fickle: making almost arbitrary changes to the code can trigger it or make it go away. When I run it under gdb, I cannot reproduce the problen, ever. (Haven't I heard this before?) The only clue is the fatal error message: it seems to be a race condition at thread termination. But how to debug this? _____ [*] I'm not including the script here. I can mail it to interested parties though. For my own reference: Subject: [Pycabal] Mysterious thread bug To: Date: Thu, 16 Nov 2000 16:21:12 -0500 Follow-Ups: Date: 2001-Jan-21 01:26 By: tim_one Comment: Let's pretend: threadmodule.c/t_bootstrap finishes running the user's spawned-thread code, PyEval_ReleaseThread(tstate) releases the global lock, then PyThreadState_Delete(tstate) is called to unlink tstate from the tstate->interp->tstate_head chain. But the thread swaps out at that point, and the main thread resumes executing. It's got nothing left to do, so it gets into pythonrun.c/Py_Finalize() quickly, and soon enough calls PyInterpreterState_Delete(interp) from there. That calls zapthreads(). zapthreads calls PyThreadState_Delete(ts) on *every* threadstate ts in the interp->tstate_head chain. If you're with me so far, the other thread still hasn't called PyThreadState_Delete on *its* threadstate, and the comment in zapthreads is semi-prophetic : /* No need to lock the mutex here because this should only happen when the threads are all really dead (XXX famous last words). */ But the problem is not that the mutex isn't locked, it's that the other thread is still going to try deleting its tstate again *later* (the precise cause of an "invalid tstate" error msg): other threads aren't really dead, and AFAICT there's actually no reason to believe they *should* be dead at this point (other than luck). Anyway, if this is right, we have two threads battling over who's going to delete a single tstate, and if the main thread gets in first, the other thread is certain to raise an error (except that, at least on Windows, if the main thread manages to exit before the other thread gets that far, the other thread will be killed off quietly in mid-stream by the OS; since Linux threads seem to be indistinguishable from Linux processes, I bet they run some pthreads emulation layer in user space that *may* take a fair amount of time to kill off child threads when the parent goes away). Waddya think? Explains everything and solves nothing . ------------------------------------------------------- Date: 2001-Jan-20 23:20 By: tim_one Comment: Guido, since we just fixed *a* thread termination problem (premature clearing of "initialized" in pythonrun.c), and I've never seen this fail on Windows, reassigning to you to see whether-- however unlikely it may seem --this problem has gone away by magic now. ------------------------------------------------------- Date: 2000-Dec-13 08:51 By: tim_one Comment: I was never able to provoke a problem on Windows using Guido's script, so changed Group to Platform-specific and added "(Linux only?)" to Summary. Here's the script; assigned to Greg under the hope he can provoke a problem: import thread class EarlyExit(Exception): pass class main_coroutine: def __init__(self): self.id = 0 self.caller = None self.value = None self.lock = thread.allocate_lock() self.lock.acquire() self.done = 0 def __call__(self, value=None): cur = current() assert cur is not self self.caller = cur self.value = value self.lock.release() cur.lock.acquire() if self.done: raise EarlyExit return cur.value all_coroutines = {thread.get_ident(): main_coroutine()} def current(): return all_coroutines[thread.get_ident()] def suspend(value=None): cur = current() caller = cur.caller assert caller and caller is not cur caller.value = value caller.lock.release() cur.lock.acquire() return cur.value nextid = 1 class coroutine(main_coroutine): def __init__(self, func, *args): global nextid self.id = nextid nextid = nextid + 1 self.caller = current() boot = thread.allocate_lock() boot.acquire() thread.start_new_thread(self.run, (boot, func, args)) boot.acquire() def run(self, boot, func, args): me = thread.get_ident() all_coroutines[me] = self self.lock = thread.allocate_lock() self.lock.acquire() self.done = 0 boot.release() self.lock.acquire() if self.value: print "Warning: initial value %s ignored" % `value` try: apply(func, args) finally: del all_coroutines[me] self.done = 1 self.caller.lock.release() def fringe(list): tl = type(list) for item in list: if type(item) is tl: fringe(item) else: suspend(item) def printinorder(list): c = coroutine(fringe, list) try: while 1: print c(), except EarlyExit: pass print if __name__ == '__main__': printinorder([1,2,3]) l = [1,2,[3,4,[5],6]] printinorder(l) #raw_input("Exit?") ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=125673&group_id=5470 From noreply@sourceforge.net Sun Jan 21 12:48:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 21 Jan 2001 04:48:48 -0800 Subject: [Python-bugs-list] [Bug #129584] pythonpath registry value ignored in 2.0 Message-ID: Bug #129584, was updated on 2001-Jan-21 04:48 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: esasaki Assigned to : nobody Summary: pythonpath registry value ignored in 2.0 Details: The value of the HKLM\software\python\pythoncore\2.0\pythonpath key is now ignored in Python 2.0 unless you have at least one subkey underneath it. Since the default installation program doesn't add any subkeys, users familiar with 1.5.2 who expect to just set pythonpath in the registry will be disappointed. I imagine that you all probably run with other extensions installed that add subkeys under pythonpath and thus never see this bug. However, the first thing I did after installing 2.0 was to try to point to my custom libs. 5 hours later I can finally start testing to see if they still work :). This problem is undoubtedly related to bug 127722. Fix that and you'll fix this one. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129584&group_id=5470 From noreply@sourceforge.net Sun Jan 21 18:41:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 21 Jan 2001 10:41:02 -0800 Subject: [Python-bugs-list] [Bug #129584] pythonpath registry value ignored in 2.0 Message-ID: Bug #129584, was updated on 2001-Jan-21 04:48 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: esasaki Assigned to : mhammond Summary: pythonpath registry value ignored in 2.0 Details: The value of the HKLM\software\python\pythoncore\2.0\pythonpath key is now ignored in Python 2.0 unless you have at least one subkey underneath it. Since the default installation program doesn't add any subkeys, users familiar with 1.5.2 who expect to just set pythonpath in the registry will be disappointed. I imagine that you all probably run with other extensions installed that add subkeys under pythonpath and thus never see this bug. However, the first thing I did after installing 2.0 was to try to point to my custom libs. 5 hours later I can finally start testing to see if they still work :). This problem is undoubtedly related to bug 127722. Fix that and you'll fix this one. Follow-Ups: Date: 2001-Jan-21 10:41 By: tim_one Comment: Mark? You know more about this than everyone else combined. Is that good news or bad ? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129584&group_id=5470 From noreply@sourceforge.net Sun Jan 21 18:53:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 21 Jan 2001 10:53:46 -0800 Subject: [Python-bugs-list] [Bug #129417] Negative numbers are grouped incorrectly Message-ID: Bug #129417, was updated on 2001-Jan-19 13:00 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: nobody Assigned to : nobody Summary: Negative numbers are grouped incorrectly Details: >>> import locale >>> locale.setlocale(locale.LC_ALL,'') 'en' >>> print locale.format("%.2f", -100, 1) -,100.00 Linux 2.4.0 on Mandrake Linux 7.2, PIII-866. Hmmm. The problem is in locale.py. The (very simplistic) algorithm to add grouping characters only works for positive numbers. It can be re-written as: def format(f,val,grouping=0): """Formats a value in the same way that the % formatting would use, but takes the current locale into account. Grouping is applied if the third parameter is true.""" result = f % val fields = string.split(result, ".") if grouping: fields[0]=_group(fields[0]) if len(fields)==2: res = fields[0]+localeconv()['decimal_point']+fields[1] elif len(fields)==1: res = fields[0] else: raise Error, "Too many decimal points in result string" if val < 0: return '-'+res else: return res -Kevin Jacobs (jacobs@theopalgroup.com) Follow-Ups: Date: 2001-Jan-21 10:53 By: loewis Comment: Suggested fix applied in 1.12 of locale.py. ------------------------------------------------------- Date: 2001-Jan-19 16:15 By: nobody Comment: Oops. That will teach me to cut-and-paste without looking. result = f % val should be result = f % abs(val) -Kevin ------------------------------------------------------- Date: 2001-Jan-19 15:01 By: gvanrossum Comment: Martin, didn't you write that code originally? If you agree with the fix, just check it in. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129417&group_id=5470 From noreply@sourceforge.net Mon Jan 22 01:46:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 21 Jan 2001 17:46:41 -0800 Subject: [Python-bugs-list] [Bug #129626] Size command broken? Message-ID: Bug #129626, was updated on 2001-Jan-21 17:46 Here is a current snapshot of the bug. Project: Python Category: Regular Expressions Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : nobody Summary: Size command broken? Details: I have been attempting to use the tell() and size() commands to detect an EOF in a c datafile I am trying to load. They appear to have the same format...f.tell() and f.size() tell seems to be working fine, but size gives an attribut error when I try to get the file size out of it. ..as in print f.size() I admit I am new to using Python, but I have spent much time trying to get size to work, and it doesn't... jrduchek@primary.net For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129626&group_id=5470 From noreply@sourceforge.net Mon Jan 22 01:55:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 21 Jan 2001 17:55:48 -0800 Subject: [Python-bugs-list] [Bug #129626] Size command broken? Message-ID: Bug #129626, was updated on 2001-Jan-21 17:46 Here is a current snapshot of the bug. Project: Python Category: Extension Modules Status: Closed Resolution: Invalid Bug Group: Not a Bug Priority: 5 Submitted by: nobody Assigned to : nobody Summary: Size command broken? Details: I have been attempting to use the tell() and size() commands to detect an EOF in a c datafile I am trying to load. They appear to have the same format...f.tell() and f.size() tell seems to be working fine, but size gives an attribut error when I try to get the file size out of it. ..as in print f.size() I admit I am new to using Python, but I have spent much time trying to get size to work, and it doesn't... jrduchek@primary.net Follow-Ups: Date: 2001-Jan-21 17:55 By: tim_one Comment: Python file objects don't have a .size() method, and I have no idea why you think they do. If you want to know the size of a file, use the function os.path.getsize(). For newbie questions (which are welcome!), try the Tutor list or the newsgroup comp.lang.python; the bug database is for bugs. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129626&group_id=5470 From noreply@sourceforge.net Mon Jan 22 08:36:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 00:36:05 -0800 Subject: [Python-bugs-list] [Bug #129651] documentation error in 2.0, section 11.4.2 (httplib example) Message-ID: Bug #129651, was updated on 2001-Jan-22 00:36 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: gaul Assigned to : nobody Summary: documentation error in 2.0, section 11.4.2 (httplib example) Details: In section 11.4.2 (httplib examples), the second example is incorrect. Several variables (paramstring, errcode) are used but not defined. The proper sample code follows: >>> import httplib, urllib >>> params = urllib.urlencode({'spam': 1, 'eggs': 2, 'bacon': 0}) >>> h = httplib.HTTP("www.musi-cal.com:80") >>> h.putrequest("POST", "/cgi-bin/query") >>> h.putheader("Content-length", "%d" % len(params)) >>> h.putheader('Accept', 'text/plain') >>> h.putheader('Host', 'www.musi-cal.com') >>> h.endheaders() >>> h.send(params) >>> errcode, msg, hdrs = h.getreply() >>> print errcode # should be 200 >>> data = h.getfile().read() # get the raw HTML The lines changed are: h.send(paramstring) -> h.send(params) reply, msg, hdrs = h.getreply() -> errcode, msg, hdrs = h.getreply() For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129651&group_id=5470 From noreply@sourceforge.net Mon Jan 22 10:17:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 02:17:04 -0800 Subject: [Python-bugs-list] [Bug #129661] library-dirs option in setup.cfg crashes distutils Message-ID: Bug #129661, was updated on 2001-Jan-22 02:16 Here is a current snapshot of the bug. Project: Python Category: Distutils Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: larsga Assigned to : nobody Summary: library-dirs option in setup.cfg crashes distutils Details: When I set library-dirs = /usr/src/own/sp-1.3.4/lib under [build_ext] in my setup.cfg file, I get a traceback from distutils that looks like this: [larsga@localhost pysp]$ python setup.py build running build running build_ext building 'pysp' extension skipping pyspmodule.cxx (build/temp.linux-i686-2.0/pyspmodule.o up-to-date) Traceback (most recent call last): File "setup.py", line 14, in ? license = "BSD-like") File "/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/core.py", line 138, in setup File "/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/dist.py", line 829, in run_commands File "/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/dist.py", line 849, in run_command File "/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/command/build.py", line 106, in run File "/usr/local/lib/python2.0/cmd.py", line 328, in run_command print "\n" File "/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/dist.py", line 849, in run_command File "/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/command/build_ext.py", line 225, in run File "/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/command/build_ext.py", line 441, in build_extensions File "/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/ccompiler.py", line 662, in link_shared_object File "/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/unixccompiler.py", line 208, in link File "/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/ccompiler.py", line 430, in _fix_lib_args TypeError: can only concatenate list (not "string") to list If I remove the option, my extension won't build, because gcc can't find the needed library. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129661&group_id=5470 From noreply@sourceforge.net Mon Jan 22 15:27:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 07:27:57 -0800 Subject: [Python-bugs-list] [Bug #129651] documentation error in 2.0, section 11.4.2 (httplib example) Message-ID: Bug #129651, was updated on 2001-Jan-22 00:36 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: gaul Assigned to : fdrake Summary: documentation error in 2.0, section 11.4.2 (httplib example) Details: In section 11.4.2 (httplib examples), the second example is incorrect. Several variables (paramstring, errcode) are used but not defined. The proper sample code follows: >>> import httplib, urllib >>> params = urllib.urlencode({'spam': 1, 'eggs': 2, 'bacon': 0}) >>> h = httplib.HTTP("www.musi-cal.com:80") >>> h.putrequest("POST", "/cgi-bin/query") >>> h.putheader("Content-length", "%d" % len(params)) >>> h.putheader('Accept', 'text/plain') >>> h.putheader('Host', 'www.musi-cal.com') >>> h.endheaders() >>> h.send(params) >>> errcode, msg, hdrs = h.getreply() >>> print errcode # should be 200 >>> data = h.getfile().read() # get the raw HTML The lines changed are: h.send(paramstring) -> h.send(params) reply, msg, hdrs = h.getreply() -> errcode, msg, hdrs = h.getreply() For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129651&group_id=5470 From noreply@sourceforge.net Mon Jan 22 15:40:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 07:40:37 -0800 Subject: [Python-bugs-list] [Bug #129683] test___all__ expects all referenced modules to exist Message-ID: Bug #129683, was updated on 2001-Jan-22 07:40 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: jackjansen Assigned to : nobody Summary: test___all__ expects all referenced modules to exist Details: Test___all__ expects that all the modules it knows about exist and are importable. This isn't always true: if bsddb isn't available on the platform then dbhash can't be imported. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129683&group_id=5470 From noreply@sourceforge.net Mon Jan 22 15:42:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 07:42:53 -0800 Subject: [Python-bugs-list] [Bug #129661] library-dirs option in setup.cfg crashes distutils Message-ID: Bug #129661, was updated on 2001-Jan-22 02:16 Here is a current snapshot of the bug. Project: Python Category: Distutils Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: larsga Assigned to : akuchling Summary: library-dirs option in setup.cfg crashes distutils Details: When I set library-dirs = /usr/src/own/sp-1.3.4/lib under [build_ext] in my setup.cfg file, I get a traceback from distutils that looks like this: [larsga@localhost pysp]$ python setup.py build running build running build_ext building 'pysp' extension skipping pyspmodule.cxx (build/temp.linux-i686-2.0/pyspmodule.o up-to-date) Traceback (most recent call last): File "setup.py", line 14, in ? license = "BSD-like") File "/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/core.py", line 138, in setup File "/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/dist.py", line 829, in run_commands File "/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/dist.py", line 849, in run_command File "/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/command/build.py", line 106, in run File "/usr/local/lib/python2.0/cmd.py", line 328, in run_command print "\n" File "/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/dist.py", line 849, in run_command File "/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/command/build_ext.py", line 225, in run File "/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/command/build_ext.py", line 441, in build_extensions File "/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/ccompiler.py", line 662, in link_shared_object File "/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/unixccompiler.py", line 208, in link File "/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/ccompiler.py", line 430, in _fix_lib_args TypeError: can only concatenate list (not "string") to list If I remove the option, my extension won't build, because gcc can't find the needed library. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129661&group_id=5470 From noreply@sourceforge.net Mon Jan 22 15:54:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 07:54:42 -0800 Subject: [Python-bugs-list] [Bug #129651] documentation error in 2.0, section 11.4.2 (httplib example) Message-ID: Bug #129651, was updated on 2001-Jan-22 00:36 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: gaul Assigned to : fdrake Summary: documentation error in 2.0, section 11.4.2 (httplib example) Details: In section 11.4.2 (httplib examples), the second example is incorrect. Several variables (paramstring, errcode) are used but not defined. The proper sample code follows: >>> import httplib, urllib >>> params = urllib.urlencode({'spam': 1, 'eggs': 2, 'bacon': 0}) >>> h = httplib.HTTP("www.musi-cal.com:80") >>> h.putrequest("POST", "/cgi-bin/query") >>> h.putheader("Content-length", "%d" % len(params)) >>> h.putheader('Accept', 'text/plain') >>> h.putheader('Host', 'www.musi-cal.com') >>> h.endheaders() >>> h.send(params) >>> errcode, msg, hdrs = h.getreply() >>> print errcode # should be 200 >>> data = h.getfile().read() # get the raw HTML The lines changed are: h.send(paramstring) -> h.send(params) reply, msg, hdrs = h.getreply() -> errcode, msg, hdrs = h.getreply() Follow-Ups: Date: 2001-Jan-22 07:54 By: fdrake Comment: Already fixed in CVS using a similar patch. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129651&group_id=5470 From noreply@sourceforge.net Mon Jan 22 16:04:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 08:04:54 -0800 Subject: [Python-bugs-list] [Bug #123599] Need user-centered info for Windows users. Message-ID: Bug #123599, was updated on 2000-Nov-27 08:31 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: Feature Request Priority: 6 Submitted by: fdrake Assigned to : fdrake Summary: Need user-centered info for Windows users. Details: Users ask questions like "How do I write batch files using Python?"; there should be a document that acts as a user's guide specifically for Windows users. This could be similar to what the Macintosh Modules Reference is becoming. This should be part of the standard documentation and could acquire the Windows module documentation. Follow-Ups: Date: 2001-Jan-22 08:04 By: fdrake Comment: Another question that should be answered in this document: "How do I create/recall modules?" This one comes up most with first time programmers and users from environments that don't expose source code as editable text files (VB?). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=123599&group_id=5470 From noreply@sourceforge.net Mon Jan 22 16:34:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 08:34:50 -0800 Subject: [Python-bugs-list] [Bug #129692] \seepep{} not corect in HTML translation Message-ID: Bug #129692, was updated on 2001-Jan-22 08:34 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: akuchling Assigned to : nobody Summary: \seepep{} not corect in HTML translation Details: The Perl code generates an incorrect URL for PEPs in the \seepep{} command in the {seealso}; the URL for PEP 230 is http://www.ietf.org/rfc/rfc230.txt. Seems to be a simple oversight... Note that the \pep command is correct. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129692&group_id=5470 From noreply@sourceforge.net Mon Jan 22 16:45:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 08:45:20 -0800 Subject: [Python-bugs-list] [Bug #129692] \seepep{} not correct in HTML translation Message-ID: Bug #129692, was updated on 2001-Jan-22 08:34 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: akuchling Assigned to : fdrake Summary: \seepep{} not correct in HTML translation Details: The Perl code generates an incorrect URL for PEPs in the \seepep{} command in the {seealso}; the URL for PEP 230 is http://www.ietf.org/rfc/rfc230.txt. Seems to be a simple oversight... Note that the \pep command is correct. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129692&group_id=5470 From noreply@sourceforge.net Mon Jan 22 17:34:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 09:34:58 -0800 Subject: [Python-bugs-list] [Bug #116008] Subsection Hypertext Links are broken in HTML Docs Message-ID: Bug #116008, was updated on 2000-Oct-04 07:33 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: pefu Assigned to : fdrake Summary: Subsection Hypertext Links are broken in HTML Docs Details: For example load ftp://python.beopen.com/pub/docco/devel/tut/node3.html into your favorite HTML browser and click on the link labeled "1.1 Where >From Here". It doesn't work as it used to work before in the 1.5.2 docs. Unfortunately I can't tell which change to the latex2html engine broke this. Follow-Ups: Date: 2001-Jan-22 09:34 By: fdrake Comment: Work-around from Anthon van der Neut checked in Doc/perl/python.perl revision 1.94. ------------------------------------------------------- Date: 2000-Dec-24 08:40 By: anthon Comment: This is stil broken, and not caused by latex2html. If you render the HTML without the python specific initialisation it works fine. The problem seems to be in Doc/perl/python.perl. As anchor_invisible_mark is set to emtpy string the gets optimized away. Setting it to   (the change comes on a newline before a
, you don't see it) seems to take away the problem. A solution would be to not optimize empty structs away if they are . Since I now little PERL, I had no clue where to start for that. ------------------------------------------------------- Date: 2000-Dec-12 13:12 By: gvanrossum Comment: Is this still broken, Fred? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=116008&group_id=5470 From noreply@sourceforge.net Mon Jan 22 17:36:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 09:36:23 -0800 Subject: [Python-bugs-list] [Bug #129692] \seepep{} not correct in HTML translation Message-ID: Bug #129692, was updated on 2001-Jan-22 08:34 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: akuchling Assigned to : fdrake Summary: \seepep{} not correct in HTML translation Details: The Perl code generates an incorrect URL for PEPs in the \seepep{} command in the {seealso}; the URL for PEP 230 is http://www.ietf.org/rfc/rfc230.txt. Seems to be a simple oversight... Note that the \pep command is correct. Follow-Ups: Date: 2001-Jan-22 09:36 By: fdrake Comment: Fixed in Doc/perl/python.perl revision 1.94. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129692&group_id=5470 From noreply@sourceforge.net Mon Jan 22 18:19:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 10:19:29 -0800 Subject: [Python-bugs-list] [Bug #125919] docs for random, whrandom too complex Message-ID: Bug #125919, was updated on 2000-Dec-15 11:02 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Closed Resolution: Fixed Bug Group: None Priority: 7 Submitted by: tim_one Assigned to : fdrake Summary: docs for random, whrandom too complex Details: From the docstring: """ x, random=random.random -> shuffle list x in place; return None. Optional arg random is a 0-argument function returning a random float in [0.0, 1.0); by default, the standard random.random. Note that for even rather small len(x), the total number of permutations of x is larger than the period of most random number generators; this implies that "most" permutations of a long sequence can never be generated. """ I would have added this myself to the docs, but don't understand the structure of the docs; e.g., I always thought whrandom was an internal implementation detail for random that wasn't meant to be exposed on its own, and the "Random Number Generator Interface" appears to be a half-baked Grand Generalization that was abandoned the day after it got dreamt up. Suggest the docs in this area would be much clearer if they documented the random module on its own, and dropped the sections on whrandom and the RNGI. Python's randomization facilities are too meager to merit so much complexity. Follow-Ups: Date: 2001-Jan-22 10:19 By: fdrake Comment: Fixed in Doc/lib/librandom.tex revision 1.16. ------------------------------------------------------- Date: 2001-Jan-15 19:35 By: tim_one Comment: No, the docs mean [0,1). People differ as to whether they favor [0,1) or (0,1), but Python picked [0,1) a long time ago. Doesn't mean you're ever going to see a 0, but does mean it won't be considered a bug if you do see one. Python's implementation of Wichmann-Hill actually ends with a mod operation, so a 0 return isn't impossible "in theory" (although on machines using proper IEEE-754 double arithmetic, I don't believe the hardware can actually generate a 0 from the sequence of operations Python performs). ------------------------------------------------------- Date: 2001-Jan-15 18:52 By: randrews Comment: Possible related typo from Python Library Reference section 5.3.1 on The Random Number Generator Interface: random () Returns the next random floating point number in the range [0.0 ... 1.0). Should the range read (0.0 ... 1.0) instead of [0.0 ... 1.0)? ------------------------------------------------------- Date: 2000-Dec-15 11:16 By: fdrake Comment: random.shuffle() was documented before I got the bug notice for this one! Your other comments still need to be dealt with, so I'll leave this open, but re-title it. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=125919&group_id=5470 From noreply@sourceforge.net Mon Jan 22 18:38:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 10:38:42 -0800 Subject: [Python-bugs-list] [Bug #125880] TeX source found in PDF contents list Message-ID: Bug #125880, was updated on 2000-Dec-15 02:07 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: nobody Assigned to : fdrake Summary: TeX source found in PDF contents list Details: Hello there The 'ext.pdf' document for 2.0 I downloaded from python.org Has some TeX source spilling out in the contents window. Section 1.9 says The Pyprotect unhbox voidb @x kern... instead of 'The Py_BuildValue() Function' (It's OK in the main window title) Regards Jon Nicoll (jkn@nicorp.f9.co.uk) Follow-Ups: Date: 2001-Jan-22 10:38 By: fdrake Comment: Worked around by changing three section titles in Doc/ext/ext.tex revision 1.90. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=125880&group_id=5470 From noreply@sourceforge.net Mon Jan 22 20:43:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 12:43:09 -0800 Subject: [Python-bugs-list] [Bug #129718] file locking lossage Message-ID: Bug #129718, was updated on 2001-Jan-22 12:43 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : nobody Summary: file locking lossage Details: (reference: http://www.erlenstar.demon.co.uk/unix/faq_3.html#SEC35) there are 4 ways to lock a file in unix. fcntl, lockf, flock and dotlocking. the only portable ways are fcntl and dotfiles. dotlocking is more nfs-resistant. (actually the only reliable nfs-resistant way seems to be a combination. see eg. http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=43491) both fcntl and dotlock require magic incantations to implement. therefore it is desireable to include code to do this in the standard python library. there is only one module in the python distribution that implements dot-locking or fcntl() locking: the posixfile module. however, it is marked as obsolete(!) because someone misguidedly thinked the sysv lockf is more portable. this leads to a situation where the most sensible low-effort way to implement file locking is to either cut-n-paste code from the posixfile module, or to call an external program (such as lockfile(1) from the procmail package) to do it. -- Erno Kuusela erno@iki.fi For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129718&group_id=5470 From noreply@sourceforge.net Mon Jan 22 21:25:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 13:25:53 -0800 Subject: [Python-bugs-list] [Bug #129718] file locking lossage Message-ID: Bug #129718, was updated on 2001-Jan-22 12:43 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : nobody Summary: file locking lossage Details: (reference: http://www.erlenstar.demon.co.uk/unix/faq_3.html#SEC35) there are 4 ways to lock a file in unix. fcntl, lockf, flock and dotlocking. the only portable ways are fcntl and dotfiles. dotlocking is more nfs-resistant. (actually the only reliable nfs-resistant way seems to be a combination. see eg. http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=43491) both fcntl and dotlock require magic incantations to implement. therefore it is desireable to include code to do this in the standard python library. there is only one module in the python distribution that implements dot-locking or fcntl() locking: the posixfile module. however, it is marked as obsolete(!) because someone misguidedly thinked the sysv lockf is more portable. this leads to a situation where the most sensible low-effort way to implement file locking is to either cut-n-paste code from the posixfile module, or to call an external program (such as lockfile(1) from the procmail package) to do it. -- Erno Kuusela erno@iki.fi Follow-Ups: Date: 2001-Jan-22 13:25 By: nobody Comment: (i apologise for the irritated tone of the above report.) it apperas the approach used in posixfile is not so bullet-proof either. in addition of the layout of the flock struct being platform-dependent, it is also (at least on linux) dependent also of the compilation mode used. if python is compiled with a 64-bit file offsets, the start and len members can grow in size. so this would either need to be done in c code or the code should test for the file offset size (i don't know if it's possible to find this out in python code). -- erno ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129718&group_id=5470 From noreply@sourceforge.net Mon Jan 22 23:31:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 15:31:45 -0800 Subject: [Python-bugs-list] [Bug #124981] zlib decompress of sync-flushed data fails Message-ID: Bug #124981, was updated on 2000-Dec-07 23:25 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: abo Assigned to : akuchling Summary: zlib decompress of sync-flushed data fails Details: I'm not sure if this is just an undocumented limitation or a genuine bug. I'm using python 1.5.2 on winNT. A single decompress of a large amount (16K+) of compressed data that has been sync-flushed fails to produce all the data up to the sync-flush. The data remains inside the decompressor untill further compressed data or a final flush is issued. Note that the 'unused_data' attribute does not show that there is further data in the decompressor to process (it shows ''). A workaround is to decompress the data in smaller chunks. Note that compressing data in smaller chunks is not required, as the problem is in the decompressor, not the compressor. The following code demonstrates the problem, and raises an exception when the compressed data reaches 17K; from zlib import * from random import * # create compressor and decompressor c=compressobj(9) d=decompressobj() # try data sizes of 1-63K for l in range(1,64): # generate random data stream a='' for i in range(l*1024): a=a+chr(randint(0,255)) # compress, sync-flush, and decompress t=d.decompress(c.compress(a)+c.flush(Z_SYNC_FLUSH)) # if decompressed data is different to input data, barf, if len(t) != len(a): print len(a),len(t),len(d.unused_data) raise error Follow-Ups: Date: 2001-Jan-22 15:31 By: abo Comment: I've got a patch that I'm currently testing. When it's ready how do you want me to submit it; through the SF patch manager? I've analysed the code pretty extensively by now, and I believe I found a few other potential problems (though I haven't bothered to create test cases to trigger them). The original problem I found could affect compression as well as decompression. There were some memory allocations that didn't raise exceptions if they failed, and potential memory leaks when exceptions did occur. Also, deflateEnd would be called twice in a decompression object if it was flushed before it was destroyed. The strange thing is compression, decompression, and both flush routines perform basicly the same function, but they were all structured totally differently (like they had been written by different people). Also, there didn't seem to be any consistancy in the coding style so I didn't know what style to use. I tried to resist fixing more than the initial problem I identified, but in the end couldn't help myself. As an aside, I noticed that the 2.0 version of zlibmodule.c is Python 2.0 specific (It wouldn't work on my 1.5.2 system so I had to compile 2.0 to test my patch). How do you want me to submit my patch; one big patch, or several smaller ones for each fix? I have been using prcs to track my changes, but I have been a bit lax in checking in each small change, so creating seperate patches will take a little work. ------------------------------------------------------- Date: 2001-Jan-20 06:22 By: abo Comment: OK, Christmas is over, and I didn't really get a chance to look at it much. However, some preliminary testing of the zlib library suggests that it is _not_ in zlib. A c program that does the same compress/decompress of random data using steadily increasing block sizes does not show the same fault... I've noticed what might be a potential problem in the inflateInit2 call in PyZlib_decompressobj. The next_in and avail_in are not being initialized before it's called. The zlib manual says they should be init'ed because deflateInit will attempt to determine the compression method if it can. I'm not sure why this hasn't tripped already... does PyObject_New zero memory when it allocates things? I also think I've found the main problem... the PyZlib_objdecompress routine's main decompression loop thinks decompression is compelete when all available input has been processed. However, it is possible that all available input has been processed but there is more pending output. The code as it stands does correctly allocate more space when this occurs, but the loop terminates without calling inflate one more time. I'm putting together a patch tomorrow. Right now I'm going to bed... ------------------------------------------------------- Date: 2000-Dec-20 15:17 By: abo Comment: I have had a look at this in more detail (Python C interfacing is actually pretty easy :-). I dunno whether to go into details here, but I have noticed that inflate is being called with Z_NO_FLUSH when the zlib docs suggest Z_SYNC_FLUSH or Z_FINISH. However, the zlib implementation only treats Z_FINISH differently, so this should not make a difference (but it might in future versions of zlib). As you have said, .unused_data will only contain data if something is appended to a complete compressed object in the stream fed to a decompressor. Perhaps the docs need something to clarify this, perhaps in the form of an example? I am going to write some test progs to see if it's in zlib. At this stage I suspect that it is, and I'm hoping over christmas to get a patch done. ------------------------------------------------------- Date: 2000-Dec-19 11:48 By: akuchling Comment: .unused_data is really a red herring; the PyZlib_objdecompress() loops until zst->avail_in is zero, so .unused_data must always be zero by definition. (The attribute is there to support gzip-format files that may contain multiple compressed streams concatenated together.) I still have no idea what the documentation should say; "don't pass more than 16K of compressed data when you're expecting a sync-flush." I can't see a way to explain this coherently without a big long explanation that will confuse people who don't care about this problem. (Add a special note, or known bugs subsection, maybe?) A simple C test program should be written, in order to check if it's the zlib library itself that's doing this. ------------------------------------------------------- Date: 2000-Dec-18 20:13 By: fdrake Comment: Andrew, please summarize what doc changes are needed, or make the changes (whichever is easier for you is fine). ------------------------------------------------------- Date: 2000-Dec-12 15:18 By: abo Comment: Further comments... After looking at the C code, a few things became clear; I need to read more about C/Python interfacing, and the "unused_data" attribute will only contain data if additional data is fed to a de-compressor at the end of a complete compressed stream. The purpose of the "unused_data" attribute is not clear in the documentation, so that should probably be clarified (mind you, I am looking at pre-2.0 docs so maybe it already has?). The failure to produce all data up to a sync-flush is something else... I'm still looking into it. I'm not sure if it is an inherent limitation of zlib, something that needs to be fixed in zlib, or something that needs to be fixed in the python interface. If it is an inherent limitation, I'd like to characterise it a bit better before documenting it. If it is something that needs to be fixed in either zlib or the python interface, I'd like to fix it. Unfortunately, this is a bit beyond me at the moment, mainly in time, but also a bit in skill (need to read the python/C interfacing documentation). Maybe over the christmas holidays I'll get a chance to fix it. ------------------------------------------------------- Date: 2000-Dec-12 13:32 By: gvanrossum Comment: OK, assigned to Fred. You may ask Andrew what to write. :-) ------------------------------------------------------- Date: 2000-Dec-08 14:50 By: abo Comment: I'm not that sure I'm happy with it just being marked closed. AFAIKT, the implementation definitely doesn't do what the documentation says, so to save people like me time when they hit it, I'prefer the bug at least be assigned to documentation so that the limitation is documented. >From my reading of the documentation as it stands, the fact that there is more pending data in the decompressor should be indicated by it's "unused_data" attribute. The tests seem to show that "decompress()" is only processing 16K of compressed data each call, which would suggest that "unused_data" should contain the rest. However, in all my tests that attribute has always been empty. Perhaps the bug is in there somewhere? Another slight strangeness, even if "unused_data" did contain something, the only way to get it out is by feeding in more compressed data, or issuing a flush(), thus ending the decompression... I guess that since I've been bitten by this, it's up to me to fix it. I've got the source to 2.0 and I'll have a look and see if I can submit a patch. and I was coding this app in python to avoid coding in C :-) ------------------------------------------------------- Date: 2000-Dec-08 09:26 By: akuchling Comment: Python 2.0 demonstrates the problem, too. I'm not sure what this is: a zlibmodule bug/oversight or simply problems with zlib's API. Looking at zlib.h, it implies that you'd have to call inflate() with the flush parameter set to Z_SYNC_FLUSH to get the remaining data. Unfortunately this doesn't seem to help -- .flush() method doesn't support an argument, but when I patch zlibmodule.c to allow one, .flush(Z_SYNC_FLUSH) always fails with a -5: buffer error, perhaps because it expects there to be some new data. (The DEFAULTALLOC constant in zlibmodule.c is 16K, but this seems to be unrelated to the problem showing up with more than 16K of data, since changing DEFAULTALLOC to 32K or 1K makes no difference to the size of data at which the bug shows up.) In short, I have no idea what's at fault, or if it can or should be fixed. Unless you or someone else submits a patch, I'll just leave it alone, and mark this bug as closed and "Won't fix". ------------------------------------------------------- Date: 2000-Dec-08 07:44 By: gvanrossum Comment: I *think* this may have been fixed in Python 2.0. I'm assigning this to Andrew who can confirm that and close the bug report (if it is fixed). ------------------------------------------------------- Date: 2000-Dec-07 23:28 By: abo Comment: Argh... SF killed all my indents... sorry about that. You should be able to figure it out, but if not email me and I can send a copy. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=124981&group_id=5470 From noreply@sourceforge.net Mon Jan 22 23:34:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 15:34:33 -0800 Subject: [Python-bugs-list] [Bug #124981] zlib decompress of sync-flushed data fails Message-ID: Bug #124981, was updated on 2000-Dec-07 23:25 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: abo Assigned to : akuchling Summary: zlib decompress of sync-flushed data fails Details: I'm not sure if this is just an undocumented limitation or a genuine bug. I'm using python 1.5.2 on winNT. A single decompress of a large amount (16K+) of compressed data that has been sync-flushed fails to produce all the data up to the sync-flush. The data remains inside the decompressor untill further compressed data or a final flush is issued. Note that the 'unused_data' attribute does not show that there is further data in the decompressor to process (it shows ''). A workaround is to decompress the data in smaller chunks. Note that compressing data in smaller chunks is not required, as the problem is in the decompressor, not the compressor. The following code demonstrates the problem, and raises an exception when the compressed data reaches 17K; from zlib import * from random import * # create compressor and decompressor c=compressobj(9) d=decompressobj() # try data sizes of 1-63K for l in range(1,64): # generate random data stream a='' for i in range(l*1024): a=a+chr(randint(0,255)) # compress, sync-flush, and decompress t=d.decompress(c.compress(a)+c.flush(Z_SYNC_FLUSH)) # if decompressed data is different to input data, barf, if len(t) != len(a): print len(a),len(t),len(d.unused_data) raise error Follow-Ups: Date: 2001-Jan-22 15:34 By: abo Comment: Oh yeah, since I now know that it's definitely a zlibmodule.c bug, not a documentation problem, you can probably change this bug's catagory from "Documentation" to something more appropriate. ------------------------------------------------------- Date: 2001-Jan-22 15:31 By: abo Comment: I've got a patch that I'm currently testing. When it's ready how do you want me to submit it; through the SF patch manager? I've analysed the code pretty extensively by now, and I believe I found a few other potential problems (though I haven't bothered to create test cases to trigger them). The original problem I found could affect compression as well as decompression. There were some memory allocations that didn't raise exceptions if they failed, and potential memory leaks when exceptions did occur. Also, deflateEnd would be called twice in a decompression object if it was flushed before it was destroyed. The strange thing is compression, decompression, and both flush routines perform basicly the same function, but they were all structured totally differently (like they had been written by different people). Also, there didn't seem to be any consistancy in the coding style so I didn't know what style to use. I tried to resist fixing more than the initial problem I identified, but in the end couldn't help myself. As an aside, I noticed that the 2.0 version of zlibmodule.c is Python 2.0 specific (It wouldn't work on my 1.5.2 system so I had to compile 2.0 to test my patch). How do you want me to submit my patch; one big patch, or several smaller ones for each fix? I have been using prcs to track my changes, but I have been a bit lax in checking in each small change, so creating seperate patches will take a little work. ------------------------------------------------------- Date: 2001-Jan-20 06:22 By: abo Comment: OK, Christmas is over, and I didn't really get a chance to look at it much. However, some preliminary testing of the zlib library suggests that it is _not_ in zlib. A c program that does the same compress/decompress of random data using steadily increasing block sizes does not show the same fault... I've noticed what might be a potential problem in the inflateInit2 call in PyZlib_decompressobj. The next_in and avail_in are not being initialized before it's called. The zlib manual says they should be init'ed because deflateInit will attempt to determine the compression method if it can. I'm not sure why this hasn't tripped already... does PyObject_New zero memory when it allocates things? I also think I've found the main problem... the PyZlib_objdecompress routine's main decompression loop thinks decompression is compelete when all available input has been processed. However, it is possible that all available input has been processed but there is more pending output. The code as it stands does correctly allocate more space when this occurs, but the loop terminates without calling inflate one more time. I'm putting together a patch tomorrow. Right now I'm going to bed... ------------------------------------------------------- Date: 2000-Dec-20 15:17 By: abo Comment: I have had a look at this in more detail (Python C interfacing is actually pretty easy :-). I dunno whether to go into details here, but I have noticed that inflate is being called with Z_NO_FLUSH when the zlib docs suggest Z_SYNC_FLUSH or Z_FINISH. However, the zlib implementation only treats Z_FINISH differently, so this should not make a difference (but it might in future versions of zlib). As you have said, .unused_data will only contain data if something is appended to a complete compressed object in the stream fed to a decompressor. Perhaps the docs need something to clarify this, perhaps in the form of an example? I am going to write some test progs to see if it's in zlib. At this stage I suspect that it is, and I'm hoping over christmas to get a patch done. ------------------------------------------------------- Date: 2000-Dec-19 11:48 By: akuchling Comment: .unused_data is really a red herring; the PyZlib_objdecompress() loops until zst->avail_in is zero, so .unused_data must always be zero by definition. (The attribute is there to support gzip-format files that may contain multiple compressed streams concatenated together.) I still have no idea what the documentation should say; "don't pass more than 16K of compressed data when you're expecting a sync-flush." I can't see a way to explain this coherently without a big long explanation that will confuse people who don't care about this problem. (Add a special note, or known bugs subsection, maybe?) A simple C test program should be written, in order to check if it's the zlib library itself that's doing this. ------------------------------------------------------- Date: 2000-Dec-18 20:13 By: fdrake Comment: Andrew, please summarize what doc changes are needed, or make the changes (whichever is easier for you is fine). ------------------------------------------------------- Date: 2000-Dec-12 15:18 By: abo Comment: Further comments... After looking at the C code, a few things became clear; I need to read more about C/Python interfacing, and the "unused_data" attribute will only contain data if additional data is fed to a de-compressor at the end of a complete compressed stream. The purpose of the "unused_data" attribute is not clear in the documentation, so that should probably be clarified (mind you, I am looking at pre-2.0 docs so maybe it already has?). The failure to produce all data up to a sync-flush is something else... I'm still looking into it. I'm not sure if it is an inherent limitation of zlib, something that needs to be fixed in zlib, or something that needs to be fixed in the python interface. If it is an inherent limitation, I'd like to characterise it a bit better before documenting it. If it is something that needs to be fixed in either zlib or the python interface, I'd like to fix it. Unfortunately, this is a bit beyond me at the moment, mainly in time, but also a bit in skill (need to read the python/C interfacing documentation). Maybe over the christmas holidays I'll get a chance to fix it. ------------------------------------------------------- Date: 2000-Dec-12 13:32 By: gvanrossum Comment: OK, assigned to Fred. You may ask Andrew what to write. :-) ------------------------------------------------------- Date: 2000-Dec-08 14:50 By: abo Comment: I'm not that sure I'm happy with it just being marked closed. AFAIKT, the implementation definitely doesn't do what the documentation says, so to save people like me time when they hit it, I'prefer the bug at least be assigned to documentation so that the limitation is documented. >From my reading of the documentation as it stands, the fact that there is more pending data in the decompressor should be indicated by it's "unused_data" attribute. The tests seem to show that "decompress()" is only processing 16K of compressed data each call, which would suggest that "unused_data" should contain the rest. However, in all my tests that attribute has always been empty. Perhaps the bug is in there somewhere? Another slight strangeness, even if "unused_data" did contain something, the only way to get it out is by feeding in more compressed data, or issuing a flush(), thus ending the decompression... I guess that since I've been bitten by this, it's up to me to fix it. I've got the source to 2.0 and I'll have a look and see if I can submit a patch. and I was coding this app in python to avoid coding in C :-) ------------------------------------------------------- Date: 2000-Dec-08 09:26 By: akuchling Comment: Python 2.0 demonstrates the problem, too. I'm not sure what this is: a zlibmodule bug/oversight or simply problems with zlib's API. Looking at zlib.h, it implies that you'd have to call inflate() with the flush parameter set to Z_SYNC_FLUSH to get the remaining data. Unfortunately this doesn't seem to help -- .flush() method doesn't support an argument, but when I patch zlibmodule.c to allow one, .flush(Z_SYNC_FLUSH) always fails with a -5: buffer error, perhaps because it expects there to be some new data. (The DEFAULTALLOC constant in zlibmodule.c is 16K, but this seems to be unrelated to the problem showing up with more than 16K of data, since changing DEFAULTALLOC to 32K or 1K makes no difference to the size of data at which the bug shows up.) In short, I have no idea what's at fault, or if it can or should be fixed. Unless you or someone else submits a patch, I'll just leave it alone, and mark this bug as closed and "Won't fix". ------------------------------------------------------- Date: 2000-Dec-08 07:44 By: gvanrossum Comment: I *think* this may have been fixed in Python 2.0. I'm assigning this to Andrew who can confirm that and close the bug report (if it is fixed). ------------------------------------------------------- Date: 2000-Dec-07 23:28 By: abo Comment: Argh... SF killed all my indents... sorry about that. You should be able to figure it out, but if not email me and I can send a copy. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=124981&group_id=5470 From noreply@sourceforge.net Tue Jan 23 00:12:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 16:12:08 -0800 Subject: [Python-bugs-list] [Bug #129740] make html fails in the current CVS tree Message-ID: Bug #129740, was updated on 2001-Jan-22 16:12 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: esr Assigned to : nobody Summary: make html fails in the current CVS tree Details: Script started on Mon Jan 22 18:49:25 2001 ]0;esr@snark.thyrsus.com: /home/esr/cvs/python/dist/src/Docsnark:~/cvs/python/dist/src/Doc$ make html (cd html; make PAPER=letter -f ../html/Makefile) /home/esr/cvs/python/dist/src/Doc/html make[1]: Entering directory `/home/esr/cvs/python/dist/src/Doc/html' ../tools/mkhowto --about ../html/stdabout.dat --address 'See About this document... for information on suggesting changes.' --up-link ../index.html --up-title "Python Documentation Index" --global-module-index "../modindex.html" --html ../api/api.tex +++ TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/api:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs: +++ latex api +++ latex2html -init_file /var/tmp/@16080.0 -dir api /home/esr/cvs/python/dist/src/Doc/api/api.tex *** Session transcript and error messages are in api.how. ../tools/mkhowto --about ../html/stdabout.dat --address 'See About this document... for information on suggesting changes.' --up-link ../index.html --up-title "Python Documentation Index" --global-module-index "../modindex.html" --html ../doc/doc.tex +++ TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/doc:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs: +++ latex doc +++ latex2html -init_file /var/tmp/@16085.0 -dir doc /home/esr/cvs/python/dist/src/Doc/doc/doc.tex *** Session transcript and error messages are in doc.how. ../tools/mkhowto --about ../html/stdabout.dat --address 'See About this document... for information on suggesting changes.' --up-link ../index.html --up-title "Python Documentation Index" --global-module-index "../modindex.html" --html ../ext/ext.tex +++ TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/ext:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs: +++ latex ext +++ latex2html -init_file /var/tmp/@16090.0 -dir ext /home/esr/cvs/python/dist/src/Doc/ext/ext.tex *** Session transcript and error messages are in ext.how. ../tools/mkhowto --about ../html/stdabout.dat --address 'See About this document... for information on suggesting changes.' --up-link ../index.html --up-title "Python Documentation Index" --global-module-index "../modindex.html" --html ../lib/lib.tex +++ TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/lib:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs: +++ latex lib +++ latex2html -init_file /var/tmp/@16095.0 -dir lib /home/esr/cvs/python/dist/src/Doc/lib/lib.tex *** Session transcript and error messages are in lib.how. ../tools/mkhowto --about ../html/stdabout.dat --address 'See About this document... for information on suggesting changes.' --up-link ../index.html --up-title "Python Documentation Index" --global-module-index "../modindex.html" --html ../mac/mac.tex +++ TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/mac:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs: +++ latex mac +++ latex2html -init_file /var/tmp/@16109.0 -dir mac /home/esr/cvs/python/dist/src/Doc/mac/mac.tex *** Session transcript and error messages are in mac.how. ../tools/mkhowto --about ../html/stdabout.dat --address 'See About this document... for information on suggesting changes.' --up-link ../index.html --up-title "Python Documentation Index" --global-module-index "../modindex.html" --html ../ref/ref.tex +++ TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/ref:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs: +++ latex ref +++ latex2html -init_file /var/tmp/@16114.0 -dir ref /home/esr/cvs/python/dist/src/Doc/ref/ref.tex *** Session transcript and error messages are in ref.how. ../tools/mkhowto --about ../html/stdabout.dat --address 'See About this document... for information on suggesting changes.' --up-link ../index.html --up-title "Python Documentation Index" --global-module-index "../modindex.html" --html --numeric --split 3 ../tut/tut.tex +++ TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/tut:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs: +++ latex tut +++ latex2html -init_file /var/tmp/@16119.0 -dir tut /home/esr/cvs/python/dist/src/Doc/tut/tut.tex *** Session transcript and error messages are in tut.how. ../tools/mkhowto --about ../html/stdabout.dat --address 'See About this document... for information on suggesting changes.' --up-link ../index.html --up-title "Python Documentation Index" --global-module-index "../modindex.html" --html ../inst/inst.tex +++ TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/inst:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs: +++ latex inst +++ latex2html -init_file /var/tmp/@16124.0 -dir inst /home/esr/cvs/python/dist/src/Doc/inst/inst.tex *** Session transcript and error messages are in inst.how. ../tools/mkhowto --about ../html/stdabout.dat --address 'See About this document... for information on suggesting changes.' --up-link ../index.html --up-title "Python Documentation Index" --global-module-index "../modindex.html" --html ../dist/dist.tex +++ TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/dist:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs: +++ latex dist +++ latex2html -init_file /var/tmp/@16129.0 -dir dist /home/esr/cvs/python/dist/src/Doc/dist/dist.tex *** Session transcript and error messages are in dist.how. ../tools/mkmodindex --columns 4 --output modindex.html \ --address 'See About this document... for information on suggesting changes.' \ lib/modindex.html mac/modindex.html Traceback (most recent call last): File "../tools/mkmodindex", line 136, in ? main() File "../tools/mkmodindex", line 91, in main ifp = open(ifn) IOError: [Errno 2] No such file or directory: 'lib/modindex.html' make[1]: *** [modindex.html] Error 1 make[1]: Leaving directory `/home/esr/cvs/python/dist/src/Doc/html' make: *** [html] Error 2 ]0;esr@snark.thyrsus.com: /home/esr/cvs/python/dist/src/Docsnark:~/cvs/python/dist/src/Doc$ exit Script done on Mon Jan 22 18:50:29 2001 For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129740&group_id=5470 From noreply@sourceforge.net Tue Jan 23 00:13:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 16:13:40 -0800 Subject: [Python-bugs-list] [Bug #129740] make html fails in the current CVS tree Message-ID: Bug #129740, was updated on 2001-Jan-22 16:12 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: esr Assigned to : fdrake Summary: make html fails in the current CVS tree Details: Script started on Mon Jan 22 18:49:25 2001 ]0;esr@snark.thyrsus.com: /home/esr/cvs/python/dist/src/Docsnark:~/cvs/python/dist/src/Doc$ make html (cd html; make PAPER=letter -f ../html/Makefile) /home/esr/cvs/python/dist/src/Doc/html make[1]: Entering directory `/home/esr/cvs/python/dist/src/Doc/html' ../tools/mkhowto --about ../html/stdabout.dat --address 'See About this document... for information on suggesting changes.' --up-link ../index.html --up-title "Python Documentation Index" --global-module-index "../modindex.html" --html ../api/api.tex +++ TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/api:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs: +++ latex api +++ latex2html -init_file /var/tmp/@16080.0 -dir api /home/esr/cvs/python/dist/src/Doc/api/api.tex *** Session transcript and error messages are in api.how. ../tools/mkhowto --about ../html/stdabout.dat --address 'See About this document... for information on suggesting changes.' --up-link ../index.html --up-title "Python Documentation Index" --global-module-index "../modindex.html" --html ../doc/doc.tex +++ TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/doc:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs: +++ latex doc +++ latex2html -init_file /var/tmp/@16085.0 -dir doc /home/esr/cvs/python/dist/src/Doc/doc/doc.tex *** Session transcript and error messages are in doc.how. ../tools/mkhowto --about ../html/stdabout.dat --address 'See About this document... for information on suggesting changes.' --up-link ../index.html --up-title "Python Documentation Index" --global-module-index "../modindex.html" --html ../ext/ext.tex +++ TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/ext:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs: +++ latex ext +++ latex2html -init_file /var/tmp/@16090.0 -dir ext /home/esr/cvs/python/dist/src/Doc/ext/ext.tex *** Session transcript and error messages are in ext.how. ../tools/mkhowto --about ../html/stdabout.dat --address 'See About this document... for information on suggesting changes.' --up-link ../index.html --up-title "Python Documentation Index" --global-module-index "../modindex.html" --html ../lib/lib.tex +++ TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/lib:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs: +++ latex lib +++ latex2html -init_file /var/tmp/@16095.0 -dir lib /home/esr/cvs/python/dist/src/Doc/lib/lib.tex *** Session transcript and error messages are in lib.how. ../tools/mkhowto --about ../html/stdabout.dat --address 'See About this document... for information on suggesting changes.' --up-link ../index.html --up-title "Python Documentation Index" --global-module-index "../modindex.html" --html ../mac/mac.tex +++ TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/mac:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs: +++ latex mac +++ latex2html -init_file /var/tmp/@16109.0 -dir mac /home/esr/cvs/python/dist/src/Doc/mac/mac.tex *** Session transcript and error messages are in mac.how. ../tools/mkhowto --about ../html/stdabout.dat --address 'See About this document... for information on suggesting changes.' --up-link ../index.html --up-title "Python Documentation Index" --global-module-index "../modindex.html" --html ../ref/ref.tex +++ TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/ref:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs: +++ latex ref +++ latex2html -init_file /var/tmp/@16114.0 -dir ref /home/esr/cvs/python/dist/src/Doc/ref/ref.tex *** Session transcript and error messages are in ref.how. ../tools/mkhowto --about ../html/stdabout.dat --address 'See About this document... for information on suggesting changes.' --up-link ../index.html --up-title "Python Documentation Index" --global-module-index "../modindex.html" --html --numeric --split 3 ../tut/tut.tex +++ TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/tut:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs: +++ latex tut +++ latex2html -init_file /var/tmp/@16119.0 -dir tut /home/esr/cvs/python/dist/src/Doc/tut/tut.tex *** Session transcript and error messages are in tut.how. ../tools/mkhowto --about ../html/stdabout.dat --address 'See About this document... for information on suggesting changes.' --up-link ../index.html --up-title "Python Documentation Index" --global-module-index "../modindex.html" --html ../inst/inst.tex +++ TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/inst:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs: +++ latex inst +++ latex2html -init_file /var/tmp/@16124.0 -dir inst /home/esr/cvs/python/dist/src/Doc/inst/inst.tex *** Session transcript and error messages are in inst.how. ../tools/mkhowto --about ../html/stdabout.dat --address 'See About this document... for information on suggesting changes.' --up-link ../index.html --up-title "Python Documentation Index" --global-module-index "../modindex.html" --html ../dist/dist.tex +++ TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/dist:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs: +++ latex dist +++ latex2html -init_file /var/tmp/@16129.0 -dir dist /home/esr/cvs/python/dist/src/Doc/dist/dist.tex *** Session transcript and error messages are in dist.how. ../tools/mkmodindex --columns 4 --output modindex.html \ --address 'See About this document... for information on suggesting changes.' \ lib/modindex.html mac/modindex.html Traceback (most recent call last): File "../tools/mkmodindex", line 136, in ? main() File "../tools/mkmodindex", line 91, in main ifp = open(ifn) IOError: [Errno 2] No such file or directory: 'lib/modindex.html' make[1]: *** [modindex.html] Error 1 make[1]: Leaving directory `/home/esr/cvs/python/dist/src/Doc/html' make: *** [html] Error 2 ]0;esr@snark.thyrsus.com: /home/esr/cvs/python/dist/src/Docsnark:~/cvs/python/dist/src/Doc$ exit Script done on Mon Jan 22 18:50:29 2001 For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129740&group_id=5470 From noreply@sourceforge.net Tue Jan 23 00:39:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 16:39:06 -0800 Subject: [Python-bugs-list] [Bug #125673] PyThreadState_Delete: invalid tstate (Unix only?) Message-ID: Bug #125673, was updated on 2000-Dec-13 08:25 Here is a current snapshot of the bug. Project: Python Category: Threads Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: gvanrossum Assigned to : gvanrossum Summary: PyThreadState_Delete: invalid tstate (Unix only?) Details: I am working on a simple couroutine/generator package using threads, to prototype the API. It seems to be working fine, except it is exposing a hard-to-find bug in the threadstate code. The following script[*] contains the API implementation and a simple example based on Tim's "fringe()" code. When I run the example, I *sometimes* get: Segmentation fault but *sometimes* I get: Fatal Python error: PyThreadState_Delete: invalid tstate Aborted and *sometimes* it succeeds. If I uncomment the raw_input("Exit?") line at the end I never get an error. The error behavior seems very fickle: making almost arbitrary changes to the code can trigger it or make it go away. When I run it under gdb, I cannot reproduce the problen, ever. (Haven't I heard this before?) The only clue is the fatal error message: it seems to be a race condition at thread termination. But how to debug this? _____ [*] I'm not including the script here. I can mail it to interested parties though. For my own reference: Subject: [Pycabal] Mysterious thread bug To: Date: Thu, 16 Nov 2000 16:21:12 -0500 Follow-Ups: Date: 2001-Jan-22 16:39 By: gvanrossum Comment: A likely story indeed! With the current CVS, the test script fails every time. If I comment out the call to PyThreadState_Delete() from t_bootstrap, it runs fine every time. Suggestion: change PyThreadState_Delete() so that it can be called with the interpreter lock *held*, and in that case it should "atomically" delete the tstate object and release the lock. I'll see if I can come up with a patch. ------------------------------------------------------- Date: 2001-Jan-21 01:26 By: tim_one Comment: Let's pretend: threadmodule.c/t_bootstrap finishes running the user's spawned-thread code, PyEval_ReleaseThread(tstate) releases the global lock, then PyThreadState_Delete(tstate) is called to unlink tstate from the tstate->interp->tstate_head chain. But the thread swaps out at that point, and the main thread resumes executing. It's got nothing left to do, so it gets into pythonrun.c/Py_Finalize() quickly, and soon enough calls PyInterpreterState_Delete(interp) from there. That calls zapthreads(). zapthreads calls PyThreadState_Delete(ts) on *every* threadstate ts in the interp->tstate_head chain. If you're with me so far, the other thread still hasn't called PyThreadState_Delete on *its* threadstate, and the comment in zapthreads is semi-prophetic : /* No need to lock the mutex here because this should only happen when the threads are all really dead (XXX famous last words). */ But the problem is not that the mutex isn't locked, it's that the other thread is still going to try deleting its tstate again *later* (the precise cause of an "invalid tstate" error msg): other threads aren't really dead, and AFAICT there's actually no reason to believe they *should* be dead at this point (other than luck). Anyway, if this is right, we have two threads battling over who's going to delete a single tstate, and if the main thread gets in first, the other thread is certain to raise an error (except that, at least on Windows, if the main thread manages to exit before the other thread gets that far, the other thread will be killed off quietly in mid-stream by the OS; since Linux threads seem to be indistinguishable from Linux processes, I bet they run some pthreads emulation layer in user space that *may* take a fair amount of time to kill off child threads when the parent goes away). Waddya think? Explains everything and solves nothing . ------------------------------------------------------- Date: 2001-Jan-20 23:20 By: tim_one Comment: Guido, since we just fixed *a* thread termination problem (premature clearing of "initialized" in pythonrun.c), and I've never seen this fail on Windows, reassigning to you to see whether-- however unlikely it may seem --this problem has gone away by magic now. ------------------------------------------------------- Date: 2000-Dec-13 08:51 By: tim_one Comment: I was never able to provoke a problem on Windows using Guido's script, so changed Group to Platform-specific and added "(Linux only?)" to Summary. Here's the script; assigned to Greg under the hope he can provoke a problem: import thread class EarlyExit(Exception): pass class main_coroutine: def __init__(self): self.id = 0 self.caller = None self.value = None self.lock = thread.allocate_lock() self.lock.acquire() self.done = 0 def __call__(self, value=None): cur = current() assert cur is not self self.caller = cur self.value = value self.lock.release() cur.lock.acquire() if self.done: raise EarlyExit return cur.value all_coroutines = {thread.get_ident(): main_coroutine()} def current(): return all_coroutines[thread.get_ident()] def suspend(value=None): cur = current() caller = cur.caller assert caller and caller is not cur caller.value = value caller.lock.release() cur.lock.acquire() return cur.value nextid = 1 class coroutine(main_coroutine): def __init__(self, func, *args): global nextid self.id = nextid nextid = nextid + 1 self.caller = current() boot = thread.allocate_lock() boot.acquire() thread.start_new_thread(self.run, (boot, func, args)) boot.acquire() def run(self, boot, func, args): me = thread.get_ident() all_coroutines[me] = self self.lock = thread.allocate_lock() self.lock.acquire() self.done = 0 boot.release() self.lock.acquire() if self.value: print "Warning: initial value %s ignored" % `value` try: apply(func, args) finally: del all_coroutines[me] self.done = 1 self.caller.lock.release() def fringe(list): tl = type(list) for item in list: if type(item) is tl: fringe(item) else: suspend(item) def printinorder(list): c = coroutine(fringe, list) try: while 1: print c(), except EarlyExit: pass print if __name__ == '__main__': printinorder([1,2,3]) l = [1,2,[3,4,[5],6]] printinorder(l) #raw_input("Exit?") ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=125673&group_id=5470 From noreply@sourceforge.net Tue Jan 23 01:48:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 17:48:57 -0800 Subject: [Python-bugs-list] [Bug #125673] PyThreadState_Delete: invalid tstate Message-ID: Bug #125673, was updated on 2000-Dec-13 08:25 Here is a current snapshot of the bug. Project: Python Category: Threads Status: Open Resolution: Fixed Bug Group: None Priority: 5 Submitted by: gvanrossum Assigned to : gvanrossum Summary: PyThreadState_Delete: invalid tstate Details: I am working on a simple couroutine/generator package using threads, to prototype the API. It seems to be working fine, except it is exposing a hard-to-find bug in the threadstate code. The following script[*] contains the API implementation and a simple example based on Tim's "fringe()" code. When I run the example, I *sometimes* get: Segmentation fault but *sometimes* I get: Fatal Python error: PyThreadState_Delete: invalid tstate Aborted and *sometimes* it succeeds. If I uncomment the raw_input("Exit?") line at the end I never get an error. The error behavior seems very fickle: making almost arbitrary changes to the code can trigger it or make it go away. When I run it under gdb, I cannot reproduce the problen, ever. (Haven't I heard this before?) The only clue is the fatal error message: it seems to be a race condition at thread termination. But how to debug this? _____ [*] I'm not including the script here. I can mail it to interested parties though. For my own reference: Subject: [Pycabal] Mysterious thread bug To: Date: Thu, 16 Nov 2000 16:21:12 -0500 Follow-Ups: Date: 2001-Jan-22 17:48 By: gvanrossum Comment: Fixed by introducing a new API: PyThreadState_DeleteCurrent(). AFAICT this is not Unix-only, but whether the behavior triggers depends on details of the thread implementation, so I cleared the platform-specific group and removed "(unix only?)" from subject. ------------------------------------------------------- Date: 2001-Jan-22 16:39 By: gvanrossum Comment: A likely story indeed! With the current CVS, the test script fails every time. If I comment out the call to PyThreadState_Delete() from t_bootstrap, it runs fine every time. Suggestion: change PyThreadState_Delete() so that it can be called with the interpreter lock *held*, and in that case it should "atomically" delete the tstate object and release the lock. I'll see if I can come up with a patch. ------------------------------------------------------- Date: 2001-Jan-21 01:26 By: tim_one Comment: Let's pretend: threadmodule.c/t_bootstrap finishes running the user's spawned-thread code, PyEval_ReleaseThread(tstate) releases the global lock, then PyThreadState_Delete(tstate) is called to unlink tstate from the tstate->interp->tstate_head chain. But the thread swaps out at that point, and the main thread resumes executing. It's got nothing left to do, so it gets into pythonrun.c/Py_Finalize() quickly, and soon enough calls PyInterpreterState_Delete(interp) from there. That calls zapthreads(). zapthreads calls PyThreadState_Delete(ts) on *every* threadstate ts in the interp->tstate_head chain. If you're with me so far, the other thread still hasn't called PyThreadState_Delete on *its* threadstate, and the comment in zapthreads is semi-prophetic : /* No need to lock the mutex here because this should only happen when the threads are all really dead (XXX famous last words). */ But the problem is not that the mutex isn't locked, it's that the other thread is still going to try deleting its tstate again *later* (the precise cause of an "invalid tstate" error msg): other threads aren't really dead, and AFAICT there's actually no reason to believe they *should* be dead at this point (other than luck). Anyway, if this is right, we have two threads battling over who's going to delete a single tstate, and if the main thread gets in first, the other thread is certain to raise an error (except that, at least on Windows, if the main thread manages to exit before the other thread gets that far, the other thread will be killed off quietly in mid-stream by the OS; since Linux threads seem to be indistinguishable from Linux processes, I bet they run some pthreads emulation layer in user space that *may* take a fair amount of time to kill off child threads when the parent goes away). Waddya think? Explains everything and solves nothing . ------------------------------------------------------- Date: 2001-Jan-20 23:20 By: tim_one Comment: Guido, since we just fixed *a* thread termination problem (premature clearing of "initialized" in pythonrun.c), and I've never seen this fail on Windows, reassigning to you to see whether-- however unlikely it may seem --this problem has gone away by magic now. ------------------------------------------------------- Date: 2000-Dec-13 08:51 By: tim_one Comment: I was never able to provoke a problem on Windows using Guido's script, so changed Group to Platform-specific and added "(Linux only?)" to Summary. Here's the script; assigned to Greg under the hope he can provoke a problem: import thread class EarlyExit(Exception): pass class main_coroutine: def __init__(self): self.id = 0 self.caller = None self.value = None self.lock = thread.allocate_lock() self.lock.acquire() self.done = 0 def __call__(self, value=None): cur = current() assert cur is not self self.caller = cur self.value = value self.lock.release() cur.lock.acquire() if self.done: raise EarlyExit return cur.value all_coroutines = {thread.get_ident(): main_coroutine()} def current(): return all_coroutines[thread.get_ident()] def suspend(value=None): cur = current() caller = cur.caller assert caller and caller is not cur caller.value = value caller.lock.release() cur.lock.acquire() return cur.value nextid = 1 class coroutine(main_coroutine): def __init__(self, func, *args): global nextid self.id = nextid nextid = nextid + 1 self.caller = current() boot = thread.allocate_lock() boot.acquire() thread.start_new_thread(self.run, (boot, func, args)) boot.acquire() def run(self, boot, func, args): me = thread.get_ident() all_coroutines[me] = self self.lock = thread.allocate_lock() self.lock.acquire() self.done = 0 boot.release() self.lock.acquire() if self.value: print "Warning: initial value %s ignored" % `value` try: apply(func, args) finally: del all_coroutines[me] self.done = 1 self.caller.lock.release() def fringe(list): tl = type(list) for item in list: if type(item) is tl: fringe(item) else: suspend(item) def printinorder(list): c = coroutine(fringe, list) try: while 1: print c(), except EarlyExit: pass print if __name__ == '__main__': printinorder([1,2,3]) l = [1,2,[3,4,[5],6]] printinorder(l) #raw_input("Exit?") ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=125673&group_id=5470 From noreply@sourceforge.net Tue Jan 23 01:49:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 17:49:07 -0800 Subject: [Python-bugs-list] [Bug #125673] PyThreadState_Delete: invalid tstate Message-ID: Bug #125673, was updated on 2000-Dec-13 08:25 Here is a current snapshot of the bug. Project: Python Category: Threads Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: gvanrossum Assigned to : gvanrossum Summary: PyThreadState_Delete: invalid tstate Details: I am working on a simple couroutine/generator package using threads, to prototype the API. It seems to be working fine, except it is exposing a hard-to-find bug in the threadstate code. The following script[*] contains the API implementation and a simple example based on Tim's "fringe()" code. When I run the example, I *sometimes* get: Segmentation fault but *sometimes* I get: Fatal Python error: PyThreadState_Delete: invalid tstate Aborted and *sometimes* it succeeds. If I uncomment the raw_input("Exit?") line at the end I never get an error. The error behavior seems very fickle: making almost arbitrary changes to the code can trigger it or make it go away. When I run it under gdb, I cannot reproduce the problen, ever. (Haven't I heard this before?) The only clue is the fatal error message: it seems to be a race condition at thread termination. But how to debug this? _____ [*] I'm not including the script here. I can mail it to interested parties though. For my own reference: Subject: [Pycabal] Mysterious thread bug To: Date: Thu, 16 Nov 2000 16:21:12 -0500 Follow-Ups: Date: 2001-Jan-22 17:48 By: gvanrossum Comment: Fixed by introducing a new API: PyThreadState_DeleteCurrent(). AFAICT this is not Unix-only, but whether the behavior triggers depends on details of the thread implementation, so I cleared the platform-specific group and removed "(unix only?)" from subject. ------------------------------------------------------- Date: 2001-Jan-22 16:39 By: gvanrossum Comment: A likely story indeed! With the current CVS, the test script fails every time. If I comment out the call to PyThreadState_Delete() from t_bootstrap, it runs fine every time. Suggestion: change PyThreadState_Delete() so that it can be called with the interpreter lock *held*, and in that case it should "atomically" delete the tstate object and release the lock. I'll see if I can come up with a patch. ------------------------------------------------------- Date: 2001-Jan-21 01:26 By: tim_one Comment: Let's pretend: threadmodule.c/t_bootstrap finishes running the user's spawned-thread code, PyEval_ReleaseThread(tstate) releases the global lock, then PyThreadState_Delete(tstate) is called to unlink tstate from the tstate->interp->tstate_head chain. But the thread swaps out at that point, and the main thread resumes executing. It's got nothing left to do, so it gets into pythonrun.c/Py_Finalize() quickly, and soon enough calls PyInterpreterState_Delete(interp) from there. That calls zapthreads(). zapthreads calls PyThreadState_Delete(ts) on *every* threadstate ts in the interp->tstate_head chain. If you're with me so far, the other thread still hasn't called PyThreadState_Delete on *its* threadstate, and the comment in zapthreads is semi-prophetic : /* No need to lock the mutex here because this should only happen when the threads are all really dead (XXX famous last words). */ But the problem is not that the mutex isn't locked, it's that the other thread is still going to try deleting its tstate again *later* (the precise cause of an "invalid tstate" error msg): other threads aren't really dead, and AFAICT there's actually no reason to believe they *should* be dead at this point (other than luck). Anyway, if this is right, we have two threads battling over who's going to delete a single tstate, and if the main thread gets in first, the other thread is certain to raise an error (except that, at least on Windows, if the main thread manages to exit before the other thread gets that far, the other thread will be killed off quietly in mid-stream by the OS; since Linux threads seem to be indistinguishable from Linux processes, I bet they run some pthreads emulation layer in user space that *may* take a fair amount of time to kill off child threads when the parent goes away). Waddya think? Explains everything and solves nothing . ------------------------------------------------------- Date: 2001-Jan-20 23:20 By: tim_one Comment: Guido, since we just fixed *a* thread termination problem (premature clearing of "initialized" in pythonrun.c), and I've never seen this fail on Windows, reassigning to you to see whether-- however unlikely it may seem --this problem has gone away by magic now. ------------------------------------------------------- Date: 2000-Dec-13 08:51 By: tim_one Comment: I was never able to provoke a problem on Windows using Guido's script, so changed Group to Platform-specific and added "(Linux only?)" to Summary. Here's the script; assigned to Greg under the hope he can provoke a problem: import thread class EarlyExit(Exception): pass class main_coroutine: def __init__(self): self.id = 0 self.caller = None self.value = None self.lock = thread.allocate_lock() self.lock.acquire() self.done = 0 def __call__(self, value=None): cur = current() assert cur is not self self.caller = cur self.value = value self.lock.release() cur.lock.acquire() if self.done: raise EarlyExit return cur.value all_coroutines = {thread.get_ident(): main_coroutine()} def current(): return all_coroutines[thread.get_ident()] def suspend(value=None): cur = current() caller = cur.caller assert caller and caller is not cur caller.value = value caller.lock.release() cur.lock.acquire() return cur.value nextid = 1 class coroutine(main_coroutine): def __init__(self, func, *args): global nextid self.id = nextid nextid = nextid + 1 self.caller = current() boot = thread.allocate_lock() boot.acquire() thread.start_new_thread(self.run, (boot, func, args)) boot.acquire() def run(self, boot, func, args): me = thread.get_ident() all_coroutines[me] = self self.lock = thread.allocate_lock() self.lock.acquire() self.done = 0 boot.release() self.lock.acquire() if self.value: print "Warning: initial value %s ignored" % `value` try: apply(func, args) finally: del all_coroutines[me] self.done = 1 self.caller.lock.release() def fringe(list): tl = type(list) for item in list: if type(item) is tl: fringe(item) else: suspend(item) def printinorder(list): c = coroutine(fringe, list) try: while 1: print c(), except EarlyExit: pass print if __name__ == '__main__': printinorder([1,2,3]) l = [1,2,[3,4,[5],6]] printinorder(l) #raw_input("Exit?") ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=125673&group_id=5470 From noreply@sourceforge.net Tue Jan 23 03:41:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 19:41:40 -0800 Subject: [Python-bugs-list] [Bug #129759] typo Message-ID: Bug #129759, was updated on 2001-Jan-22 19:41 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: noah Assigned to : nobody Summary: typo Details: URL to document page: http://www.python.org/doc/current/ref/programs.html search for the word "coplete" in this context: "The initial environment is identical to that of a coplete program; each statement is executed in the namespace of __main__. " I believe that the first word of that second line should be "complete", not "coplete". Yours, Noah For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129759&group_id=5470 From noreply@sourceforge.net Tue Jan 23 04:16:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 20:16:14 -0800 Subject: [Python-bugs-list] [Bug #124981] zlib decompress of sync-flushed data fails Message-ID: Bug #124981, was updated on 2000-Dec-07 23:25 Here is a current snapshot of the bug. Project: Python Category: Extension Modules Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: abo Assigned to : akuchling Summary: zlib decompress of sync-flushed data fails Details: I'm not sure if this is just an undocumented limitation or a genuine bug. I'm using python 1.5.2 on winNT. A single decompress of a large amount (16K+) of compressed data that has been sync-flushed fails to produce all the data up to the sync-flush. The data remains inside the decompressor untill further compressed data or a final flush is issued. Note that the 'unused_data' attribute does not show that there is further data in the decompressor to process (it shows ''). A workaround is to decompress the data in smaller chunks. Note that compressing data in smaller chunks is not required, as the problem is in the decompressor, not the compressor. The following code demonstrates the problem, and raises an exception when the compressed data reaches 17K; from zlib import * from random import * # create compressor and decompressor c=compressobj(9) d=decompressobj() # try data sizes of 1-63K for l in range(1,64): # generate random data stream a='' for i in range(l*1024): a=a+chr(randint(0,255)) # compress, sync-flush, and decompress t=d.decompress(c.compress(a)+c.flush(Z_SYNC_FLUSH)) # if decompressed data is different to input data, barf, if len(t) != len(a): print len(a),len(t),len(d.unused_data) raise error Follow-Ups: Date: 2001-Jan-22 20:16 By: akuchling Comment: Yay! Please submit your patch using the Patch Manager on SourceForge so that we can look at it and discuss it. You can submit it as one big patch; obviously correct changes can be applied right away causing the patch to shrink, and disentangling the changes shouldn't be too difficult. The zlib module is really ugly code, and could probably do with a restructuring; I've wondered before if it would be worth trashing it and rewriting from scratch with the same API. Maybe for 2.2... If you want to be ambitious and do a more serious restructuring, feel free to do so, but it probably wouldn't get into 2.1. And the bug has been reclassified under Extension Modules. ------------------------------------------------------- Date: 2001-Jan-22 15:34 By: abo Comment: Oh yeah, since I now know that it's definitely a zlibmodule.c bug, not a documentation problem, you can probably change this bug's catagory from "Documentation" to something more appropriate. ------------------------------------------------------- Date: 2001-Jan-22 15:31 By: abo Comment: I've got a patch that I'm currently testing. When it's ready how do you want me to submit it; through the SF patch manager? I've analysed the code pretty extensively by now, and I believe I found a few other potential problems (though I haven't bothered to create test cases to trigger them). The original problem I found could affect compression as well as decompression. There were some memory allocations that didn't raise exceptions if they failed, and potential memory leaks when exceptions did occur. Also, deflateEnd would be called twice in a decompression object if it was flushed before it was destroyed. The strange thing is compression, decompression, and both flush routines perform basicly the same function, but they were all structured totally differently (like they had been written by different people). Also, there didn't seem to be any consistancy in the coding style so I didn't know what style to use. I tried to resist fixing more than the initial problem I identified, but in the end couldn't help myself. As an aside, I noticed that the 2.0 version of zlibmodule.c is Python 2.0 specific (It wouldn't work on my 1.5.2 system so I had to compile 2.0 to test my patch). How do you want me to submit my patch; one big patch, or several smaller ones for each fix? I have been using prcs to track my changes, but I have been a bit lax in checking in each small change, so creating seperate patches will take a little work. ------------------------------------------------------- Date: 2001-Jan-20 06:22 By: abo Comment: OK, Christmas is over, and I didn't really get a chance to look at it much. However, some preliminary testing of the zlib library suggests that it is _not_ in zlib. A c program that does the same compress/decompress of random data using steadily increasing block sizes does not show the same fault... I've noticed what might be a potential problem in the inflateInit2 call in PyZlib_decompressobj. The next_in and avail_in are not being initialized before it's called. The zlib manual says they should be init'ed because deflateInit will attempt to determine the compression method if it can. I'm not sure why this hasn't tripped already... does PyObject_New zero memory when it allocates things? I also think I've found the main problem... the PyZlib_objdecompress routine's main decompression loop thinks decompression is compelete when all available input has been processed. However, it is possible that all available input has been processed but there is more pending output. The code as it stands does correctly allocate more space when this occurs, but the loop terminates without calling inflate one more time. I'm putting together a patch tomorrow. Right now I'm going to bed... ------------------------------------------------------- Date: 2000-Dec-20 15:17 By: abo Comment: I have had a look at this in more detail (Python C interfacing is actually pretty easy :-). I dunno whether to go into details here, but I have noticed that inflate is being called with Z_NO_FLUSH when the zlib docs suggest Z_SYNC_FLUSH or Z_FINISH. However, the zlib implementation only treats Z_FINISH differently, so this should not make a difference (but it might in future versions of zlib). As you have said, .unused_data will only contain data if something is appended to a complete compressed object in the stream fed to a decompressor. Perhaps the docs need something to clarify this, perhaps in the form of an example? I am going to write some test progs to see if it's in zlib. At this stage I suspect that it is, and I'm hoping over christmas to get a patch done. ------------------------------------------------------- Date: 2000-Dec-19 11:48 By: akuchling Comment: .unused_data is really a red herring; the PyZlib_objdecompress() loops until zst->avail_in is zero, so .unused_data must always be zero by definition. (The attribute is there to support gzip-format files that may contain multiple compressed streams concatenated together.) I still have no idea what the documentation should say; "don't pass more than 16K of compressed data when you're expecting a sync-flush." I can't see a way to explain this coherently without a big long explanation that will confuse people who don't care about this problem. (Add a special note, or known bugs subsection, maybe?) A simple C test program should be written, in order to check if it's the zlib library itself that's doing this. ------------------------------------------------------- Date: 2000-Dec-18 20:13 By: fdrake Comment: Andrew, please summarize what doc changes are needed, or make the changes (whichever is easier for you is fine). ------------------------------------------------------- Date: 2000-Dec-12 15:18 By: abo Comment: Further comments... After looking at the C code, a few things became clear; I need to read more about C/Python interfacing, and the "unused_data" attribute will only contain data if additional data is fed to a de-compressor at the end of a complete compressed stream. The purpose of the "unused_data" attribute is not clear in the documentation, so that should probably be clarified (mind you, I am looking at pre-2.0 docs so maybe it already has?). The failure to produce all data up to a sync-flush is something else... I'm still looking into it. I'm not sure if it is an inherent limitation of zlib, something that needs to be fixed in zlib, or something that needs to be fixed in the python interface. If it is an inherent limitation, I'd like to characterise it a bit better before documenting it. If it is something that needs to be fixed in either zlib or the python interface, I'd like to fix it. Unfortunately, this is a bit beyond me at the moment, mainly in time, but also a bit in skill (need to read the python/C interfacing documentation). Maybe over the christmas holidays I'll get a chance to fix it. ------------------------------------------------------- Date: 2000-Dec-12 13:32 By: gvanrossum Comment: OK, assigned to Fred. You may ask Andrew what to write. :-) ------------------------------------------------------- Date: 2000-Dec-08 14:50 By: abo Comment: I'm not that sure I'm happy with it just being marked closed. AFAIKT, the implementation definitely doesn't do what the documentation says, so to save people like me time when they hit it, I'prefer the bug at least be assigned to documentation so that the limitation is documented. >From my reading of the documentation as it stands, the fact that there is more pending data in the decompressor should be indicated by it's "unused_data" attribute. The tests seem to show that "decompress()" is only processing 16K of compressed data each call, which would suggest that "unused_data" should contain the rest. However, in all my tests that attribute has always been empty. Perhaps the bug is in there somewhere? Another slight strangeness, even if "unused_data" did contain something, the only way to get it out is by feeding in more compressed data, or issuing a flush(), thus ending the decompression... I guess that since I've been bitten by this, it's up to me to fix it. I've got the source to 2.0 and I'll have a look and see if I can submit a patch. and I was coding this app in python to avoid coding in C :-) ------------------------------------------------------- Date: 2000-Dec-08 09:26 By: akuchling Comment: Python 2.0 demonstrates the problem, too. I'm not sure what this is: a zlibmodule bug/oversight or simply problems with zlib's API. Looking at zlib.h, it implies that you'd have to call inflate() with the flush parameter set to Z_SYNC_FLUSH to get the remaining data. Unfortunately this doesn't seem to help -- .flush() method doesn't support an argument, but when I patch zlibmodule.c to allow one, .flush(Z_SYNC_FLUSH) always fails with a -5: buffer error, perhaps because it expects there to be some new data. (The DEFAULTALLOC constant in zlibmodule.c is 16K, but this seems to be unrelated to the problem showing up with more than 16K of data, since changing DEFAULTALLOC to 32K or 1K makes no difference to the size of data at which the bug shows up.) In short, I have no idea what's at fault, or if it can or should be fixed. Unless you or someone else submits a patch, I'll just leave it alone, and mark this bug as closed and "Won't fix". ------------------------------------------------------- Date: 2000-Dec-08 07:44 By: gvanrossum Comment: I *think* this may have been fixed in Python 2.0. I'm assigning this to Andrew who can confirm that and close the bug report (if it is fixed). ------------------------------------------------------- Date: 2000-Dec-07 23:28 By: abo Comment: Argh... SF killed all my indents... sorry about that. You should be able to figure it out, but if not email me and I can send a copy. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=124981&group_id=5470 From noreply@sourceforge.net Tue Jan 23 05:03:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jan 2001 21:03:29 -0800 Subject: [Python-bugs-list] [Bug #129762] Python 2.1a1 build on Irix - Makefile syntax Message-ID: Bug #129762, was updated on 2001-Jan-22 21:03 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: pj99 Assigned to : nobody Summary: Python 2.1a1 build on Irix - Makefile syntax Details: A plain "./configure; make" of the new (Thanks!) alpha 1 of Python 2.1 fails on SGI's Irix 6.5.10, with a syntax error in Modules/Makefile.pre. The Make variable DLLLIBRARY is empty, causing the Makefile line: $(DLLLIBRARY): $(LIBRARY) to fail with the message: .../Python-2.1a1/Modules make: file `Makefile.pre' line 132: Syntax error *** Error code 1 (bu21) >From what I can tell, DLLLIBRARY is only useful on Cygnus. But I'd guess it would be better to set it to the same value as in LIBRARY on other platforms, rather than leave it empty, for those variants of make that don't like an empty target. In any case, the following change in Modules/Makefile.pre seems to workaround this problem and let the make continue, at least on Irix: Change line 108 from: DLLLIBRARY= to: DLLLIBRARY= $(LIBRARY) For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129762&group_id=5470 From noreply@sourceforge.net Tue Jan 23 09:28:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 01:28:02 -0800 Subject: [Python-bugs-list] [Bug #129788] cgi module. FieldStorage class returns keys blank fields. Message-ID: Bug #129788, was updated on 2001-Jan-23 01:28 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : nobody Summary: cgi module. FieldStorage class returns keys blank fields. Details: In module cgi.py The FieldStorage class returns keys for blank values even though the keep_blank_values property is set to 0 The problem lies in the parse_qsl method. The second last line of the function r.append((name, value)) should read if (len(value) or keep_blank_values): r.append((name, value)) I hope this can be corrected. Thanks For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129788&group_id=5470 From noreply@sourceforge.net Tue Jan 23 10:02:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 02:02:19 -0800 Subject: [Python-bugs-list] [Bug #128040] memory leak with multiple Py_Initialize/Py_Finalize calls Message-ID: Bug #128040, was updated on 2001-Jan-08 07:00 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: pbmtl Assigned to : bwarsaw Summary: memory leak with multiple Py_Initialize/Py_Finalize calls Details: I run script that use the win32 extension embedded in a server. When I call the Py_Finalize method, the memory is not free completely. Each time I run a script, my server uses more and more memory. I think the Patch #101713 talk about this problem. It seems that python have problem handling multiple Py_Initialize and Py_Finalise when extension are used. Follow-Ups: Date: 2001-Jan-23 02:02 By: tregnago Comment: In Borland C++, under MSWin, we have a tool called CodeGuard that it's very useful to check out this kind of problems. Can't you simply do a Python debug session with a similar tool? ------------------------------------------------------- Date: 2001-Jan-19 15:11 By: gvanrossum Comment: One for Barry and Insure++! ------------------------------------------------------- Date: 2001-Jan-10 08:59 By: gvanrossum Comment: I agree with Mark that in the past we have been lax in addressing these kinds of problems. I do wish to fix these in the future! It's just hard to find all the leaks. In the past we had reports where a simple loop calling Py_Initialize() and Py_Finalize() with nothing in between would leak; we've fixed these. But now if you put real work in between it still seems to leak. I'll see if I can check in a test program in the Demo tree which Barry can then work on using Insure++. pbmtl, when you write that "the call to PyEval_CallObject will return an error", can you submit a separate bug report for that with enough details (e.g. C source code) so that we can reproduce the problem? This seems to be a separate bug, unrelated to leakage! ------------------------------------------------------- Date: 2001-Jan-10 06:17 By: pbmtl Comment: I agree with you that it's not that important when script are executed using PythonWin for example, because when PythonWin is closed, the memory is recover. But if you use python embedded in a server on a remote computer that is never supposed to be stopped, it's a real problem. The memory usage increase rapidly, Hundreds KB at each execution in my case. In fact, I can't call PyInitialize and PyFinalize for each script because if I do, the second script to be executed will not work correctly (the call to PyEval_CallObject will return an error). I use the Py_NewInterpreter and the Py_EndInterpreter. For my part, I think the script virtual machine should be responsable of the memory created by the scripts. Otherwise, there is no garanty that the PyFinalyze will free the memory correctly. Thanks ------------------------------------------------------- Date: 2001-Jan-09 21:20 By: tim_one Comment: Thank you, Mark! Since nobody is going to volunteer to do all this stuff, and everyone else will try to stop them if they did , I reassigned it to Guido -- it's never going to get done if he doesn't push for it (and if he doesn't think it's worth the effort, that's fine too, but that's his call). ------------------------------------------------------- Date: 2001-Jan-09 17:11 By: mhammond Comment: I dont believe this is Windows specific, nor specific to the Win32 extensions. I can confirm that Python does leak with multiple Init/Terms, as I had to change the COM extensions to only initialize once (and hence never finalize). It is definitely related to the referenced patch (#101713) This has been raised before, but there doesnt appear much enthusiasm for a fix. As far as I can tell, it would involve having Py_Finalize() correctly release _all_ memory allocated by Py_Initialize(). However, I have seen numerous people state that "one off" allocations that are not freed are not worth finding and freeing - however, if this bug wants a fix, then we must track them all down. I further note that the problem is not only in the Python core, but in extension modules. Modules need a reliable way to be told that Python is finalizing so they can free their own "one off" allocations. Various hacks have been proposed for this (eg, rely on ref-count semantics to ensure that a special object is destroyed as the module dict is cleared) but nothing "reasonable" has been proposed. Really not sure what I can do here. I am willing to do my bit in patching up the leaks, but would want a (fuzzy) commitment from python-dev that I wouldnt be doing it alone, and that it is seen as important. I have updated the bug description and platform appropriately, but haven't reallocated a new person. ------------------------------------------------------- Date: 2001-Jan-09 14:38 By: tim_one Comment: Reassigned to MarkH. Mark, sound familiar? ------------------------------------------------------- Date: 2001-Jan-08 18:02 By: gvanrossum Comment: Assigned to Tim. First task would be to request needed infromation from submitter. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128040&group_id=5470 From noreply@sourceforge.net Tue Jan 23 10:18:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 02:18:09 -0800 Subject: [Python-bugs-list] [Bug #128040] memory leak with multiple Py_Initialize/Py_Finalize calls Message-ID: Bug #128040, was updated on 2001-Jan-08 07:00 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: pbmtl Assigned to : bwarsaw Summary: memory leak with multiple Py_Initialize/Py_Finalize calls Details: I run script that use the win32 extension embedded in a server. When I call the Py_Finalize method, the memory is not free completely. Each time I run a script, my server uses more and more memory. I think the Patch #101713 talk about this problem. It seems that python have problem handling multiple Py_Initialize and Py_Finalise when extension are used. Follow-Ups: Date: 2001-Jan-23 02:18 By: tim_one Comment: tregnago, that's what Insure++ is. ------------------------------------------------------- Date: 2001-Jan-23 02:02 By: tregnago Comment: In Borland C++, under MSWin, we have a tool called CodeGuard that it's very useful to check out this kind of problems. Can't you simply do a Python debug session with a similar tool? ------------------------------------------------------- Date: 2001-Jan-19 15:11 By: gvanrossum Comment: One for Barry and Insure++! ------------------------------------------------------- Date: 2001-Jan-10 08:59 By: gvanrossum Comment: I agree with Mark that in the past we have been lax in addressing these kinds of problems. I do wish to fix these in the future! It's just hard to find all the leaks. In the past we had reports where a simple loop calling Py_Initialize() and Py_Finalize() with nothing in between would leak; we've fixed these. But now if you put real work in between it still seems to leak. I'll see if I can check in a test program in the Demo tree which Barry can then work on using Insure++. pbmtl, when you write that "the call to PyEval_CallObject will return an error", can you submit a separate bug report for that with enough details (e.g. C source code) so that we can reproduce the problem? This seems to be a separate bug, unrelated to leakage! ------------------------------------------------------- Date: 2001-Jan-10 06:17 By: pbmtl Comment: I agree with you that it's not that important when script are executed using PythonWin for example, because when PythonWin is closed, the memory is recover. But if you use python embedded in a server on a remote computer that is never supposed to be stopped, it's a real problem. The memory usage increase rapidly, Hundreds KB at each execution in my case. In fact, I can't call PyInitialize and PyFinalize for each script because if I do, the second script to be executed will not work correctly (the call to PyEval_CallObject will return an error). I use the Py_NewInterpreter and the Py_EndInterpreter. For my part, I think the script virtual machine should be responsable of the memory created by the scripts. Otherwise, there is no garanty that the PyFinalyze will free the memory correctly. Thanks ------------------------------------------------------- Date: 2001-Jan-09 21:20 By: tim_one Comment: Thank you, Mark! Since nobody is going to volunteer to do all this stuff, and everyone else will try to stop them if they did , I reassigned it to Guido -- it's never going to get done if he doesn't push for it (and if he doesn't think it's worth the effort, that's fine too, but that's his call). ------------------------------------------------------- Date: 2001-Jan-09 17:11 By: mhammond Comment: I dont believe this is Windows specific, nor specific to the Win32 extensions. I can confirm that Python does leak with multiple Init/Terms, as I had to change the COM extensions to only initialize once (and hence never finalize). It is definitely related to the referenced patch (#101713) This has been raised before, but there doesnt appear much enthusiasm for a fix. As far as I can tell, it would involve having Py_Finalize() correctly release _all_ memory allocated by Py_Initialize(). However, I have seen numerous people state that "one off" allocations that are not freed are not worth finding and freeing - however, if this bug wants a fix, then we must track them all down. I further note that the problem is not only in the Python core, but in extension modules. Modules need a reliable way to be told that Python is finalizing so they can free their own "one off" allocations. Various hacks have been proposed for this (eg, rely on ref-count semantics to ensure that a special object is destroyed as the module dict is cleared) but nothing "reasonable" has been proposed. Really not sure what I can do here. I am willing to do my bit in patching up the leaks, but would want a (fuzzy) commitment from python-dev that I wouldnt be doing it alone, and that it is seen as important. I have updated the bug description and platform appropriately, but haven't reallocated a new person. ------------------------------------------------------- Date: 2001-Jan-09 14:38 By: tim_one Comment: Reassigned to MarkH. Mark, sound familiar? ------------------------------------------------------- Date: 2001-Jan-08 18:02 By: gvanrossum Comment: Assigned to Tim. First task would be to request needed infromation from submitter. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128040&group_id=5470 From noreply@sourceforge.net Tue Jan 23 15:28:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 07:28:12 -0800 Subject: [Python-bugs-list] [Bug #129810] Memore leak in pickle and cPickle Message-ID: Bug #129810, was updated on 2001-Jan-23 07:28 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: Irreproducible Priority: 5 Submitted by: vlk Assigned to : nobody Summary: Memore leak in pickle and cPickle Details: # When Pickler.object is used for dump typles into file and Unpickler for # load from files. A loaded object are not garbage collected. # When function dump(object,file) is used Unpickler works fine. # Problem is in pickle and cPickle module # tested on Python 2.0 Red Hat Linux 6.2 import cPickle #import pickle import gc f=open("xxx","w") pic=cPickle.Pickler(f,1) # ERROR #pic=pickle.Pickler(f,1) # ERROR for i in range(100): #cPickle.dump(([long(i),long(i),long(i),long(i)],i),f) # this is OK #pickle.dump(([long(i),long(i),long(i),long(i)],i),f) # this is OK pic.dump(([long(i),long(i),long(i),long(i)],i)) # Memory leak f.close() gc.set_debug(gc.DEBUG_STATS) f=open("xxx","r") u=cPickle.Unpickler(f) try: while 1: gc.collect() print u.load() except EOFError: pass f.close() For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129810&group_id=5470 From noreply@sourceforge.net Tue Jan 23 16:35:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 08:35:51 -0800 Subject: [Python-bugs-list] [Bug #124981] zlib decompress of sync-flushed data fails Message-ID: Bug #124981, was updated on 2000-Dec-07 23:25 Here is a current snapshot of the bug. Project: Python Category: Extension Modules Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: abo Assigned to : akuchling Summary: zlib decompress of sync-flushed data fails Details: I'm not sure if this is just an undocumented limitation or a genuine bug. I'm using python 1.5.2 on winNT. A single decompress of a large amount (16K+) of compressed data that has been sync-flushed fails to produce all the data up to the sync-flush. The data remains inside the decompressor untill further compressed data or a final flush is issued. Note that the 'unused_data' attribute does not show that there is further data in the decompressor to process (it shows ''). A workaround is to decompress the data in smaller chunks. Note that compressing data in smaller chunks is not required, as the problem is in the decompressor, not the compressor. The following code demonstrates the problem, and raises an exception when the compressed data reaches 17K; from zlib import * from random import * # create compressor and decompressor c=compressobj(9) d=decompressobj() # try data sizes of 1-63K for l in range(1,64): # generate random data stream a='' for i in range(l*1024): a=a+chr(randint(0,255)) # compress, sync-flush, and decompress t=d.decompress(c.compress(a)+c.flush(Z_SYNC_FLUSH)) # if decompressed data is different to input data, barf, if len(t) != len(a): print len(a),len(t),len(d.unused_data) raise error Follow-Ups: Date: 2001-Jan-23 08:35 By: abo Comment: OK, patch submitted. Fire away :-) overall the code is fairly ugly, but not too bad. I dunno if it warrents a complete re-write, but certainly there is a heap of redundancy that could be cleaned up. It would be a nice simple project for someone with time, but that ain't me :-) ------------------------------------------------------- Date: 2001-Jan-22 20:16 By: akuchling Comment: Yay! Please submit your patch using the Patch Manager on SourceForge so that we can look at it and discuss it. You can submit it as one big patch; obviously correct changes can be applied right away causing the patch to shrink, and disentangling the changes shouldn't be too difficult. The zlib module is really ugly code, and could probably do with a restructuring; I've wondered before if it would be worth trashing it and rewriting from scratch with the same API. Maybe for 2.2... If you want to be ambitious and do a more serious restructuring, feel free to do so, but it probably wouldn't get into 2.1. And the bug has been reclassified under Extension Modules. ------------------------------------------------------- Date: 2001-Jan-22 15:34 By: abo Comment: Oh yeah, since I now know that it's definitely a zlibmodule.c bug, not a documentation problem, you can probably change this bug's catagory from "Documentation" to something more appropriate. ------------------------------------------------------- Date: 2001-Jan-22 15:31 By: abo Comment: I've got a patch that I'm currently testing. When it's ready how do you want me to submit it; through the SF patch manager? I've analysed the code pretty extensively by now, and I believe I found a few other potential problems (though I haven't bothered to create test cases to trigger them). The original problem I found could affect compression as well as decompression. There were some memory allocations that didn't raise exceptions if they failed, and potential memory leaks when exceptions did occur. Also, deflateEnd would be called twice in a decompression object if it was flushed before it was destroyed. The strange thing is compression, decompression, and both flush routines perform basicly the same function, but they were all structured totally differently (like they had been written by different people). Also, there didn't seem to be any consistancy in the coding style so I didn't know what style to use. I tried to resist fixing more than the initial problem I identified, but in the end couldn't help myself. As an aside, I noticed that the 2.0 version of zlibmodule.c is Python 2.0 specific (It wouldn't work on my 1.5.2 system so I had to compile 2.0 to test my patch). How do you want me to submit my patch; one big patch, or several smaller ones for each fix? I have been using prcs to track my changes, but I have been a bit lax in checking in each small change, so creating seperate patches will take a little work. ------------------------------------------------------- Date: 2001-Jan-20 06:22 By: abo Comment: OK, Christmas is over, and I didn't really get a chance to look at it much. However, some preliminary testing of the zlib library suggests that it is _not_ in zlib. A c program that does the same compress/decompress of random data using steadily increasing block sizes does not show the same fault... I've noticed what might be a potential problem in the inflateInit2 call in PyZlib_decompressobj. The next_in and avail_in are not being initialized before it's called. The zlib manual says they should be init'ed because deflateInit will attempt to determine the compression method if it can. I'm not sure why this hasn't tripped already... does PyObject_New zero memory when it allocates things? I also think I've found the main problem... the PyZlib_objdecompress routine's main decompression loop thinks decompression is compelete when all available input has been processed. However, it is possible that all available input has been processed but there is more pending output. The code as it stands does correctly allocate more space when this occurs, but the loop terminates without calling inflate one more time. I'm putting together a patch tomorrow. Right now I'm going to bed... ------------------------------------------------------- Date: 2000-Dec-20 15:17 By: abo Comment: I have had a look at this in more detail (Python C interfacing is actually pretty easy :-). I dunno whether to go into details here, but I have noticed that inflate is being called with Z_NO_FLUSH when the zlib docs suggest Z_SYNC_FLUSH or Z_FINISH. However, the zlib implementation only treats Z_FINISH differently, so this should not make a difference (but it might in future versions of zlib). As you have said, .unused_data will only contain data if something is appended to a complete compressed object in the stream fed to a decompressor. Perhaps the docs need something to clarify this, perhaps in the form of an example? I am going to write some test progs to see if it's in zlib. At this stage I suspect that it is, and I'm hoping over christmas to get a patch done. ------------------------------------------------------- Date: 2000-Dec-19 11:48 By: akuchling Comment: .unused_data is really a red herring; the PyZlib_objdecompress() loops until zst->avail_in is zero, so .unused_data must always be zero by definition. (The attribute is there to support gzip-format files that may contain multiple compressed streams concatenated together.) I still have no idea what the documentation should say; "don't pass more than 16K of compressed data when you're expecting a sync-flush." I can't see a way to explain this coherently without a big long explanation that will confuse people who don't care about this problem. (Add a special note, or known bugs subsection, maybe?) A simple C test program should be written, in order to check if it's the zlib library itself that's doing this. ------------------------------------------------------- Date: 2000-Dec-18 20:13 By: fdrake Comment: Andrew, please summarize what doc changes are needed, or make the changes (whichever is easier for you is fine). ------------------------------------------------------- Date: 2000-Dec-12 15:18 By: abo Comment: Further comments... After looking at the C code, a few things became clear; I need to read more about C/Python interfacing, and the "unused_data" attribute will only contain data if additional data is fed to a de-compressor at the end of a complete compressed stream. The purpose of the "unused_data" attribute is not clear in the documentation, so that should probably be clarified (mind you, I am looking at pre-2.0 docs so maybe it already has?). The failure to produce all data up to a sync-flush is something else... I'm still looking into it. I'm not sure if it is an inherent limitation of zlib, something that needs to be fixed in zlib, or something that needs to be fixed in the python interface. If it is an inherent limitation, I'd like to characterise it a bit better before documenting it. If it is something that needs to be fixed in either zlib or the python interface, I'd like to fix it. Unfortunately, this is a bit beyond me at the moment, mainly in time, but also a bit in skill (need to read the python/C interfacing documentation). Maybe over the christmas holidays I'll get a chance to fix it. ------------------------------------------------------- Date: 2000-Dec-12 13:32 By: gvanrossum Comment: OK, assigned to Fred. You may ask Andrew what to write. :-) ------------------------------------------------------- Date: 2000-Dec-08 14:50 By: abo Comment: I'm not that sure I'm happy with it just being marked closed. AFAIKT, the implementation definitely doesn't do what the documentation says, so to save people like me time when they hit it, I'prefer the bug at least be assigned to documentation so that the limitation is documented. >From my reading of the documentation as it stands, the fact that there is more pending data in the decompressor should be indicated by it's "unused_data" attribute. The tests seem to show that "decompress()" is only processing 16K of compressed data each call, which would suggest that "unused_data" should contain the rest. However, in all my tests that attribute has always been empty. Perhaps the bug is in there somewhere? Another slight strangeness, even if "unused_data" did contain something, the only way to get it out is by feeding in more compressed data, or issuing a flush(), thus ending the decompression... I guess that since I've been bitten by this, it's up to me to fix it. I've got the source to 2.0 and I'll have a look and see if I can submit a patch. and I was coding this app in python to avoid coding in C :-) ------------------------------------------------------- Date: 2000-Dec-08 09:26 By: akuchling Comment: Python 2.0 demonstrates the problem, too. I'm not sure what this is: a zlibmodule bug/oversight or simply problems with zlib's API. Looking at zlib.h, it implies that you'd have to call inflate() with the flush parameter set to Z_SYNC_FLUSH to get the remaining data. Unfortunately this doesn't seem to help -- .flush() method doesn't support an argument, but when I patch zlibmodule.c to allow one, .flush(Z_SYNC_FLUSH) always fails with a -5: buffer error, perhaps because it expects there to be some new data. (The DEFAULTALLOC constant in zlibmodule.c is 16K, but this seems to be unrelated to the problem showing up with more than 16K of data, since changing DEFAULTALLOC to 32K or 1K makes no difference to the size of data at which the bug shows up.) In short, I have no idea what's at fault, or if it can or should be fixed. Unless you or someone else submits a patch, I'll just leave it alone, and mark this bug as closed and "Won't fix". ------------------------------------------------------- Date: 2000-Dec-08 07:44 By: gvanrossum Comment: I *think* this may have been fixed in Python 2.0. I'm assigning this to Andrew who can confirm that and close the bug report (if it is fixed). ------------------------------------------------------- Date: 2000-Dec-07 23:28 By: abo Comment: Argh... SF killed all my indents... sorry about that. You should be able to figure it out, but if not email me and I can send a copy. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=124981&group_id=5470 From noreply@sourceforge.net Tue Jan 23 17:34:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 09:34:48 -0800 Subject: [Python-bugs-list] [Bug #129827] Mac OSX build of 2.1a needs "-traditional-cpp" Message-ID: Bug #129827, was updated on 2001-Jan-23 09:34 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: sdm7g Assigned to : nobody Summary: Mac OSX build of 2.1a needs "-traditional-cpp" Details: build of 2.1a1 fails on Mac OSX: compiling classobject.c generates a syntax error cc needs "-traditional-cpp" flag (This probably should have been in before, but changes to classobject uncovered the bug. ) -- Steve For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129827&group_id=5470 From noreply@sourceforge.net Tue Jan 23 17:42:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 09:42:47 -0800 Subject: [Python-bugs-list] [Bug #129829] 2.1a Mac OSX build fails on "-lm" switch Message-ID: Bug #129829, was updated on 2001-Jan-23 09:42 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: sdm7g Assigned to : nobody Summary: 2.1a Mac OSX build fails on "-lm" switch Details: The new setup.py system hardwires the -lm switch with "libraries=['m']" in several places (rather than getting switches from a config file) This breaks the Mac OSX/Darwin build as that system has no libm -- those functions are folded into the system framework. ( There's been some discussion on the Darwin dev. list of putting fake stub libraries into /usr/lib to solve this, but if it happens, it won't happen for a while. ) For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129829&group_id=5470 From noreply@sourceforge.net Tue Jan 23 17:54:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 09:54:08 -0800 Subject: [Python-bugs-list] [Bug #128040] memory leak with multiple Py_Initialize/Py_Finalize calls Message-ID: Bug #128040, was updated on 2001-Jan-08 07:00 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: pbmtl Assigned to : bwarsaw Summary: memory leak with multiple Py_Initialize/Py_Finalize calls Details: I run script that use the win32 extension embedded in a server. When I call the Py_Finalize method, the memory is not free completely. Each time I run a script, my server uses more and more memory. I think the Patch #101713 talk about this problem. It seems that python have problem handling multiple Py_Initialize and Py_Finalise when extension are used. Follow-Ups: Date: 2001-Jan-23 09:54 By: bwarsaw Comment: I took Guido's Demo/embed/loop.c test, compiled it with Insure, and ran a series of tests using a simple `pass' loop. There were definitely objects that got caught in cycles and never freed, but also didn't technically leak (in the sense that there were still C pointers to the blocks). There was a big problem with the exceptions.c module, and I've now fixed that. Now the loop.c test does not grow with each interation of the loop (modulo a few tiny leaks in Jeremy's still experimental symbol table stuff in the compiler). The interpreter still keeps some objects alive past Py_Finalize(), e.g. the interned strings dictionary, but those are never reallocated at the next Py_Initialize() so they should be fine. Closing this bug report. ------------------------------------------------------- Date: 2001-Jan-23 02:18 By: tim_one Comment: tregnago, that's what Insure++ is. ------------------------------------------------------- Date: 2001-Jan-23 02:02 By: tregnago Comment: In Borland C++, under MSWin, we have a tool called CodeGuard that it's very useful to check out this kind of problems. Can't you simply do a Python debug session with a similar tool? ------------------------------------------------------- Date: 2001-Jan-19 15:11 By: gvanrossum Comment: One for Barry and Insure++! ------------------------------------------------------- Date: 2001-Jan-10 08:59 By: gvanrossum Comment: I agree with Mark that in the past we have been lax in addressing these kinds of problems. I do wish to fix these in the future! It's just hard to find all the leaks. In the past we had reports where a simple loop calling Py_Initialize() and Py_Finalize() with nothing in between would leak; we've fixed these. But now if you put real work in between it still seems to leak. I'll see if I can check in a test program in the Demo tree which Barry can then work on using Insure++. pbmtl, when you write that "the call to PyEval_CallObject will return an error", can you submit a separate bug report for that with enough details (e.g. C source code) so that we can reproduce the problem? This seems to be a separate bug, unrelated to leakage! ------------------------------------------------------- Date: 2001-Jan-10 06:17 By: pbmtl Comment: I agree with you that it's not that important when script are executed using PythonWin for example, because when PythonWin is closed, the memory is recover. But if you use python embedded in a server on a remote computer that is never supposed to be stopped, it's a real problem. The memory usage increase rapidly, Hundreds KB at each execution in my case. In fact, I can't call PyInitialize and PyFinalize for each script because if I do, the second script to be executed will not work correctly (the call to PyEval_CallObject will return an error). I use the Py_NewInterpreter and the Py_EndInterpreter. For my part, I think the script virtual machine should be responsable of the memory created by the scripts. Otherwise, there is no garanty that the PyFinalyze will free the memory correctly. Thanks ------------------------------------------------------- Date: 2001-Jan-09 21:20 By: tim_one Comment: Thank you, Mark! Since nobody is going to volunteer to do all this stuff, and everyone else will try to stop them if they did , I reassigned it to Guido -- it's never going to get done if he doesn't push for it (and if he doesn't think it's worth the effort, that's fine too, but that's his call). ------------------------------------------------------- Date: 2001-Jan-09 17:11 By: mhammond Comment: I dont believe this is Windows specific, nor specific to the Win32 extensions. I can confirm that Python does leak with multiple Init/Terms, as I had to change the COM extensions to only initialize once (and hence never finalize). It is definitely related to the referenced patch (#101713) This has been raised before, but there doesnt appear much enthusiasm for a fix. As far as I can tell, it would involve having Py_Finalize() correctly release _all_ memory allocated by Py_Initialize(). However, I have seen numerous people state that "one off" allocations that are not freed are not worth finding and freeing - however, if this bug wants a fix, then we must track them all down. I further note that the problem is not only in the Python core, but in extension modules. Modules need a reliable way to be told that Python is finalizing so they can free their own "one off" allocations. Various hacks have been proposed for this (eg, rely on ref-count semantics to ensure that a special object is destroyed as the module dict is cleared) but nothing "reasonable" has been proposed. Really not sure what I can do here. I am willing to do my bit in patching up the leaks, but would want a (fuzzy) commitment from python-dev that I wouldnt be doing it alone, and that it is seen as important. I have updated the bug description and platform appropriately, but haven't reallocated a new person. ------------------------------------------------------- Date: 2001-Jan-09 14:38 By: tim_one Comment: Reassigned to MarkH. Mark, sound familiar? ------------------------------------------------------- Date: 2001-Jan-08 18:02 By: gvanrossum Comment: Assigned to Tim. First task would be to request needed infromation from submitter. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128040&group_id=5470 From noreply@sourceforge.net Tue Jan 23 17:56:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 09:56:32 -0800 Subject: [Python-bugs-list] [Bug #129832] 2.1a Mac OSX build fails on "-lm" switch Message-ID: Bug #129832, was updated on 2001-Jan-23 09:56 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: sdm7g Assigned to : nobody Summary: 2.1a Mac OSX build fails on "-lm" switch Details: The new setup.py system hardwires the -lm switch with "libraries=['m']" in several places (rather than getting switches from a config file) This breaks the Mac OSX/Darwin build as that system has no libm -- those functions are folded into the system framework. ( There's been some discussion on the Darwin dev. list of putting fake stub libraries into /usr/lib to solve this, but if it happens, it won't happen for a while. ) For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129832&group_id=5470 From noreply@sourceforge.net Tue Jan 23 17:57:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 09:57:17 -0800 Subject: [Python-bugs-list] [Bug #129833] 2.1a Mac OSX build fails on "-lm" switch Message-ID: Bug #129833, was updated on 2001-Jan-23 09:57 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: sdm7g Assigned to : nobody Summary: 2.1a Mac OSX build fails on "-lm" switch Details: The new setup.py system hardwires the -lm switch with "libraries=['m']" in several places (rather than getting switches from a config file) This breaks the Mac OSX/Darwin build as that system has no libm -- those functions are folded into the system framework. ( There's been some discussion on the Darwin dev. list of putting fake stub libraries into /usr/lib to solve this, but if it happens, it won't happen for a while. ) For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129833&group_id=5470 From noreply@sourceforge.net Tue Jan 23 18:01:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 10:01:09 -0800 Subject: [Python-bugs-list] [Bug #129833] 2.1a Mac OSX build fails on "-lm" switch Message-ID: Bug #129833, was updated on 2001-Jan-23 09:57 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: sdm7g Assigned to : nobody Summary: 2.1a Mac OSX build fails on "-lm" switch Details: The new setup.py system hardwires the -lm switch with "libraries=['m']" in several places (rather than getting switches from a config file) This breaks the Mac OSX/Darwin build as that system has no libm -- those functions are folded into the system framework. ( There's been some discussion on the Darwin dev. list of putting fake stub libraries into /usr/lib to solve this, but if it happens, it won't happen for a while. ) Follow-Ups: Date: 2001-Jan-23 10:01 By: sdm7g Comment: I only submitted this bug once, but for some reason, reading it in the browser and returning to the buglist seems to cause it to be duplicated! --Steve. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129833&group_id=5470 From noreply@sourceforge.net Tue Jan 23 18:52:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 10:52:25 -0800 Subject: [Python-bugs-list] [Bug #129840] IDLE needs to print ! Message-ID: Bug #129840, was updated on 2001-Jan-23 10:52 Here is a current snapshot of the bug. Project: Python Category: IDLE Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Submitted by: cdoutri Assigned to : nobody Summary: IDLE needs to print ! Details: It'd be really nice if idle had a print function, all these nice colors got to be printed ! or at least a postscript output would be nice. Thanks, C. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129840&group_id=5470 From noreply@sourceforge.net Tue Jan 23 19:10:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 11:10:43 -0800 Subject: [Python-bugs-list] [Bug #129841] 'make install' needs write access to build directory Message-ID: Bug #129841, was updated on 2001-Jan-23 11:10 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: loewis Assigned to : nobody Summary: 'make install' needs write access to build directory Details: [submitted by David Highley ] I experienced the following types of installation build problems with the Python 2.0 release. Not all building and modification of files is completed int the build step. When doing the install as a root user and the Python code tree is NFS mounted the install proess fails. I also needed to modify the Modules/Makefile to pass ld a run time path so that when the python executable is invoked it can find the tcl/tk libraries in /usr/local/lib. This install was on a Solaris 8 system. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129841&group_id=5470 From noreply@sourceforge.net Tue Jan 23 19:38:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 11:38:28 -0800 Subject: [Python-bugs-list] [Bug #129843] MacOSX case insensitivity bug resurfaces Message-ID: Bug #129843, was updated on 2001-Jan-23 11:38 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: nobody Assigned to : nobody Summary: MacOSX case insensitivity bug resurfaces Details: The case insensitivity with HFS+ MacOSX bug has resurfaced with the 2.1a1 release. import FCNTL; import fcntl or import termios; import TERMIOS (and maybe others) will crash due to duplicate symbols as it tries to import the same shared libraries twice instead ot importing the .py file for one of them. This was handled in 2.0 by building those modules as built-in, not shared. ( I haven't yet figured out the new setup.py system. Maybe it should be fixed in import. ) -- Steve M. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129843&group_id=5470 From noreply@sourceforge.net Tue Jan 23 20:48:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 12:48:02 -0800 Subject: [Python-bugs-list] [Bug #129179] Memory leak on repeated reloads Message-ID: Bug #129179, was updated on 2001-Jan-17 13:57 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Closed Resolution: Works For Me Bug Group: None Priority: 5 Submitted by: cgw Assigned to : bwarsaw Summary: Memory leak on repeated reloads Details: boo.py: ========== Class Boo: pass a = [1] b = Boo() def testit(): try: divmod(a,b) except TypeError, msg: print msg testit() =========== import boo while 1: reload(boo) Follow-Ups: Date: 2001-Jan-23 12:48 By: bwarsaw Comment: I've run this test case through Insure and I do not see any memory growth when running the reload loop different number of times. Same memory usage profile for 1x, 2x, 25x through loop. Closing this bug report unless a better test case can be provided. ------------------------------------------------------- Date: 2001-Jan-19 22:36 By: bwarsaw Comment: Running top while executing this program shows no memory growth using the current CVS snapshot as of 20-Jan-2001, 1:34am EST. RH6.1. Charles, can you verify? If it's growing for you, I'll run it through Insure (but I'm currently Insuring another memory leak, which is why I've only done the top test for now). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129179&group_id=5470 From noreply@sourceforge.net Tue Jan 23 21:18:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 13:18:49 -0800 Subject: [Python-bugs-list] [Bug #129854] old PYTHONPATH confuses setup.py [build|install] Message-ID: Bug #129854, was updated on 2001-Jan-23 13:18 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: pj99 Assigned to : nobody Summary: old PYTHONPATH confuses setup.py [build|install] Details: Some of the Makefile actions set the value of PYTHONPATH to the python libraries being built, intentionally over- riding the ambient value, such as in the Makefile line: 349: export PYTHONPATH; PYTHONPATH="`pwd`/Lib"; \ But the lines that invoke setup.py: 163: ./python$(EXE) $(srcdir)/setup.py build 431: ./python$(EXE) $(srcdir)/setup.py install don't override PYTHONPATH, and when I first tried to build and install Python 2.1, on a system configured to be running Python 2.0, these setup lines failed, with the complaint: AttributeError: 'distutils.sysconfig' module has no attribute 'set_python_build' which is a sensible complaint, given that 2.0 sysconfig lacks 'set_python_build', 2.1 has it, and setup.py invokes it. Would it make sense to be overriding PYTHONPATH for these lines of the Makefile as well? For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129854&group_id=5470 From noreply@sourceforge.net Tue Jan 23 21:48:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 13:48:08 -0800 Subject: [Python-bugs-list] [Bug #121706] exceptions module cannot be imported in two interpreters Message-ID: Bug #121706, was updated on 2000-Nov-05 15:40 Here is a current snapshot of the bug. Project: Python Category: Extension Modules Status: Closed Resolution: Fixed Bug Group: None Priority: 6 Submitted by: mhagger Assigned to : bwarsaw Summary: exceptions module cannot be imported in two interpreters Details: If the exceptions module is imported in two separate interpreters within one process, the second import fails. The program below fails when linked with Python 2.0 on RedHat Linux 6.2 with the following message: Traceback (most recent call last): File "", line 1, in ? ImportError: Cannot re-init internal module exceptions Program source: #include char *cmd = "import exceptions"; int main() { Py_Initialize(); PyEval_InitThreads(); PyRun_SimpleString(cmd); Py_EndInterpreter(PyThreadState_Get()); Py_NewInterpreter(); PyRun_SimpleString(cmd); Py_Finalize(); } If the command is changed to "import sys" or "import os" there is no error message. Follow-Ups: Date: 2001-Jan-23 13:48 By: bwarsaw Comment: Fixed by including the exception module's init function in config.c.in. (version 1.73). ------------------------------------------------------- Date: 2001-Jan-18 19:47 By: gvanrossum Comment: Barry, please look into this! ------------------------------------------------------- Date: 2000-Nov-13 12:14 By: gvanrossum Comment: Verified. For Barry to investigate! ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=121706&group_id=5470 From noreply@sourceforge.net Wed Jan 24 01:01:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 17:01:18 -0800 Subject: [Python-bugs-list] [Bug #116547] test_poll.py fails on SPARCstation LX under Red Hat 5.2 Message-ID: Bug #116547, was updated on 2000-Oct-10 15:02 Here is a current snapshot of the bug. Project: Python Category: Extension Modules Status: Closed Resolution: None Bug Group: Irreproducible Priority: 1 Submitted by: holdenweb Assigned to : akuchling Summary: test_poll.py fails on SPARCstation LX under Red Hat 5.2 Details: Attached is a traceback from running the test manually. Running poll test 1 This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. Traceback (most recent call last): File "./Lib/test/test_poll.py", line 171, in ? test_poll1() File "./Lib/test/test_poll.py", line 65, in test_poll1 poll_unit_tests() File "./Lib/test/test_poll.py", line 77, in poll_unit_tests r = p.poll() select.error: (9, 'Bad file descriptor') Follow-Ups: Date: 2001-Jan-23 17:01 By: akuchling Comment: I'm closing this bug report; I have no access to the platform in question, and therefore no way to debug the problem or propose a fix. If the original reporter can provide a patch, it'll certainly be considered, but that's about all I can do. ------------------------------------------------------- Date: 2000-Dec-12 13:01 By: gvanrossum Comment: Is this worth keeping open? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=116547&group_id=5470 From noreply@sourceforge.net Wed Jan 24 01:02:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 17:02:25 -0800 Subject: [Python-bugs-list] [Bug #119709] POLLIN undefined Message-ID: Bug #119709, was updated on 2000-Oct-29 16:20 Here is a current snapshot of the bug. Project: Python Category: Build Status: Closed Resolution: None Bug Group: Platform-specific Priority: 1 Submitted by: jsfrank Assigned to : akuchling Summary: POLLIN undefined Details: I use: Slackware96 Linux 2.0.0 gcc 2.7.2 glibc2 PC/i486 And I try to install Python-2.0.tar.gz package. I use default Modules/Setup. When run: #./configure #make gcc tells me in Modules/selectmodule.c, begins from the 345 line, POLLIN undeclared,... Every POLL* name follows are all undeclared. Which header file lost? poll.h? Or something wrong? Thanks. Follow-Ups: Date: 2001-Jan-23 17:02 By: akuchling Comment: I'm closing this bug report; I have no access to the platform in question, and therefore no way to debug the problem or propose a fix. If the original reporter can provide a patch, it'll certainly be considered, but that's about all I can do. ------------------------------------------------------- Date: 2000-Dec-12 13:19 By: gvanrossum Comment: Did the user ever reply? If not, let's close this one. There are too many potential configuration problems lingering around in the Bugs list that are probably not bugs in Python... ------------------------------------------------------- Date: 2000-Nov-03 12:09 By: akuchling Comment: Can you provide the exact output from make, please, and a copy of the config.h generated by Python's configure script? It's possible that both HAVE_POLL_H and HAVE_POLL are defined but the header files are wrong in some way that POLLIN isn't defined. You can provide the output and config.h via private e-mail to akuchlin@mems-exchange.org. ------------------------------------------------------- Date: 2000-Nov-02 20:16 By: fdrake Comment: I think this has been fixed post-2.0, but I'm not sure. Assigned to Andrew since he'll know and, if it's not fixed, will be the one to do so. ;-) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=119709&group_id=5470 From noreply@sourceforge.net Wed Jan 24 01:03:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 17:03:52 -0800 Subject: [Python-bugs-list] [Bug #115617] poll problem on Linux 2.0.38, glibc 2.0.7 Message-ID: Bug #115617, was updated on 2000-Sep-28 14:37 Here is a current snapshot of the bug. Project: Python Category: Extension Modules Status: Closed Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: akuchling Assigned to : akuchling Summary: poll problem on Linux 2.0.38, glibc 2.0.7 Details: Originally reported by Neil Schemenauer in a comment in patch #101682: After this patch the selectmodule compiles but test_poll fails with: File "Lib/test/test_poll.py", line 77, in poll_unit_tests r = p.poll() error: (9, 'Bad file descriptor') The kernel is 2.0.38 if that makes a difference. Follow-Ups: Date: 2001-Jan-23 17:03 By: akuchling Comment: I'm closing this bug report; I have no access to the platform in question, and therefore no way to debug the problem or propose a fix. If the original reporter can provide a patch, it'll certainly be considered, but that's about all I can do. ------------------------------------------------------- Date: 2000-Sep-29 01:32 By: jpettit Comment: I get the exact same result on OpenBSD 2.5 with the most current CVS version. On OpenBSD 2.7 (this has Python 2.0b2 installed), I get: test_support.TestSkipped: select.poll not defined -- skipping test_poll Both versions of OpenBSD appear to support the poll mechanism. ------------------------------------------------------- Date: 2000-Sep-29 01:31 By: jpettit Comment: I get the exact same result on OpenBSD 2.5 with the most current CVS version. On OpenBSD 2.7 (this has Python 2.0b2 installed), I get: test_support.TestSkipped: select.poll not defined -- skipping test_poll Both versions of OpenBSD appear to support the poll mechanism. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=115617&group_id=5470 From noreply@sourceforge.net Wed Jan 24 02:40:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 18:40:30 -0800 Subject: [Python-bugs-list] [Bug #129840] IDLE needs to print ! Message-ID: Bug #129840, was updated on 2001-Jan-23 10:52 Here is a current snapshot of the bug. Project: Python Category: IDLE Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Submitted by: cdoutri Assigned to : gvanrossum Summary: IDLE needs to print ! Details: It'd be really nice if idle had a print function, all these nice colors got to be printed ! or at least a postscript output would be nice. Thanks, C. Follow-Ups: Date: 2001-Jan-23 18:40 By: gvanrossum Comment: The kind folks from reportlab.com once contributed a printing function. it was kind of slow though. But maybe it should still be added. I think I have it somewhere still. The problem is the licensing (it's not relesed under the same license as Python itself). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129840&group_id=5470 From noreply@sourceforge.net Wed Jan 24 02:46:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 18:46:14 -0800 Subject: [Python-bugs-list] [Bug #129843] MacOSX case insensitivity bug resurfaces Message-ID: Bug #129843, was updated on 2001-Jan-23 11:38 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: nobody Assigned to : gvanrossum Summary: MacOSX case insensitivity bug resurfaces Details: The case insensitivity with HFS+ MacOSX bug has resurfaced with the 2.1a1 release. import FCNTL; import fcntl or import termios; import TERMIOS (and maybe others) will crash due to duplicate symbols as it tries to import the same shared libraries twice instead ot importing the .py file for one of them. This was handled in 2.0 by building those modules as built-in, not shared. ( I haven't yet figured out the new setup.py system. Maybe it should be fixed in import. ) -- Steve M. Follow-Ups: Date: 2001-Jan-23 18:46 By: gvanrossum Comment: You can make them built-in by adding them to the Modules/Setup file -- that file still exists and works as before, it's just that most modules aren't listed there any more. See also the discussion at this patch: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 The long-term solution is to get rid of the FCNTL and TERMIOS modules and include the symbols in the extension -- as has been done for e.g. the socket module. (Some of the symbols of FCNTL are already exported by fcntl or os.) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129843&group_id=5470 From noreply@sourceforge.net Wed Jan 24 03:26:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 19:26:55 -0800 Subject: [Python-bugs-list] [Bug #129832] 2.1a Mac OSX build fails on "-lm" switch Message-ID: Bug #129832, was updated on 2001-Jan-23 09:56 Here is a current snapshot of the bug. Project: Python Category: Build Status: Closed Resolution: Duplicate Bug Group: Platform-specific Priority: 5 Submitted by: sdm7g Assigned to : akuchling Summary: 2.1a Mac OSX build fails on "-lm" switch Details: The new setup.py system hardwires the -lm switch with "libraries=['m']" in several places (rather than getting switches from a config file) This breaks the Mac OSX/Darwin build as that system has no libm -- those functions are folded into the system framework. ( There's been some discussion on the Darwin dev. list of putting fake stub libraries into /usr/lib to solve this, but if it happens, it won't happen for a while. ) Follow-Ups: Date: 2001-Jan-23 19:26 By: akuchling Comment: Duplicate of #129833; closing. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129832&group_id=5470 From noreply@sourceforge.net Wed Jan 24 03:27:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 19:27:11 -0800 Subject: [Python-bugs-list] [Bug #129829] 2.1a Mac OSX build fails on "-lm" switch Message-ID: Bug #129829, was updated on 2001-Jan-23 09:42 Here is a current snapshot of the bug. Project: Python Category: Build Status: Closed Resolution: Duplicate Bug Group: Platform-specific Priority: 5 Submitted by: sdm7g Assigned to : akuchling Summary: 2.1a Mac OSX build fails on "-lm" switch Details: The new setup.py system hardwires the -lm switch with "libraries=['m']" in several places (rather than getting switches from a config file) This breaks the Mac OSX/Darwin build as that system has no libm -- those functions are folded into the system framework. ( There's been some discussion on the Darwin dev. list of putting fake stub libraries into /usr/lib to solve this, but if it happens, it won't happen for a while. ) Follow-Ups: Date: 2001-Jan-23 19:27 By: akuchling Comment: Duplicate of #129833; closing. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129829&group_id=5470 From noreply@sourceforge.net Wed Jan 24 03:28:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 19:28:10 -0800 Subject: [Python-bugs-list] [Bug #129810] Memore leak in pickle and cPickle Message-ID: Bug #129810, was updated on 2001-Jan-23 07:28 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: Irreproducible Priority: 5 Submitted by: vlk Assigned to : bwarsaw Summary: Memore leak in pickle and cPickle Details: # When Pickler.object is used for dump typles into file and Unpickler for # load from files. A loaded object are not garbage collected. # When function dump(object,file) is used Unpickler works fine. # Problem is in pickle and cPickle module # tested on Python 2.0 Red Hat Linux 6.2 import cPickle #import pickle import gc f=open("xxx","w") pic=cPickle.Pickler(f,1) # ERROR #pic=pickle.Pickler(f,1) # ERROR for i in range(100): #cPickle.dump(([long(i),long(i),long(i),long(i)],i),f) # this is OK #pickle.dump(([long(i),long(i),long(i),long(i)],i),f) # this is OK pic.dump(([long(i),long(i),long(i),long(i)],i)) # Memory leak f.close() gc.set_debug(gc.DEBUG_STATS) f=open("xxx","r") u=cPickle.Unpickler(f) try: while 1: gc.collect() print u.load() except EOFError: pass f.close() Follow-Ups: Date: 2001-Jan-23 19:28 By: gvanrossum Comment: Barry, can you look into this? I would first see if this is really reproducable without using Insure++; somehow it looks a bit fishy. Could also be fixed in 2.1 because now modules participate in gc. Or could have to do with a __del__? Also, I doubt the claim that this is a leak with both pickle and cPickle. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129810&group_id=5470 From noreply@sourceforge.net Wed Jan 24 03:32:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 19:32:16 -0800 Subject: [Python-bugs-list] [Bug #129833] 2.1a Mac OSX build fails on "-lm" switch Message-ID: Bug #129833, was updated on 2001-Jan-23 09:57 Here is a current snapshot of the bug. Project: Python Category: Build Status: Closed Resolution: Fixed Bug Group: Platform-specific Priority: 5 Submitted by: sdm7g Assigned to : akuchling Summary: 2.1a Mac OSX build fails on "-lm" switch Details: The new setup.py system hardwires the -lm switch with "libraries=['m']" in several places (rather than getting switches from a config file) This breaks the Mac OSX/Darwin build as that system has no libm -- those functions are folded into the system framework. ( There's been some discussion on the Darwin dev. list of putting fake stub libraries into /usr/lib to solve this, but if it happens, it won't happen for a while. ) Follow-Ups: Date: 2001-Jan-23 19:32 By: akuchling Comment: Apparently fixed in revision 1.13 of setup.py; thanks! ------------------------------------------------------- Date: 2001-Jan-23 10:01 By: sdm7g Comment: I only submitted this bug once, but for some reason, reading it in the browser and returning to the buglist seems to cause it to be duplicated! --Steve. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129833&group_id=5470 From noreply@sourceforge.net Wed Jan 24 06:05:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 22:05:13 -0800 Subject: [Python-bugs-list] [Bug #129827] Mac OSX build of 2.1a needs "-traditional-cpp" Message-ID: Bug #129827, was updated on 2001-Jan-23 09:34 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: sdm7g Assigned to : nobody Summary: Mac OSX build of 2.1a needs "-traditional-cpp" Details: build of 2.1a1 fails on Mac OSX: compiling classobject.c generates a syntax error cc needs "-traditional-cpp" flag (This probably should have been in before, but changes to classobject uncovered the bug. ) -- Steve Follow-Ups: Date: 2001-Jan-23 22:05 By: dkwolfe Comment: Note: This is only true for Public Beta. Post public beta builds do not need this flag. (the bug in the pre-processor has been fixed.) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129827&group_id=5470 From noreply@sourceforge.net Wed Jan 24 06:13:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 22:13:53 -0800 Subject: [Python-bugs-list] [Bug #129843] MacOSX case insensitivity bug resurfaces Message-ID: Bug #129843, was updated on 2001-Jan-23 11:38 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: nobody Assigned to : gvanrossum Summary: MacOSX case insensitivity bug resurfaces Details: The case insensitivity with HFS+ MacOSX bug has resurfaced with the 2.1a1 release. import FCNTL; import fcntl or import termios; import TERMIOS (and maybe others) will crash due to duplicate symbols as it tries to import the same shared libraries twice instead ot importing the .py file for one of them. This was handled in 2.0 by building those modules as built-in, not shared. ( I haven't yet figured out the new setup.py system. Maybe it should be fixed in import. ) -- Steve M. Follow-Ups: Date: 2001-Jan-23 22:13 By: nobody Comment: There is also a clash between: lib/plat-Darwin1.2/SOCKET.py & lib/socket.py which can't be fixed by building one builtin. ( The .so is _socketmodule.so, so it doesn't clash. ) - sdm7g ------------------------------------------------------- Date: 2001-Jan-23 18:46 By: gvanrossum Comment: You can make them built-in by adding them to the Modules/Setup file -- that file still exists and works as before, it's just that most modules aren't listed there any more. See also the discussion at this patch: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 The long-term solution is to get rid of the FCNTL and TERMIOS modules and include the symbols in the extension -- as has been done for e.g. the socket module. (Some of the symbols of FCNTL are already exported by fcntl or os.) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129843&group_id=5470 From noreply@sourceforge.net Wed Jan 24 06:22:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jan 2001 22:22:35 -0800 Subject: [Python-bugs-list] [Bug #129904] 2.1a1: lib-tk not in sys.path: import fails Message-ID: Bug #129904, was updated on 2001-Jan-23 22:22 Here is a current snapshot of the bug. Project: Python Category: Tkinter Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: sdm7g Assigned to : nobody Summary: 2.1a1: lib-tk not in sys.path: import fails Details: "import Tkinter" fails on the new 2.1a1 build. The new setup.py script correctly finds the libraries and builds it automatically, but lib-tk is no longer put into sys.path as it was in 2.0. -- Steve M. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129904&group_id=5470 From noreply@sourceforge.net Wed Jan 24 08:44:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 00:44:07 -0800 Subject: [Python-bugs-list] [Bug #129904] 2.1a1: lib-tk not in sys.path: import fails Message-ID: Bug #129904, was updated on 2001-Jan-23 22:22 Here is a current snapshot of the bug. Project: Python Category: Tkinter Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: sdm7g Assigned to : gvanrossum Summary: 2.1a1: lib-tk not in sys.path: import fails Details: "import Tkinter" fails on the new 2.1a1 build. The new setup.py script correctly finds the libraries and builds it automatically, but lib-tk is no longer put into sys.path as it was in 2.0. -- Steve M. Follow-Ups: Date: 2001-Jan-24 00:44 By: tim_one Comment: Not a problem on Windows, so changed group to Platform-specific. Assigned to Guido at random. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129904&group_id=5470 From noreply@sourceforge.net Wed Jan 24 15:50:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 07:50:47 -0800 Subject: [Python-bugs-list] [Bug #123225] asyncore.py should use select.poll(), not "import poll" Message-ID: Bug #123225, was updated on 2000-Nov-22 20:41 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Closed Resolution: Fixed Bug Group: Not a Bug Priority: 5 Submitted by: nobody Assigned to : akuchling Summary: asyncore.py should use select.poll(), not "import poll" Details: The Python2.0 asyncore module is able to use the poll system call (claimed to be much more efficient than select for large numbers of requests), however, it tries to "import poll", which fails (there is no pollmodule supplied with Python2.0), whereas it could use the poll available with the select module (select.poll()). Follow-Ups: Date: 2001-Jan-24 07:50 By: akuchling Comment: Fixed in revision 1.9 of asyncore.py. ------------------------------------------------------- Date: 2001-Jan-19 08:13 By: akuchling Comment: I haven't really tested the patch (though I can make time for doing so before alpha2), and simply just don't like forking the code. I've pinged the mailing list, but have heard nothing yet. If Sam remains silent, I'll test the patch and then check it in. ------------------------------------------------------- Date: 2001-Jan-18 19:41 By: gvanrossum Comment: Would it be really bad if we applied this without waiting for Sam? Maybe Sam is busy (after egroups was aquired by Yahoo I think he decided to move to the SF bay area and/or change jobs). Maybe he's not yet on the Python 2.x bandwagon. What's wrong with a (temporary) fork in the code? ------------------------------------------------------- Date: 2001-Jan-18 13:44 By: akuchling Comment: The patch is archived at http://www.egroups.com/message/medusa/262 . Still no word from Sam Rushing on whether he accepted it. ------------------------------------------------------- Date: 2000-Dec-22 06:43 By: akuchling Comment: A patch to use Python 2.0's select.poll() has been sent off to the medusa@egroups.com mailing list. Assuming the patch is accepted, this bug will be fixed when we pick up the latest version of asyncore.py before Python 2.1 is finalized. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=123225&group_id=5470 From noreply@sourceforge.net Thu Jan 25 00:22:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 16:22:01 -0800 Subject: [Python-bugs-list] [Bug #129991] build process references ld_so_aix in lib before it exists Message-ID: Bug #129991, was updated on 2001-Jan-24 16:22 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: bcollar Assigned to : nobody Summary: build process references ld_so_aix in lib before it exists Details: Platform: AIX 4.2.1. performed ./configure --without-gcc --without-threads --prefix=/development/utils. Had to do --without-threads because otherwise it builds, but core dumps. make CC=xlC OPT="-O2 -qmaxmem=4000". make bombs because there is not a directory called /development/utils/lib/python2.1. Here is the relevant output from make: running build running build_ext building 'struct' extension skipping /development/utils/src/Python-2.1a1/Modules/structmodule.c (build/temp.aix-2-000310094C00-2.1/structmodule.o up-to-date) /development/utils/lib/python2.1/config/ld_so_aix cc -bI:/development/utils/lib/python2.1/config/python.exp build/temp.aix-2-000310094C00-2.1/structmodule.o -L/usr/local/lib -o build/lib.aix-2-000310094C00-2.1/struct.so unable to execute /development/utils/lib/python2.1/config/ld_so_aix: No such file or directory error: command '/development/utils/lib/python2.1/config/ld_so_aix' failed with exit status 1 make: 1254-004 The error code from the last command is 1. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129991&group_id=5470 From noreply@sourceforge.net Thu Jan 25 00:40:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 16:40:27 -0800 Subject: [Python-bugs-list] [Bug #129994] problem building readline extension on linux Message-ID: Bug #129994, was updated on 2001-Jan-24 16:40 Here is a current snapshot of the bug. Project: Python Category: Extension Modules Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: bcollar Assigned to : nobody Summary: problem building readline extension on linux Details: Howdy Using debian stable, 2.2.18pre1. Configure ran fine, python built okay, but the readline extension failed to build with this error: building 'readline' extension gcc -g -O2 -Wall -Wstrict-prototypes -fPIC -fpic -I. -I/tmp/Python-2.1a1/./Include -IInclude/ -I/usr/local/include -c /tmp/Python-2.1a1/Modules/readline.c -o build/temp.linux-i586-2.1/readline.o gcc -shared build/temp.linux-i586-2.1/readline.o -L/usr/local/lib -lreadline -ltermcap -o build/lib.linux-i586-2.1/readline.so /usr/bin/ld: cannot find -ltermcap collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 make: *** [sharedmods] Error 1 For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129994&group_id=5470 From noreply@sourceforge.net Thu Jan 25 00:44:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 16:44:40 -0800 Subject: [Python-bugs-list] [Bug #129995] segfaults on AIX if configured with threads Message-ID: Bug #129995, was updated on 2001-Jan-24 16:44 Here is a current snapshot of the bug. Project: Python Category: Threads Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: bcollar Assigned to : nobody Summary: segfaults on AIX if configured with threads Details: Hi. AIX 4.2.1. ran ./configure --without-gcc --prefix=/development/utils. make CC=xlC OPT="-O2 -qmaxmem=4000". some of the make output follows. Let me know if you need all of it. if test ! -f ../Modules/hassignal; then echo adding sigcheck.o; ar r ../libpython2.1.a sigcheck.o; else echo leaving sigcheck.o out; fi leaving sigcheck.o out touch add2lib if test -f hassignal; then echo removing sigcheck.o intrcheck.o; ar d ../libpython2.1.a sigcheck.o intrcheck.o 2>/dev/null; else echo leaving sigcheck.o intrcheck.o in; fi removing sigcheck.o intrcheck.o make: 1254-004 The error code from the last command is 2. make: 1254-005 Ignored error code 2 from last command. ar cr ../libpython2.1.a gcmodule.o threadmodule.o posixmodule.o _sre.o signalmodule.o config.o getpath.o main.o getbuildinfo.o touch add2lib cd Modules; make OPT="-O2 -qmaxmem=4000" python.o xlC -O2 -qmaxmem=4000 -I./../Include -I.. -DHAVE_CONFIG_H -c python.c expr `cat buildno` + 1 >buildno1 mv -f buildno1 buildno xlC -c -O2 -qmaxmem=4000 -I. -DHAVE_CONFIG_H -DBUILD=`cat buildno` ./Modules/getbuildinfo.c ar cr libpython2.1.a getbuildinfo.o ranlib libpython2.1.a true cd Modules; make OPT="-O2 -qmaxmem=4000" VERSION="2.1" prefix="/development/utils/" exec_prefix="/development/utils/" LIBRARY=../libpython2.1.a link ./makexp_aix python.exp "" ../libpython2.1.a; xlC -Wl,-bE:python.exp -lld python.o ../libpython2.1.a -ldl -lpthreads -lm -o python mv python ../python ./python ./setup.py build pthread_mutex_init: Error 0 pthread_cond_init: Error 0 pthread_mutex_lock[1]: Error 0 make: 1254-059 The signal code from the last command is 11. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129995&group_id=5470 From noreply@sourceforge.net Thu Jan 25 00:51:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 16:51:58 -0800 Subject: [Python-bugs-list] [Bug #129994] problem building readline extension on linux Message-ID: Bug #129994, was updated on 2001-Jan-24 16:40 Here is a current snapshot of the bug. Project: Python Category: Extension Modules Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: bcollar Assigned to : nobody Summary: problem building readline extension on linux Details: Howdy Using debian stable, 2.2.18pre1. Configure ran fine, python built okay, but the readline extension failed to build with this error: building 'readline' extension gcc -g -O2 -Wall -Wstrict-prototypes -fPIC -fpic -I. -I/tmp/Python-2.1a1/./Include -IInclude/ -I/usr/local/include -c /tmp/Python-2.1a1/Modules/readline.c -o build/temp.linux-i586-2.1/readline.o gcc -shared build/temp.linux-i586-2.1/readline.o -L/usr/local/lib -lreadline -ltermcap -o build/lib.linux-i586-2.1/readline.so /usr/bin/ld: cannot find -ltermcap collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 make: *** [sharedmods] Error 1 Follow-Ups: Date: 2001-Jan-24 16:51 By: bcollar Comment: I just looked at the setup.py script, and this line I'm figuring is the problem: if (self.compiler.find_library_file(lib_dirs, 'readline')): exts.append( Extension('readline', ['readline.c'], libraries=['readline', 'termcap']) ) since libraries includes termcap, the the find_library_file should also look for termcap, no? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129994&group_id=5470 From noreply@sourceforge.net Thu Jan 25 01:57:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 17:57:56 -0800 Subject: [Python-bugs-list] [Bug #129998] "Corrupt installation" when installed without admin privs Message-ID: Bug #129998, was updated on 2001-Jan-24 17:57 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: tlau Assigned to : nobody Summary: "Corrupt installation" when installed without admin privs Details: On Windows 2000, when logged in a user without administrator privileges, attempting to run the Python 2.0 installer results in a single dialog box saying "Corrupt installation detected" and then the installer exits. This should be a more informative error message. I downloaded the 5MB installer three times before suspecting the correct cause of the problem. When the same binary is run as a user with the correct privileges, it correctly begins the installation process. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129998&group_id=5470 From noreply@sourceforge.net Thu Jan 25 04:00:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 20:00:19 -0800 Subject: [Python-bugs-list] [Bug #130006] /test/tokenize_tests_.py minor bug Message-ID: Bug #130006, was updated on 2001-Jan-24 20:00 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : nobody Summary: /test/tokenize_tests_.py minor bug Details: There is a minor error on line 147 in the module /test/tokenize_tests.py of the new 2.1alpha1. The function d01v has the parameter name "rest" repeated in the function definition. This gives an error message when that function is reached during "make install" on a Debian 2.2 (potato) Linux system. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130006&group_id=5470 From noreply@sourceforge.net Thu Jan 25 04:07:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 20:07:02 -0800 Subject: [Python-bugs-list] [Bug #129998] "Corrupt installation" when installed without admin privs Message-ID: Bug #129998, was updated on 2001-Jan-24 17:57 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: tlau Assigned to : mhammond Summary: "Corrupt installation" when installed without admin privs Details: On Windows 2000, when logged in a user without administrator privileges, attempting to run the Python 2.0 installer results in a single dialog box saying "Corrupt installation detected" and then the installer exits. This should be a more informative error message. I downloaded the 5MB installer three times before suspecting the correct cause of the problem. When the same binary is run as a user with the correct privileges, it correctly begins the installation process. Follow-Ups: Date: 2001-Jan-24 20:07 By: tim_one Comment: I need someone else to confirm this (don't have W2K myself). Mark? If not, assign back to me. tlau, from where did you obtain the installer? Exactly how large is it? (If it's not exactly 5811039 bytes, it's definitely corrupt -- if it is that size, say so and we'll try an MD5 checksum next.) The Wise installer produces the "Corrupt installation detected" msg itself, when it gets a CRC mismatch after checksumming its internal components. We have no control over that, and in every previous case of this I know of it *did* mean the installer was corrupt. If you're not logged in with admin privileges, what's supposed to happen is that a box pops up telling you so, and asking whether you want to proceed with a weaker installation, or abort the installation. Testers reported that the 2.0 installer did exactly that, on NT and W2K (it's not an issue on 95, 98 or ME). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129998&group_id=5470 From noreply@sourceforge.net Thu Jan 25 04:46:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 20:46:36 -0800 Subject: [Python-bugs-list] [Bug #129998] "Corrupt installation" when installed without admin privs Message-ID: Bug #129998, was updated on 2001-Jan-24 17:57 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: tlau Assigned to : mhammond Summary: "Corrupt installation" when installed without admin privs Details: On Windows 2000, when logged in a user without administrator privileges, attempting to run the Python 2.0 installer results in a single dialog box saying "Corrupt installation detected" and then the installer exits. This should be a more informative error message. I downloaded the 5MB installer three times before suspecting the correct cause of the problem. When the same binary is run as a user with the correct privileges, it correctly begins the installation process. Follow-Ups: Date: 2001-Jan-24 20:46 By: tlau Comment: I downloaded it using this link: http://www.python.org/ftp/python/2.0/BeOpen-Python-2.0.exe The first two times I used IE to click on the link. I didn't save those copies; I know the file size was around 5.8MB, but I don't know exactly. For the third try, I used ncftp on a Linux machine to get this file: ftp://ftp.python.org/pub/python/2.0/BeOpen-Python-2.0.exe I then used Samba to copy the file from my Linux home directory to the Win2k machine. I got the same error message (corrupt installation) for all three attempts. I then logged in as a user with admin privs, ran the third copy, and installation proceeded correctly. I don't know how to compute the checksum on Windows, but this is what I get from the copy I saved on my Linux system: % md5sum BeOpen-Python-2.0.exe 05f93fc81247dfb993f2e946016264c0 BeOpen-Python-2.0.exe ------------------------------------------------------- Date: 2001-Jan-24 20:07 By: tim_one Comment: I need someone else to confirm this (don't have W2K myself). Mark? If not, assign back to me. tlau, from where did you obtain the installer? Exactly how large is it? (If it's not exactly 5811039 bytes, it's definitely corrupt -- if it is that size, say so and we'll try an MD5 checksum next.) The Wise installer produces the "Corrupt installation detected" msg itself, when it gets a CRC mismatch after checksumming its internal components. We have no control over that, and in every previous case of this I know of it *did* mean the installer was corrupt. If you're not logged in with admin privileges, what's supposed to happen is that a box pops up telling you so, and asking whether you want to proceed with a weaker installation, or abort the installation. Testers reported that the 2.0 installer did exactly that, on NT and W2K (it's not an issue on 95, 98 or ME). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129998&group_id=5470 From noreply@sourceforge.net Thu Jan 25 05:14:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jan 2001 21:14:42 -0800 Subject: [Python-bugs-list] [Bug #130010] Nasty case for comparison performance Message-ID: Bug #130010, was updated on 2001-Jan-24 21:14 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: None Priority: 1 Submitted by: tim_one Assigned to : gvanrossum Summary: Nasty case for comparison performance Details: Test case: def timeeq(x, y): from time import clock import sys assert len(x) == len(y) print "comparing dicts of len", len(x), "...", sys.stdout.flush() s = clock() result = x == y f = clock() print round(f-s, 1), "seconds" sys.stdout.flush() d = {} e = {} timeeq(d, e) d[0] = d e[0] = e timeeq(d, e) d[1] = d e[1] = e timeeq(d, e) d[2] = d e[2] = e timeeq(d, e) Under current CVS, output is: comparing dicts of len 0 ... 0.0 seconds comparing dicts of len 1 ... 0.0 seconds comparing dicts of len 2 ... 6.5 seconds comparing dicts of len 3 ... There's no sign that the 3-element dict compare will ever terminate (killed it after 15 minutes on a quiet machine). This is actually a huge improvement over Python 2.0, though! There it spins (seemingly) forever comparing the 2-element dicts. Note that I put this at priority 1 (lowest). For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130010&group_id=5470 From noreply@sourceforge.net Thu Jan 25 08:15:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jan 2001 00:15:03 -0800 Subject: [Python-bugs-list] [Bug #121207] % operator on strings not documented Message-ID: Bug #121207, was updated on 2000-Nov-03 04:51 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : fdrake Summary: % operator on strings not documented Details: Python string substitution with % is not documented -- the closest the doc gets is at which says the string is "interpreted as a C sprintf() format string", but doesn't say what that means or how the substitution is done. Follow-Ups: Date: 2001-Jan-25 00:15 By: moshez Comment: 103412 patch is meant to solve this bug. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=121207&group_id=5470 From noreply@sourceforge.net Thu Jan 25 10:10:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jan 2001 02:10:07 -0800 Subject: [Python-bugs-list] [Bug #129998] "Corrupt installation" when installed without admin privs Message-ID: Bug #129998, was updated on 2001-Jan-24 17:57 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: tlau Assigned to : mhammond Summary: "Corrupt installation" when installed without admin privs Details: On Windows 2000, when logged in a user without administrator privileges, attempting to run the Python 2.0 installer results in a single dialog box saying "Corrupt installation detected" and then the installer exits. This should be a more informative error message. I downloaded the 5MB installer three times before suspecting the correct cause of the problem. When the same binary is run as a user with the correct privileges, it correctly begins the installation process. Follow-Ups: Date: 2001-Jan-25 02:10 By: tim_one Comment: Curious! That's the right MD5 checksum. Yours is the only report of this we've ever gotten, though, while you're certainly not the only 2.0 Win2K user. It's possible that you're the only one who wasn't logged on to an admin account, though. Since you have Python running on Windows now, we can use it to compute the MD5 digest: >>> # change to path of your installer; "rb" is crucial >>> f = open("/updates/beopen-python-2.0.exe", "rb") >>> import md5 >>> print md5.md5(f.read()).hexdigest() 05f93fc81247dfb993f2e946016264c0 >>> If you still get the right checksum, we can rule out the file transfer, but then I'm stumped. Guess we'll have to report it as a bug to Wise, then (we're not generating the error msg you're seeing -- that's all an automatic function of the Wise installer). ------------------------------------------------------- Date: 2001-Jan-24 20:46 By: tlau Comment: I downloaded it using this link: http://www.python.org/ftp/python/2.0/BeOpen-Python-2.0.exe The first two times I used IE to click on the link. I didn't save those copies; I know the file size was around 5.8MB, but I don't know exactly. For the third try, I used ncftp on a Linux machine to get this file: ftp://ftp.python.org/pub/python/2.0/BeOpen-Python-2.0.exe I then used Samba to copy the file from my Linux home directory to the Win2k machine. I got the same error message (corrupt installation) for all three attempts. I then logged in as a user with admin privs, ran the third copy, and installation proceeded correctly. I don't know how to compute the checksum on Windows, but this is what I get from the copy I saved on my Linux system: % md5sum BeOpen-Python-2.0.exe 05f93fc81247dfb993f2e946016264c0 BeOpen-Python-2.0.exe ------------------------------------------------------- Date: 2001-Jan-24 20:07 By: tim_one Comment: I need someone else to confirm this (don't have W2K myself). Mark? If not, assign back to me. tlau, from where did you obtain the installer? Exactly how large is it? (If it's not exactly 5811039 bytes, it's definitely corrupt -- if it is that size, say so and we'll try an MD5 checksum next.) The Wise installer produces the "Corrupt installation detected" msg itself, when it gets a CRC mismatch after checksumming its internal components. We have no control over that, and in every previous case of this I know of it *did* mean the installer was corrupt. If you're not logged in with admin privileges, what's supposed to happen is that a box pops up telling you so, and asking whether you want to proceed with a weaker installation, or abort the installation. Testers reported that the 2.0 installer did exactly that, on NT and W2K (it's not an issue on 95, 98 or ME). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129998&group_id=5470 From noreply@sourceforge.net Thu Jan 25 10:55:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jan 2001 02:55:29 -0800 Subject: [Python-bugs-list] [Bug #130029] Python chokes on pthread_mutex_init Message-ID: Bug #130029, was updated on 2001-Jan-25 02:55 Here is a current snapshot of the bug. Project: Python Category: Threads Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: nobody Assigned to : nobody Summary: Python chokes on pthread_mutex_init Details: On an HPUX 11.00: During "make intstall": ./install-sh -c -m 644 ./Lib/curses/__init__.py /opt/tmp/Python/lib/python2.0/curses ./install-sh -c -m 644 ./Lib/curses/ascii.py /opt/tmp/Python/lib/python2.0/curses ./install-sh -c -m 644 ./Lib/curses/has_key.py /opt/tmp/Python/lib/python2.0/curses ./install-sh -c -m 644 ./Lib/curses/textpad.py /opt/tmp/Python/lib/python2.0/curses ./install-sh -c -m 644 ./Lib/curses/wrapper.py /opt/tmp/Python/lib/python2.0/curses ./install-sh -c -m 644 ./Lib/plat-hp-uxB/core /opt/tmp/Python/lib/python2.0/plat-hp-uxB ./install-sh -c -m 755 ./Lib/plat-hp-uxB/regen /opt/tmp/Python/lib/python2.0/plat-hp-uxB ./install-sh -c -m 644 ./LICENSE /opt/tmp/Python/lib/python2.0/LICENSE.txt PYTHONPATH=/opt/tmp/Python/lib/python2.0 \ ./python -tt /opt/tmp/Python/lib/python2.0/compileall.py /opt/tmp/Python/lib/python2.0 pthread_mutex_init: Invalid argument sh: 6074 Memory fault(coredump) ---------------------------------------------------------- This fault can be reproduced: export PYTHONPATH=/opt/tmp/Python/lib/python2.0 /opt/stephie/Python-2.0 > ./python -tt /opt/tmp/Python/lib/python2.0/compileall.py /opt/tmp/Python/lib/python2.0 pthread_mutex_init: Invalid argument Memory fault(coredump) For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130029&group_id=5470 From noreply@sourceforge.net Thu Jan 25 11:03:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jan 2001 03:03:09 -0800 Subject: [Python-bugs-list] [Bug #130030] Claim of bad betavariate algorithm Message-ID: Bug #130030, was updated on 2001-Jan-25 03:03 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: Irreproducible Priority: 5 Submitted by: tim_one Assigned to : tim_one Summary: Claim of bad betavariate algorithm Details: From c.l.py. Beats me, but sounds credible. random.py cites Discrete Event Simulation in C, pp 87-88, for its algorithm. """ [Janne Sinkkonen (mailto:janne@mansikka.nnets.fi)] At least in Python 2.0 and earlier, the samples returned by the function betavariate() of random.py are not from a beta distribution although the function name misleadingly suggests so. The following would give beta-distributed samples: def betavariate(alpha, beta): y = gammavariate(alpha,1) if y==0: return 0.0 else: return y/(y+gammavariate(beta,1)) This is from matlab. A comment in the original matlab code refers to Devroye, L. (1986) Non-Uniform Random Variate Generation, theorem 4.1A (p. 430). Another reference would be Gelman, A. et al. (1995) Bayesian data analysis, p. 481, which I have checked and found to agree with the code above. """ For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130030&group_id=5470 From noreply@sourceforge.net Thu Jan 25 11:05:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jan 2001 03:05:59 -0800 Subject: [Python-bugs-list] [Bug #128965] Crash on Windows (no current thread) with gadfly Message-ID: Bug #128965, was updated on 2001-Jan-15 18:33 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Closed Resolution: Wont Fix Bug Group: 3rd Party Priority: 3 Submitted by: nobody Assigned to : tim_one Summary: Crash on Windows (no current thread) with gadfly Details: Occurs when attempting to use gadly: > Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32 > Type "copyright", "credits" or "license" for more information. > >>> import sys > >>> gadflydir=r"c:\program files\python20\lib\gadfly" > >>> sys.path.append(gadflydir) > >>> from gadfly import gadfly > >>> connection=gadfly() > >>> connection.startup("mydatabase", r"c:\data") > >>> cursor = connection.cursor() > >>> cursor.execute("create table ph(nm varchar, ph varchar)") > Fatal Python error: PyThreadState_Get: no current thread > > abnormal program termination > Follow-Ups: Date: 2001-Jan-25 03:05 By: tim_one Comment: More than a week has gone by without a followup, so, as threatened, I'm just closing this (WontFix, presumed Invalid). If more info comes in, I'll reopen it. ------------------------------------------------------- Date: 2001-Jan-16 17:48 By: tim_one Comment: We don't write, maintain or even distribute gadfly. So unless the anonymous submitter resurfaces to explain where they got gadfly, and what Aaron (gadfly's author) had to say about it, I'm going to close this. ------------------------------------------------------- Date: 2001-Jan-16 06:18 By: gvanrossum Comment: The problem is not that Python for Windows hasn't been built with threads (as the subject originally suggested). But I don't know what the problem *is* -- it could well be a bug in gadfly, or it could be a Python bug triggered by gadfly. Assigning this to Tim, our universal Windows scapegoat. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128965&group_id=5470 From noreply@sourceforge.net Thu Jan 25 12:52:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jan 2001 04:52:16 -0800 Subject: [Python-bugs-list] [Bug #129998] "Corrupt installation" when installed without admin privs Message-ID: Bug #129998, was updated on 2001-Jan-24 17:57 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Platform-specific Priority: 1 Submitted by: tlau Assigned to : mhammond Summary: "Corrupt installation" when installed without admin privs Details: On Windows 2000, when logged in a user without administrator privileges, attempting to run the Python 2.0 installer results in a single dialog box saying "Corrupt installation detected" and then the installer exits. This should be a more informative error message. I downloaded the 5MB installer three times before suspecting the correct cause of the problem. When the same binary is run as a user with the correct privileges, it correctly begins the installation process. Follow-Ups: Date: 2001-Jan-25 04:52 By: gvanrossum Comment: I recall explicitly testing whether that installer worked on Win2000 without admin privileges. So I suspect it's something to do with tlau's set-up, and I don't think we will be able to get much further with this. (It doesn't help that we don't have the source code for the WISE installer generator, of course. :-( ) ------------------------------------------------------- Date: 2001-Jan-25 02:10 By: tim_one Comment: Curious! That's the right MD5 checksum. Yours is the only report of this we've ever gotten, though, while you're certainly not the only 2.0 Win2K user. It's possible that you're the only one who wasn't logged on to an admin account, though. Since you have Python running on Windows now, we can use it to compute the MD5 digest: >>> # change to path of your installer; "rb" is crucial >>> f = open("/updates/beopen-python-2.0.exe", "rb") >>> import md5 >>> print md5.md5(f.read()).hexdigest() 05f93fc81247dfb993f2e946016264c0 >>> If you still get the right checksum, we can rule out the file transfer, but then I'm stumped. Guess we'll have to report it as a bug to Wise, then (we're not generating the error msg you're seeing -- that's all an automatic function of the Wise installer). ------------------------------------------------------- Date: 2001-Jan-24 20:46 By: tlau Comment: I downloaded it using this link: http://www.python.org/ftp/python/2.0/BeOpen-Python-2.0.exe The first two times I used IE to click on the link. I didn't save those copies; I know the file size was around 5.8MB, but I don't know exactly. For the third try, I used ncftp on a Linux machine to get this file: ftp://ftp.python.org/pub/python/2.0/BeOpen-Python-2.0.exe I then used Samba to copy the file from my Linux home directory to the Win2k machine. I got the same error message (corrupt installation) for all three attempts. I then logged in as a user with admin privs, ran the third copy, and installation proceeded correctly. I don't know how to compute the checksum on Windows, but this is what I get from the copy I saved on my Linux system: % md5sum BeOpen-Python-2.0.exe 05f93fc81247dfb993f2e946016264c0 BeOpen-Python-2.0.exe ------------------------------------------------------- Date: 2001-Jan-24 20:07 By: tim_one Comment: I need someone else to confirm this (don't have W2K myself). Mark? If not, assign back to me. tlau, from where did you obtain the installer? Exactly how large is it? (If it's not exactly 5811039 bytes, it's definitely corrupt -- if it is that size, say so and we'll try an MD5 checksum next.) The Wise installer produces the "Corrupt installation detected" msg itself, when it gets a CRC mismatch after checksumming its internal components. We have no control over that, and in every previous case of this I know of it *did* mean the installer was corrupt. If you're not logged in with admin privileges, what's supposed to happen is that a box pops up telling you so, and asking whether you want to proceed with a weaker installation, or abort the installation. Testers reported that the 2.0 installer did exactly that, on NT and W2K (it's not an issue on 95, 98 or ME). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129998&group_id=5470 From noreply@sourceforge.net Thu Jan 25 18:38:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jan 2001 10:38:46 -0800 Subject: [Python-bugs-list] [Bug #128973] OpenBSD Problems with _funlockfile in fileobject.c Message-ID: Bug #128973, was updated on 2001-Jan-15 21:12 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: jpettit Assigned to : gvanrossum Summary: OpenBSD Problems with _funlockfile in fileobject.c Details: When I compile the current CVS version of Python on OpenBSD 2.8, I get the following linker error: ld: _funlockfile: non-function jmpslot collect2: ld returned 1 exit status *** Error code 1 This function was first added to Python in version 2.97 of "fileobject.c". Follow-Ups: Date: 2001-Jan-25 10:38 By: ltratt Comment: I'd be happy to offer any of the Python developers an account on an OpenBSD machine if they wish - mail tratt@dcs.kcl.ac.uk ------------------------------------------------------- Date: 2001-Jan-18 19:32 By: gvanrossum Comment: Alas, it seems that this will remain open in 2.1a1. Hopefully someone else will be able to fix it once the alpha1 release is out. ------------------------------------------------------- Date: 2001-Jan-16 11:58 By: jpettit Comment: The man page doesn't seem to specify a particular library to link against. It only says to include stdio.h. I'm building Python without any special flags. I thought threads were enabled by default, but just for good measure, I ran configure with --with-threads and got the same results. I don't see any reference to flockfile/funlockfile in config.log. ------------------------------------------------------- Date: 2001-Jan-16 11:00 By: twouters Comment: Unfortunately, I don't have access to OpenBSD, just FreeBSD and BSDI. flockfile/funlockfile both work fine there. I suspect it's a header/library problem: maybe we need to include a separate header/library, which we for some reason do in the configure process, but not in the linking of Python (or maybe it needs additional magic to link together with other libraries, I don't know.) jpettit, can you check the manpage for funlockfile to see what headerfiles should be included, and perhaps what to link with ? Also, are you compiling threaded or unthreaded ? There is a good chance the flockfile/funlockfile functions are only available in threaded code, or maybe Python is being compiled half-threaded for some reason. Checking to see the difference between what config.log and 'make' say might give some hints, too. Or it could just be an OS bug :P We should be able to figure it out though: if Python can't *compile* with those functions, neither should configure. ------------------------------------------------------- Date: 2001-Jan-16 09:56 By: jpettit Comment: I'd be happy to help however I can. However, autoconf is black magic to me. I think that funlockfile is supposed to be available...there is even a man page dated 20 August 1998. This may be another case of OpenBSD improperly integrating components from the other BSDs. Please let me know what I can do. ------------------------------------------------------- Date: 2001-Jan-16 05:28 By: gvanrossum Comment: It's gotta be more complicated that that. The configure script has a test program that calls flockfile(), getc_unlocked(), and funlockfile(). Only if this test program links successfully does it decide to use getc_unlocked(). (Making the test depend on successfully *running* it shouldn't make a difference -- the user here got a link-time error.) jpettit, is there a way you could find out why the configure test succeeds but then you get a link error linking Python? I'll also ask Thomas Wouters to look into this. ------------------------------------------------------- Date: 2001-Jan-15 22:19 By: tim_one Comment: Ho ho ho: so this means some flavor of Unix has getc_unlocked() but not the flockfile() and funlockfile() that are supposed to come with it? Man, Windows looks better every day -- and so does the getline_via_fgets() hack ... ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128973&group_id=5470 From noreply@sourceforge.net Thu Jan 25 20:16:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jan 2001 12:16:31 -0800 Subject: [Python-bugs-list] [Bug #130075] dbmmodule build fails on Debian GNU/Linux unstable (Sid) Message-ID: Bug #130075, was updated on 2001-Jan-25 12:16 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: krftkndl Assigned to : nobody Summary: dbmmodule build fails on Debian GNU/Linux unstable (Sid) Details: When building on Debian GNU/Linux unstable, the build fails with: /home/kalle/src/python/dist/src/Modules/dbmmodule.c:24: #error "No ndbm.h available!" error: command 'gcc' failed with exit status 1 make: *** [sharedmods] Error 1 The *dbm.h files available are /usr/include/dbm.h /usr/include/gdbm.h /usr/include/gdbm-ndbm.h All are part of the package libgdbmg1-dev. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130075&group_id=5470 From noreply@sourceforge.net Thu Jan 25 20:21:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jan 2001 12:21:24 -0800 Subject: [Python-bugs-list] [Bug #130075] dbmmodule build fails on Debian GNU/Linux unstable (Sid) Message-ID: Bug #130075, was updated on 2001-Jan-25 12:16 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: krftkndl Assigned to : nobody Summary: dbmmodule build fails on Debian GNU/Linux unstable (Sid) Details: When building on Debian GNU/Linux unstable, the build fails with: /home/kalle/src/python/dist/src/Modules/dbmmodule.c:24: #error "No ndbm.h available!" error: command 'gcc' failed with exit status 1 make: *** [sharedmods] Error 1 The *dbm.h files available are /usr/include/dbm.h /usr/include/gdbm.h /usr/include/gdbm-ndbm.h All are part of the package libgdbmg1-dev. Follow-Ups: Date: 2001-Jan-25 12:21 By: krftkndl Comment: Forgot to say that it's Python out of CVS, updated Thu Jan 25 21:23:52 CET 2001. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130075&group_id=5470 From noreply@sourceforge.net Thu Jan 25 20:31:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jan 2001 12:31:32 -0800 Subject: [Python-bugs-list] [Bug #130077] one-line typo in arraymodule.c Message-ID: Bug #130077, was updated on 2001-Jan-25 12:31 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: yole Assigned to : nobody Summary: one-line typo in arraymodule.c Details: Line 470 of arraymodule.c in Python-2.1alpha1 reads: case Py_LE: cmp = ws <= ws; break; It should be: case Py_LE: cmp = vs <= ws; break; For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130077&group_id=5470 From noreply@sourceforge.net Thu Jan 25 21:22:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jan 2001 13:22:42 -0800 Subject: [Python-bugs-list] [Bug #129998] "Corrupt installation" when installed without admin privs Message-ID: Bug #129998, was updated on 2001-Jan-24 17:57 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Platform-specific Priority: 1 Submitted by: tlau Assigned to : mhammond Summary: "Corrupt installation" when installed without admin privs Details: On Windows 2000, when logged in a user without administrator privileges, attempting to run the Python 2.0 installer results in a single dialog box saying "Corrupt installation detected" and then the installer exits. This should be a more informative error message. I downloaded the 5MB installer three times before suspecting the correct cause of the problem. When the same binary is run as a user with the correct privileges, it correctly begins the installation process. Follow-Ups: Date: 2001-Jan-25 13:22 By: tlau Comment: I did some more investigating. Python prints the correct md5 checksum for the installer; but that's a red herring. In the "Users and Passwords" control panel, my account is set up as a "Restricted user" (Users Group) account. When I change this setting to "Standard user" (Power Users Group), then launching the installer prompts me to proceed with a weaker installation (as expected). Changing the setting back to "Restricted user" and re-running the installer produces the "corrupt installation detected" message yet again. ------------------------------------------------------- Date: 2001-Jan-25 04:52 By: gvanrossum Comment: I recall explicitly testing whether that installer worked on Win2000 without admin privileges. So I suspect it's something to do with tlau's set-up, and I don't think we will be able to get much further with this. (It doesn't help that we don't have the source code for the WISE installer generator, of course. :-( ) ------------------------------------------------------- Date: 2001-Jan-25 02:10 By: tim_one Comment: Curious! That's the right MD5 checksum. Yours is the only report of this we've ever gotten, though, while you're certainly not the only 2.0 Win2K user. It's possible that you're the only one who wasn't logged on to an admin account, though. Since you have Python running on Windows now, we can use it to compute the MD5 digest: >>> # change to path of your installer; "rb" is crucial >>> f = open("/updates/beopen-python-2.0.exe", "rb") >>> import md5 >>> print md5.md5(f.read()).hexdigest() 05f93fc81247dfb993f2e946016264c0 >>> If you still get the right checksum, we can rule out the file transfer, but then I'm stumped. Guess we'll have to report it as a bug to Wise, then (we're not generating the error msg you're seeing -- that's all an automatic function of the Wise installer). ------------------------------------------------------- Date: 2001-Jan-24 20:46 By: tlau Comment: I downloaded it using this link: http://www.python.org/ftp/python/2.0/BeOpen-Python-2.0.exe The first two times I used IE to click on the link. I didn't save those copies; I know the file size was around 5.8MB, but I don't know exactly. For the third try, I used ncftp on a Linux machine to get this file: ftp://ftp.python.org/pub/python/2.0/BeOpen-Python-2.0.exe I then used Samba to copy the file from my Linux home directory to the Win2k machine. I got the same error message (corrupt installation) for all three attempts. I then logged in as a user with admin privs, ran the third copy, and installation proceeded correctly. I don't know how to compute the checksum on Windows, but this is what I get from the copy I saved on my Linux system: % md5sum BeOpen-Python-2.0.exe 05f93fc81247dfb993f2e946016264c0 BeOpen-Python-2.0.exe ------------------------------------------------------- Date: 2001-Jan-24 20:07 By: tim_one Comment: I need someone else to confirm this (don't have W2K myself). Mark? If not, assign back to me. tlau, from where did you obtain the installer? Exactly how large is it? (If it's not exactly 5811039 bytes, it's definitely corrupt -- if it is that size, say so and we'll try an MD5 checksum next.) The Wise installer produces the "Corrupt installation detected" msg itself, when it gets a CRC mismatch after checksumming its internal components. We have no control over that, and in every previous case of this I know of it *did* mean the installer was corrupt. If you're not logged in with admin privileges, what's supposed to happen is that a box pops up telling you so, and asking whether you want to proceed with a weaker installation, or abort the installation. Testers reported that the 2.0 installer did exactly that, on NT and W2K (it's not an issue on 95, 98 or ME). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129998&group_id=5470 From noreply@sourceforge.net Thu Jan 25 21:36:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jan 2001 13:36:08 -0800 Subject: [Python-bugs-list] [Bug #130030] Claim of bad betavariate algorithm Message-ID: Bug #130030, was updated on 2001-Jan-25 03:03 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: tim_one Assigned to : tim_one Summary: Claim of bad betavariate algorithm Details: From c.l.py. Beats me, but sounds credible. random.py cites Discrete Event Simulation in C, pp 87-88, for its algorithm. """ [Janne Sinkkonen (mailto:janne@mansikka.nnets.fi)] At least in Python 2.0 and earlier, the samples returned by the function betavariate() of random.py are not from a beta distribution although the function name misleadingly suggests so. The following would give beta-distributed samples: def betavariate(alpha, beta): y = gammavariate(alpha,1) if y==0: return 0.0 else: return y/(y+gammavariate(beta,1)) This is from matlab. A comment in the original matlab code refers to Devroye, L. (1986) Non-Uniform Random Variate Generation, theorem 4.1A (p. 430). Another reference would be Gelman, A. et al. (1995) Bayesian data analysis, p. 481, which I have checked and found to agree with the code above. """ Follow-Ups: Date: 2001-Jan-25 13:36 By: tim_one Comment: I have no idea why the Group was set to Irreproducible, but have seen that on other recent new bug reports too -- maybe a new SF buglet. Anyway, changed group to None. Ivan Frohne helpfully investigated this, and made what looks to be a very strong case for adopting the algorithm Janne suggests. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130030&group_id=5470 From noreply@sourceforge.net Thu Jan 25 22:27:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jan 2001 14:27:25 -0800 Subject: [Python-bugs-list] [Bug #129998] "Corrupt installation" when installed without admin privs Message-ID: Bug #129998, was updated on 2001-Jan-24 17:57 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Platform-specific Priority: 1 Submitted by: tlau Assigned to : mhammond Summary: "Corrupt installation" when installed without admin privs Details: On Windows 2000, when logged in a user without administrator privileges, attempting to run the Python 2.0 installer results in a single dialog box saying "Corrupt installation detected" and then the installer exits. This should be a more informative error message. I downloaded the 5MB installer three times before suspecting the correct cause of the problem. When the same binary is run as a user with the correct privileges, it correctly begins the installation process. Follow-Ups: Date: 2001-Jan-25 14:27 By: gvanrossum Comment: Then this is most likely a bug we can't fix. The"Corrupt installation" check is made AFAIK by the WISE installer code before it runs any of the script. One of the system checks it does must be using something that's disallowed by Win2K in Restricted User mode. We have control over the script -- it tests for Administrator privileges and offers to proceed; but we have no control over the system check before it runs. I haven't seen this complaint before, so I presume it's unlikely to happen (Restricted Users typically won't want to install software :-). I'll leave it up to Tim, but personally, I'd just close the report as "Won't Fix" and "3rd party". ------------------------------------------------------- Date: 2001-Jan-25 13:22 By: tlau Comment: I did some more investigating. Python prints the correct md5 checksum for the installer; but that's a red herring. In the "Users and Passwords" control panel, my account is set up as a "Restricted user" (Users Group) account. When I change this setting to "Standard user" (Power Users Group), then launching the installer prompts me to proceed with a weaker installation (as expected). Changing the setting back to "Restricted user" and re-running the installer produces the "corrupt installation detected" message yet again. ------------------------------------------------------- Date: 2001-Jan-25 04:52 By: gvanrossum Comment: I recall explicitly testing whether that installer worked on Win2000 without admin privileges. So I suspect it's something to do with tlau's set-up, and I don't think we will be able to get much further with this. (It doesn't help that we don't have the source code for the WISE installer generator, of course. :-( ) ------------------------------------------------------- Date: 2001-Jan-25 02:10 By: tim_one Comment: Curious! That's the right MD5 checksum. Yours is the only report of this we've ever gotten, though, while you're certainly not the only 2.0 Win2K user. It's possible that you're the only one who wasn't logged on to an admin account, though. Since you have Python running on Windows now, we can use it to compute the MD5 digest: >>> # change to path of your installer; "rb" is crucial >>> f = open("/updates/beopen-python-2.0.exe", "rb") >>> import md5 >>> print md5.md5(f.read()).hexdigest() 05f93fc81247dfb993f2e946016264c0 >>> If you still get the right checksum, we can rule out the file transfer, but then I'm stumped. Guess we'll have to report it as a bug to Wise, then (we're not generating the error msg you're seeing -- that's all an automatic function of the Wise installer). ------------------------------------------------------- Date: 2001-Jan-24 20:46 By: tlau Comment: I downloaded it using this link: http://www.python.org/ftp/python/2.0/BeOpen-Python-2.0.exe The first two times I used IE to click on the link. I didn't save those copies; I know the file size was around 5.8MB, but I don't know exactly. For the third try, I used ncftp on a Linux machine to get this file: ftp://ftp.python.org/pub/python/2.0/BeOpen-Python-2.0.exe I then used Samba to copy the file from my Linux home directory to the Win2k machine. I got the same error message (corrupt installation) for all three attempts. I then logged in as a user with admin privs, ran the third copy, and installation proceeded correctly. I don't know how to compute the checksum on Windows, but this is what I get from the copy I saved on my Linux system: % md5sum BeOpen-Python-2.0.exe 05f93fc81247dfb993f2e946016264c0 BeOpen-Python-2.0.exe ------------------------------------------------------- Date: 2001-Jan-24 20:07 By: tim_one Comment: I need someone else to confirm this (don't have W2K myself). Mark? If not, assign back to me. tlau, from where did you obtain the installer? Exactly how large is it? (If it's not exactly 5811039 bytes, it's definitely corrupt -- if it is that size, say so and we'll try an MD5 checksum next.) The Wise installer produces the "Corrupt installation detected" msg itself, when it gets a CRC mismatch after checksumming its internal components. We have no control over that, and in every previous case of this I know of it *did* mean the installer was corrupt. If you're not logged in with admin privileges, what's supposed to happen is that a box pops up telling you so, and asking whether you want to proceed with a weaker installation, or abort the installation. Testers reported that the 2.0 installer did exactly that, on NT and W2K (it's not an issue on 95, 98 or ME). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129998&group_id=5470 From noreply@sourceforge.net Fri Jan 26 04:51:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jan 2001 20:51:47 -0800 Subject: [Python-bugs-list] [Bug #130117] Python-2.1a1 sgi build _curses Module fix Message-ID: Bug #130117, was updated on 2001-Jan-25 20:51 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: pj99 Assigned to : nobody Summary: Python-2.1a1 sgi build _curses Module fix Details: The build of the _curses module on sgi (IRIX) fails, for want of an extern function declaration of tparm(). Without the following fix, the "setup.py build" fails on the _curses module with many complaints resembling: cc-1515 cc: ERROR File = /usr/people/pj/etc/python/Python-2.1a1/Python-2.1a1/Modules/_cursesmodule.c, Line = 2239 A value of type "int" cannot be assigned to an entity of type "char *". result = tparm(fmt); ^ With this fix, the compilation of _cursesmodule.c is clean. The patch is: *** _cursesmodule.c.orig Thu Jan 25 19:37:29 2001 --- _cursesmodule.c Thu Jan 25 20:39:10 2001 *************** *** 115,120 **** --- 115,121 ---- extern int setupterm(char *,int,int *); #ifdef sgi extern char *tigetstr(char *); + extern char *tparm(char *instring, ...); #endif #if defined(sgi) || defined(__sun__) For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130117&group_id=5470 From noreply@sourceforge.net Fri Jan 26 04:57:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jan 2001 20:57:05 -0800 Subject: [Python-bugs-list] [Bug #130117] Python-2.1a1 sgi build _curses Module fix Message-ID: Bug #130117, was updated on 2001-Jan-25 20:51 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: pj99 Assigned to : nobody Summary: Python-2.1a1 sgi build _curses Module fix Details: The build of the _curses module on sgi (IRIX) fails, for want of an extern function declaration of tparm(). Without the following fix, the "setup.py build" fails on the _curses module with many complaints resembling: cc-1515 cc: ERROR File = /usr/people/pj/etc/python/Python-2.1a1/Python-2.1a1/Modules/_cursesmodule.c, Line = 2239 A value of type "int" cannot be assigned to an entity of type "char *". result = tparm(fmt); ^ With this fix, the compilation of _cursesmodule.c is clean. The patch is: *** _cursesmodule.c.orig Thu Jan 25 19:37:29 2001 --- _cursesmodule.c Thu Jan 25 20:39:10 2001 *************** *** 115,120 **** --- 115,121 ---- extern int setupterm(char *,int,int *); #ifdef sgi extern char *tigetstr(char *); + extern char *tparm(char *instring, ...); #endif #if defined(sgi) || defined(__sun__) Follow-Ups: Date: 2001-Jan-25 20:57 By: pj99 Comment: Hmmm ... my original submission had some leading spaces removed. Lets try that patch one more time, to see if I can get it right. *** _cursesmodule.c.orig Thu Jan 25 19:37:29 2001 --- _cursesmodule.c Thu Jan 25 20:39:10 2001 *************** *** 115,120 **** --- 115,121 ---- extern int setupterm(char *,int,int *); #ifdef sgi extern char *tigetstr(char *); + extern char *tparm(char *instring, ...); #endif #if defined(sgi) || defined(__sun__) === Ok - the code lines above (in this little Netscape web editing window) each start in column two. Let's "Submit" and see if the end result shows that. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130117&group_id=5470 From noreply@sourceforge.net Fri Jan 26 04:59:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jan 2001 20:59:05 -0800 Subject: [Python-bugs-list] [Bug #130117] Python-2.1a1 sgi build _curses Module fix Message-ID: Bug #130117, was updated on 2001-Jan-25 20:51 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: pj99 Assigned to : nobody Summary: Python-2.1a1 sgi build _curses Module fix Details: The build of the _curses module on sgi (IRIX) fails, for want of an extern function declaration of tparm(). Without the following fix, the "setup.py build" fails on the _curses module with many complaints resembling: cc-1515 cc: ERROR File = /usr/people/pj/etc/python/Python-2.1a1/Python-2.1a1/Modules/_cursesmodule.c, Line = 2239 A value of type "int" cannot be assigned to an entity of type "char *". result = tparm(fmt); ^ With this fix, the compilation of _cursesmodule.c is clean. The patch is: *** _cursesmodule.c.orig Thu Jan 25 19:37:29 2001 --- _cursesmodule.c Thu Jan 25 20:39:10 2001 *************** *** 115,120 **** --- 115,121 ---- extern int setupterm(char *,int,int *); #ifdef sgi extern char *tigetstr(char *); + extern char *tparm(char *instring, ...); #endif #if defined(sgi) || defined(__sun__) Follow-Ups: Date: 2001-Jan-25 20:59 By: pj99 Comment: No - still wrong (still loosing leading spaces on each line). I give up. If someone knows how to submit patches without munging the spacing. I'd be interested to learn. Sorry. ------------------------------------------------------- Date: 2001-Jan-25 20:57 By: pj99 Comment: Hmmm ... my original submission had some leading spaces removed. Lets try that patch one more time, to see if I can get it right. *** _cursesmodule.c.orig Thu Jan 25 19:37:29 2001 --- _cursesmodule.c Thu Jan 25 20:39:10 2001 *************** *** 115,120 **** --- 115,121 ---- extern int setupterm(char *,int,int *); #ifdef sgi extern char *tigetstr(char *); + extern char *tparm(char *instring, ...); #endif #if defined(sgi) || defined(__sun__) === Ok - the code lines above (in this little Netscape web editing window) each start in column two. Let's "Submit" and see if the end result shows that. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130117&group_id=5470 From noreply@sourceforge.net Fri Jan 26 06:19:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jan 2001 22:19:36 -0800 Subject: [Python-bugs-list] [Bug #130030] Claim of bad betavariate algorithm Message-ID: Bug #130030, was updated on 2001-Jan-25 03:03 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: tim_one Assigned to : tim_one Summary: Claim of bad betavariate algorithm Details: From c.l.py. Beats me, but sounds credible. random.py cites Discrete Event Simulation in C, pp 87-88, for its algorithm. """ [Janne Sinkkonen (mailto:janne@mansikka.nnets.fi)] At least in Python 2.0 and earlier, the samples returned by the function betavariate() of random.py are not from a beta distribution although the function name misleadingly suggests so. The following would give beta-distributed samples: def betavariate(alpha, beta): y = gammavariate(alpha,1) if y==0: return 0.0 else: return y/(y+gammavariate(beta,1)) This is from matlab. A comment in the original matlab code refers to Devroye, L. (1986) Non-Uniform Random Variate Generation, theorem 4.1A (p. 430). Another reference would be Gelman, A. et al. (1995) Bayesian data analysis, p. 481, which I have checked and found to agree with the code above. """ Follow-Ups: Date: 2001-Jan-25 22:19 By: tim_one Comment: c.l.py post by Ivan Frohne: I'm convinced that Janne Sinkkonen is right: The beta distribution generator in module random.py does not return Beta-distributed random numbers. Janne's suggested fix should work just fine. Here's my guess on how and why this bug bit -- it won't be of interest to most but this subject is so obscure sometimes that there needs to be a detailed analysis. The probability density function of the gamma distribution with (positive) parameters A and B is usually written g(x; A, B) = (x**(A-1) * exp(x/B)) / (Gamma(A) * B**A), where x, A, and B > 0. Here Gamma(A) is the gamma function -- for A a positive integer, Gamma(A) is the factorial of A - 1, Gamma(A) = (A-1)!. In fact, this is the definition used by the authors of random.py in defining gammavariate(alpha, beta), the gamma distribution random number generator. Now it happens that a gamma-distributed random variable with parameters A = 1 and B has the (much simpler) exponential distribution with density function g(x; 1, B) = exp(-x/B) / B. Keep that in mind. The reference "Discrete Event Simulation in ," by Kevin Watkins (McGraw-Hill, 1993) was consulted by the random.py authors. But this reference defines the gamma probability distribution a little differently, as g1(x; A, B) = (B**A * x**(A-1) * exp(B*x)) / Gamma(A), where x, A, B > 0. (See p. 85). On page 87, Watkins states (incorrectly) that if grv(A, B) is a function which returns a gamma random variable with parameters A and B (using his definition on p. 85), then the function brv(A, B) = grv(1, 1/B) / ( grv(1, 1/B) + grv(1, A) ) [ not true!] will return a random variable which has the beta distribution with parameters A and B. Believing Watkins to be correct, the random.py authors remembered that a gamma random variable with parameter A = 1 is just an exponential random variable and further simplified their beta generator to brv(A, B) = erv(1/B) / (erv(1/B) + erv(A)), where erv(K) is a random variable having the exponential distribution with parameter K. The corrected equation for a beta random variable, using Watkins' definition of the gamma density, is brv(A, B) = grv(A, 1) / ( grv(A, 1) + grv(1/B, 1) ), which translates to brv(A, B) = grv(A, 1) / (grv(A, 1) + grv(B, 1) using the more common gamma density definition (the one used in random.py). Many standard statistical references give this equation -- two are "Non-Uniform random Variate Generation," by Luc Devroye, Springer-Verlag, 1986, p. 432, and "Monte Carlo Concepts, Algorithms and Applications," by George S. Fishman, Springer, 1996, p. 200. --Ivan Frohne ------------------------------------------------------- Date: 2001-Jan-25 13:36 By: tim_one Comment: I have no idea why the Group was set to Irreproducible, but have seen that on other recent new bug reports too -- maybe a new SF buglet. Anyway, changed group to None. Ivan Frohne helpfully investigated this, and made what looks to be a very strong case for adopting the algorithm Janne suggests. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130030&group_id=5470 From noreply@sourceforge.net Fri Jan 26 06:34:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jan 2001 22:34:26 -0800 Subject: [Python-bugs-list] [Bug #130030] Claim of bad betavariate algorithm Message-ID: Bug #130030, was updated on 2001-Jan-25 03:03 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: tim_one Assigned to : tim_one Summary: Claim of bad betavariate algorithm Details: From c.l.py. Beats me, but sounds credible. random.py cites Discrete Event Simulation in C, pp 87-88, for its algorithm. """ [Janne Sinkkonen (mailto:janne@mansikka.nnets.fi)] At least in Python 2.0 and earlier, the samples returned by the function betavariate() of random.py are not from a beta distribution although the function name misleadingly suggests so. The following would give beta-distributed samples: def betavariate(alpha, beta): y = gammavariate(alpha,1) if y==0: return 0.0 else: return y/(y+gammavariate(beta,1)) This is from matlab. A comment in the original matlab code refers to Devroye, L. (1986) Non-Uniform Random Variate Generation, theorem 4.1A (p. 430). Another reference would be Gelman, A. et al. (1995) Bayesian data analysis, p. 481, which I have checked and found to agree with the code above. """ Follow-Ups: Date: 2001-Jan-25 22:34 By: tim_one Comment: And my reply: [Ivan Frohne] > I'm convinced that Janne Sinkkonen is right: The beta distribution > generator in module random.py does not return Beta-distributed random > numbers. Janne's suggested fix should work just fine. Which is (for reference): def betavariate(alpha, beta): y = gammavariate(alpha,1) if y==0: return 0.0 else: return y/(y+gammavariate(beta,1)) > Here's my guess on how and why this bug bit -- it won't be of interest > to most but this subject is so obscure sometimes that there needs to > be a detailed analysis. > ... Which I'll skip, since it's immortalized already in c.l.py and the bug report: https://sourceforge.net/bugs/?func=detailbug&bug_id=130030&group_id=5470 > ... > The corrected equation for a beta random variable, using Watkins' > definition of the gamma density, is > > brv(A, B) = grv(A, 1) / ( grv(A, 1) + grv(1/B, 1) ), > > which translates to > > brv(A, B) = grv(A, 1) / (grv(A, 1) + grv(B, 1) > > using the more common gamma density definition (the one used in random. > py). Now that seems plain wrong, although I hope it's just typographical confusions: 1. You don't really mean to generate two independent instances of grv(A, 1), right? 2. The parens around the summand denominator have magically disappeared, changing something of the form X/(X+Y) to (X/X)+Y. > Many standard statistical references give this equation -- two are > "Non-Uniform random Variate Generation," by Luc Devroye, Springer-Verlag, > 1986, p. 432, and "Monte Carlo Concepts, Algorithms and Applications," > by George S. Fishman, Springer, 1996, p. 200. So does Knuth, Vol 3 Ed 3 (in the X/(X+Y) form), although he's not careful (as was Janne) to avoid division by 0. So I'll check in Janne's code as-is. Thank you for the analysis! It was an enlightening help. ------------------------------------------------------- Date: 2001-Jan-25 22:19 By: tim_one Comment: c.l.py post by Ivan Frohne: I'm convinced that Janne Sinkkonen is right: The beta distribution generator in module random.py does not return Beta-distributed random numbers. Janne's suggested fix should work just fine. Here's my guess on how and why this bug bit -- it won't be of interest to most but this subject is so obscure sometimes that there needs to be a detailed analysis. The probability density function of the gamma distribution with (positive) parameters A and B is usually written g(x; A, B) = (x**(A-1) * exp(x/B)) / (Gamma(A) * B**A), where x, A, and B > 0. Here Gamma(A) is the gamma function -- for A a positive integer, Gamma(A) is the factorial of A - 1, Gamma(A) = (A-1)!. In fact, this is the definition used by the authors of random.py in defining gammavariate(alpha, beta), the gamma distribution random number generator. Now it happens that a gamma-distributed random variable with parameters A = 1 and B has the (much simpler) exponential distribution with density function g(x; 1, B) = exp(-x/B) / B. Keep that in mind. The reference "Discrete Event Simulation in ," by Kevin Watkins (McGraw-Hill, 1993) was consulted by the random.py authors. But this reference defines the gamma probability distribution a little differently, as g1(x; A, B) = (B**A * x**(A-1) * exp(B*x)) / Gamma(A), where x, A, B > 0. (See p. 85). On page 87, Watkins states (incorrectly) that if grv(A, B) is a function which returns a gamma random variable with parameters A and B (using his definition on p. 85), then the function brv(A, B) = grv(1, 1/B) / ( grv(1, 1/B) + grv(1, A) ) [ not true!] will return a random variable which has the beta distribution with parameters A and B. Believing Watkins to be correct, the random.py authors remembered that a gamma random variable with parameter A = 1 is just an exponential random variable and further simplified their beta generator to brv(A, B) = erv(1/B) / (erv(1/B) + erv(A)), where erv(K) is a random variable having the exponential distribution with parameter K. The corrected equation for a beta random variable, using Watkins' definition of the gamma density, is brv(A, B) = grv(A, 1) / ( grv(A, 1) + grv(1/B, 1) ), which translates to brv(A, B) = grv(A, 1) / (grv(A, 1) + grv(B, 1) using the more common gamma density definition (the one used in random.py). Many standard statistical references give this equation -- two are "Non-Uniform random Variate Generation," by Luc Devroye, Springer-Verlag, 1986, p. 432, and "Monte Carlo Concepts, Algorithms and Applications," by George S. Fishman, Springer, 1996, p. 200. --Ivan Frohne ------------------------------------------------------- Date: 2001-Jan-25 13:36 By: tim_one Comment: I have no idea why the Group was set to Irreproducible, but have seen that on other recent new bug reports too -- maybe a new SF buglet. Anyway, changed group to None. Ivan Frohne helpfully investigated this, and made what looks to be a very strong case for adopting the algorithm Janne suggests. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130030&group_id=5470 From noreply@sourceforge.net Fri Jan 26 06:51:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jan 2001 22:51:54 -0800 Subject: [Python-bugs-list] [Bug #130030] Claim of bad betavariate algorithm Message-ID: Bug #130030, was updated on 2001-Jan-25 03:03 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: tim_one Assigned to : tim_one Summary: Claim of bad betavariate algorithm Details: From c.l.py. Beats me, but sounds credible. random.py cites Discrete Event Simulation in C, pp 87-88, for its algorithm. """ [Janne Sinkkonen (mailto:janne@mansikka.nnets.fi)] At least in Python 2.0 and earlier, the samples returned by the function betavariate() of random.py are not from a beta distribution although the function name misleadingly suggests so. The following would give beta-distributed samples: def betavariate(alpha, beta): y = gammavariate(alpha,1) if y==0: return 0.0 else: return y/(y+gammavariate(beta,1)) This is from matlab. A comment in the original matlab code refers to Devroye, L. (1986) Non-Uniform Random Variate Generation, theorem 4.1A (p. 430). Another reference would be Gelman, A. et al. (1995) Bayesian data analysis, p. 481, which I have checked and found to agree with the code above. """ Follow-Ups: Date: 2001-Jan-25 22:51 By: tim_one Comment: Fixed; dhecked in to random.py rev 1.19, ACKS rev 1.74. ------------------------------------------------------- Date: 2001-Jan-25 22:34 By: tim_one Comment: And my reply: [Ivan Frohne] > I'm convinced that Janne Sinkkonen is right: The beta distribution > generator in module random.py does not return Beta-distributed random > numbers. Janne's suggested fix should work just fine. Which is (for reference): def betavariate(alpha, beta): y = gammavariate(alpha,1) if y==0: return 0.0 else: return y/(y+gammavariate(beta,1)) > Here's my guess on how and why this bug bit -- it won't be of interest > to most but this subject is so obscure sometimes that there needs to > be a detailed analysis. > ... Which I'll skip, since it's immortalized already in c.l.py and the bug report: https://sourceforge.net/bugs/?func=detailbug&bug_id=130030&group_id=5470 > ... > The corrected equation for a beta random variable, using Watkins' > definition of the gamma density, is > > brv(A, B) = grv(A, 1) / ( grv(A, 1) + grv(1/B, 1) ), > > which translates to > > brv(A, B) = grv(A, 1) / (grv(A, 1) + grv(B, 1) > > using the more common gamma density definition (the one used in random. > py). Now that seems plain wrong, although I hope it's just typographical confusions: 1. You don't really mean to generate two independent instances of grv(A, 1), right? 2. The parens around the summand denominator have magically disappeared, changing something of the form X/(X+Y) to (X/X)+Y. > Many standard statistical references give this equation -- two are > "Non-Uniform random Variate Generation," by Luc Devroye, Springer-Verlag, > 1986, p. 432, and "Monte Carlo Concepts, Algorithms and Applications," > by George S. Fishman, Springer, 1996, p. 200. So does Knuth, Vol 3 Ed 3 (in the X/(X+Y) form), although he's not careful (as was Janne) to avoid division by 0. So I'll check in Janne's code as-is. Thank you for the analysis! It was an enlightening help. ------------------------------------------------------- Date: 2001-Jan-25 22:19 By: tim_one Comment: c.l.py post by Ivan Frohne: I'm convinced that Janne Sinkkonen is right: The beta distribution generator in module random.py does not return Beta-distributed random numbers. Janne's suggested fix should work just fine. Here's my guess on how and why this bug bit -- it won't be of interest to most but this subject is so obscure sometimes that there needs to be a detailed analysis. The probability density function of the gamma distribution with (positive) parameters A and B is usually written g(x; A, B) = (x**(A-1) * exp(x/B)) / (Gamma(A) * B**A), where x, A, and B > 0. Here Gamma(A) is the gamma function -- for A a positive integer, Gamma(A) is the factorial of A - 1, Gamma(A) = (A-1)!. In fact, this is the definition used by the authors of random.py in defining gammavariate(alpha, beta), the gamma distribution random number generator. Now it happens that a gamma-distributed random variable with parameters A = 1 and B has the (much simpler) exponential distribution with density function g(x; 1, B) = exp(-x/B) / B. Keep that in mind. The reference "Discrete Event Simulation in ," by Kevin Watkins (McGraw-Hill, 1993) was consulted by the random.py authors. But this reference defines the gamma probability distribution a little differently, as g1(x; A, B) = (B**A * x**(A-1) * exp(B*x)) / Gamma(A), where x, A, B > 0. (See p. 85). On page 87, Watkins states (incorrectly) that if grv(A, B) is a function which returns a gamma random variable with parameters A and B (using his definition on p. 85), then the function brv(A, B) = grv(1, 1/B) / ( grv(1, 1/B) + grv(1, A) ) [ not true!] will return a random variable which has the beta distribution with parameters A and B. Believing Watkins to be correct, the random.py authors remembered that a gamma random variable with parameter A = 1 is just an exponential random variable and further simplified their beta generator to brv(A, B) = erv(1/B) / (erv(1/B) + erv(A)), where erv(K) is a random variable having the exponential distribution with parameter K. The corrected equation for a beta random variable, using Watkins' definition of the gamma density, is brv(A, B) = grv(A, 1) / ( grv(A, 1) + grv(1/B, 1) ), which translates to brv(A, B) = grv(A, 1) / (grv(A, 1) + grv(B, 1) using the more common gamma density definition (the one used in random.py). Many standard statistical references give this equation -- two are "Non-Uniform random Variate Generation," by Luc Devroye, Springer-Verlag, 1986, p. 432, and "Monte Carlo Concepts, Algorithms and Applications," by George S. Fishman, Springer, 1996, p. 200. --Ivan Frohne ------------------------------------------------------- Date: 2001-Jan-25 13:36 By: tim_one Comment: I have no idea why the Group was set to Irreproducible, but have seen that on other recent new bug reports too -- maybe a new SF buglet. Anyway, changed group to None. Ivan Frohne helpfully investigated this, and made what looks to be a very strong case for adopting the algorithm Janne suggests. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130030&group_id=5470 From noreply@sourceforge.net Fri Jan 26 07:06:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jan 2001 23:06:11 -0800 Subject: [Python-bugs-list] [Bug #129998] "Corrupt installation" when installed without admin privs Message-ID: Bug #129998, was updated on 2001-Jan-24 17:57 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Closed Resolution: Wont Fix Bug Group: 3rd Party Priority: 1 Submitted by: tlau Assigned to : tim_one Summary: "Corrupt installation" when installed without admin privs Details: On Windows 2000, when logged in a user without administrator privileges, attempting to run the Python 2.0 installer results in a single dialog box saying "Corrupt installation detected" and then the installer exits. This should be a more informative error message. I downloaded the 5MB installer three times before suspecting the correct cause of the problem. When the same binary is run as a user with the correct privileges, it correctly begins the installation process. Follow-Ups: Date: 2001-Jan-25 23:06 By: tim_one Comment: tlau, thanks a lot for helping us here! I wish we could help you in return, but Guido is right, there's really nothing we can do about it now. Well, a long-term plan is to move to a more recent Windows installation program (the one we're using was developed before Win2K was even a rumor!), but that's not going to happen soon. For a good time, download ActiveState's Python Windows installer, and see whether it blows up too: no reason you can't be disappointed by all of us . ------------------------------------------------------- Date: 2001-Jan-25 14:27 By: gvanrossum Comment: Then this is most likely a bug we can't fix. The"Corrupt installation" check is made AFAIK by the WISE installer code before it runs any of the script. One of the system checks it does must be using something that's disallowed by Win2K in Restricted User mode. We have control over the script -- it tests for Administrator privileges and offers to proceed; but we have no control over the system check before it runs. I haven't seen this complaint before, so I presume it's unlikely to happen (Restricted Users typically won't want to install software :-). I'll leave it up to Tim, but personally, I'd just close the report as "Won't Fix" and "3rd party". ------------------------------------------------------- Date: 2001-Jan-25 13:22 By: tlau Comment: I did some more investigating. Python prints the correct md5 checksum for the installer; but that's a red herring. In the "Users and Passwords" control panel, my account is set up as a "Restricted user" (Users Group) account. When I change this setting to "Standard user" (Power Users Group), then launching the installer prompts me to proceed with a weaker installation (as expected). Changing the setting back to "Restricted user" and re-running the installer produces the "corrupt installation detected" message yet again. ------------------------------------------------------- Date: 2001-Jan-25 04:52 By: gvanrossum Comment: I recall explicitly testing whether that installer worked on Win2000 without admin privileges. So I suspect it's something to do with tlau's set-up, and I don't think we will be able to get much further with this. (It doesn't help that we don't have the source code for the WISE installer generator, of course. :-( ) ------------------------------------------------------- Date: 2001-Jan-25 02:10 By: tim_one Comment: Curious! That's the right MD5 checksum. Yours is the only report of this we've ever gotten, though, while you're certainly not the only 2.0 Win2K user. It's possible that you're the only one who wasn't logged on to an admin account, though. Since you have Python running on Windows now, we can use it to compute the MD5 digest: >>> # change to path of your installer; "rb" is crucial >>> f = open("/updates/beopen-python-2.0.exe", "rb") >>> import md5 >>> print md5.md5(f.read()).hexdigest() 05f93fc81247dfb993f2e946016264c0 >>> If you still get the right checksum, we can rule out the file transfer, but then I'm stumped. Guess we'll have to report it as a bug to Wise, then (we're not generating the error msg you're seeing -- that's all an automatic function of the Wise installer). ------------------------------------------------------- Date: 2001-Jan-24 20:46 By: tlau Comment: I downloaded it using this link: http://www.python.org/ftp/python/2.0/BeOpen-Python-2.0.exe The first two times I used IE to click on the link. I didn't save those copies; I know the file size was around 5.8MB, but I don't know exactly. For the third try, I used ncftp on a Linux machine to get this file: ftp://ftp.python.org/pub/python/2.0/BeOpen-Python-2.0.exe I then used Samba to copy the file from my Linux home directory to the Win2k machine. I got the same error message (corrupt installation) for all three attempts. I then logged in as a user with admin privs, ran the third copy, and installation proceeded correctly. I don't know how to compute the checksum on Windows, but this is what I get from the copy I saved on my Linux system: % md5sum BeOpen-Python-2.0.exe 05f93fc81247dfb993f2e946016264c0 BeOpen-Python-2.0.exe ------------------------------------------------------- Date: 2001-Jan-24 20:07 By: tim_one Comment: I need someone else to confirm this (don't have W2K myself). Mark? If not, assign back to me. tlau, from where did you obtain the installer? Exactly how large is it? (If it's not exactly 5811039 bytes, it's definitely corrupt -- if it is that size, say so and we'll try an MD5 checksum next.) The Wise installer produces the "Corrupt installation detected" msg itself, when it gets a CRC mismatch after checksumming its internal components. We have no control over that, and in every previous case of this I know of it *did* mean the installer was corrupt. If you're not logged in with admin privileges, what's supposed to happen is that a box pops up telling you so, and asking whether you want to proceed with a weaker installation, or abort the installation. Testers reported that the 2.0 installer did exactly that, on NT and W2K (it's not an issue on 95, 98 or ME). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129998&group_id=5470 From noreply@sourceforge.net Fri Jan 26 07:11:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jan 2001 23:11:09 -0800 Subject: [Python-bugs-list] [Bug #113785] SIGSEGV in PyDict_SetItem Message-ID: Bug #113785, was updated on 2000-Sep-07 01:51 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Closed Resolution: Works For Me Bug Group: 3rd Party Priority: 5 Submitted by: nobody Assigned to : gvanrossum Summary: SIGSEGV in PyDict_SetItem Details: On a PC running FreeBSD 3.5 Python 1.5.2 (#1, Aug 23 2000, 10:14:09) [GCC 2.95 19990728 (release)] on freebsd3 I installed Python to run a filter that comes with inn 2.3.0 (usenet News) Some time the fiter written in Python hangs with the following (from gdb) Program received signal SIGSEGV, Segmentation fault. 0x810465b in PyDict_SetItem (op=0x83c6a80, key=0x83d4020, value=0x0) at dictobject.c:375 375 Py_INCREF(value); I suspect that the Python filter may be # # $Id: filter_innd.py,v 1.2 1999/09/23 14:24:23 kondou Exp $ # # This is a sample filter for the Python innd hook. # # For details, see the file README.python_hook that came with INN. # import re from string import * # This looks weird, but creating and interning these strings should # let us get faster access to header keys (which innd also interns) by # losing some strcmps under the covers. Approved = intern("Approved"); Control = intern("Control") Date = intern("Date"); Distribution = intern("Distribution") Expires = intern("Expires"); From = intern("From") Lines = intern("Lines"); Message_ID = intern("Message-ID") Newsgroups = intern("Newsgroups"); Path = intern("Path") Reply_To = intern("Reply-To"); Sender = intern("Sender") Subject = intern("Subject"); Supersedes = intern("Supersedes") Bytes = intern("Bytes"); Also_Control = intern("Also-Control") References = intern("References"); Xref = intern("Xref") Keywords = intern("Keywords"); X_Trace = intern("X-Trace") NNTP_Posting_Host = intern("NNTP-Posting-Host") Followup_To = intern("Followup-To"); Organization = intern("Organization") Content_Type = intern("Content-Type"); Content_Base = intern("Content-Base") Content_Disposition = intern("Content-Disposition") X_Newsreader = intern("X-Newsreader"); X_Mailer = intern("X-Mailer") X_Newsposter = intern("X-Newsposter") X_Cancelled_By = intern("X-Cancelled-By") X_Canceled_By = intern("X-Canceled-By"); Cancel_Key = intern("Cancel-Key") __BODY__ = intern("__BODY__"); __LINES__ = intern("__LINES__") class InndFilter: """Provide filtering callbacks to innd.""" def __init__(self): """This runs every time the filter is loaded or reloaded. This is a good place to initialize variables and precompile regular expressions, or maybe reload stats from disk. """ self.re_newrmgroup = re.compile('(?:new|rm)group\s') self.re_obsctl = re.compile('(?:sendsys|version|uuname)') # msgid pattern from a once-common spambot. self.re_none44 = re.compile('none\d+\.yet>') # There is a mad newgrouper who likes to meow. self.re_meow = re.compile("^Meow\!", re.M) # One of my silly addresses. self.re_fluffymorph = re.compile("andruQ@myremarQ.coM", re.I) def filter_before_reload(self): """Runs just before the filter gets reloaded. You can use this method to save state information to be restored by the __init__() method or down in the main module. """ syslog('notice', "filter_before_reload executing...") def filter_close(self): """Runs when innd exits. You can use this method to save state information to be restored by the __init__() method or down in the main module. """ syslog('notice', "filter_close running, bye!") def filter_messageid(self, msgid): """Filter articles just by their message IDs. This method interacts with the IHAVE and CHECK NNTP commands. If you return a non-empty string here, the offered article will be refused before you ever have to waste any bandwidth looking at it. This is not foolproof, so you should do your ID checks both here and in filter_art. (TAKETHIS does not offer the ID for examination, and a TAKETHIS isn't always preceded by a CHECK.) """ return "" # deactivate the samples. if self.re_none44.search(msgid): return "But I don't like spam!" if msgid[0:8] == '\r Path: news.nectec.or.th!news.loxinfo.co.th!news-out.cwix.com!newsfeed.\ cwix.com!newsfeeds.belnet.be!news.belnet.be!newsgate.cistron.nl!bullse\ ye.news.demon.net!demon!news.demon.co.uk!demon!inert.demon.co.uk!not-f\ or-mail\r From: inert@inert.demon.co.uk\r Newsgroups: rec.music.industrial\r Subject: *** CLUB NOIR *** 31/8/00\r Date: Wed, 30 Aug 2000 19:47:53 GMT\r Organization: inertia\r Message-ID: <967664873.12710.1.nnrp-02.9e98fa8b@news.demon.co.uk>\r NNTP-Posting-Host: inert.demon.co.uk\r X-NNTP-Posting-Host: inert.demon.co.uk:158.152.250.139\r X-Trace: news.demon.co.uk 967664873 nnrp-02:12710 NO-IDENT inert.demon\ .co.uk:158.152.250.139\r X-Complaints-To: abuse@demon.net\r X-Mailer: Mozilla 1.22 (Windows; I; 16bit)\r MIME-Version: 1.0\r Lines: 0\r Xref: news.nectec.or.th rec.music.industrial:137401\r \r .\r So, for an easy solution, I can disable Python filtering and then inn will be working fine. But even if the filter was not doing what it is supposed to do, Python should not SIGSEGV I presume. Beside Python installed without problem and make test result is: 42 tests OK. 19 tests skipped: test_al test_audioop test_bsddb test_cd test_cl test_crypt test_dbm test_dl test_gdbm test_gl test_gzip test_imageop test_imgfile test_nis test_rgbimg test_sunaudiodev test_thread test_timing test_zlib For more info: on@cs.ait.ac.th Thank you, Olivier Follow-Ups: Date: 2001-Jan-25 23:11 By: meowing Comment: Not a Python bug. An off-by-1 error had crept into in innd; reported to inn-bugs and fixed in December 2000. FWIW, INN embeds Python, and the INN module is a C extension built into innd. ------------------------------------------------------- Date: 2000-Sep-12 16:52 By: gvanrossum Comment: I'm closing this because I have not enough information, and I have no way to reproduce the problem. If you provide more information I'll gladly reopen it. Some questions: - How does inn invoke Python? Does it embed Python or does it run Python as a subprocess? Is there any INN specific extension C code? - What's in the INN module? ------------------------------------------------------- Date: 2000-Sep-07 15:04 By: jhylton Comment: Please do triage on this bug. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=113785&group_id=5470 From noreply@sourceforge.net Fri Jan 26 14:46:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 06:46:24 -0800 Subject: [Python-bugs-list] [Bug #130165] Python 2.1a1 Makefile changed OPT value not used in module compilation Message-ID: Bug #130165, was updated on 2001-Jan-26 06:46 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : nobody Summary: Python 2.1a1 Makefile changed OPT value not used in module compilation Details: When the top level "Makefile" value used for the variable "OPT" is changed after executing "configure", that new value is used to compile "python", but is *not* used during the compilation of the modules. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130165&group_id=5470 From noreply@sourceforge.net Fri Jan 26 15:21:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 07:21:52 -0800 Subject: [Python-bugs-list] [Bug #130077] one-line typo in arraymodule.c Message-ID: Bug #130077, was updated on 2001-Jan-25 12:31 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: yole Assigned to : gvanrossum Summary: one-line typo in arraymodule.c Details: Line 470 of arraymodule.c in Python-2.1alpha1 reads: case Py_LE: cmp = ws <= ws; break; It should be: case Py_LE: cmp = vs <= ws; break; Follow-Ups: Date: 2001-Jan-26 07:21 By: fdrake Comment: Guido already checked in the fix in Modules/arraymodule.c revision 2.62. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130077&group_id=5470 From noreply@sourceforge.net Fri Jan 26 15:22:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 07:22:53 -0800 Subject: [Python-bugs-list] [Bug #130117] Python-2.1a1 sgi build _curses Module fix Message-ID: Bug #130117, was updated on 2001-Jan-25 20:51 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: pj99 Assigned to : akuchling Summary: Python-2.1a1 sgi build _curses Module fix Details: The build of the _curses module on sgi (IRIX) fails, for want of an extern function declaration of tparm(). Without the following fix, the "setup.py build" fails on the _curses module with many complaints resembling: cc-1515 cc: ERROR File = /usr/people/pj/etc/python/Python-2.1a1/Python-2.1a1/Modules/_cursesmodule.c, Line = 2239 A value of type "int" cannot be assigned to an entity of type "char *". result = tparm(fmt); ^ With this fix, the compilation of _cursesmodule.c is clean. The patch is: *** _cursesmodule.c.orig Thu Jan 25 19:37:29 2001 --- _cursesmodule.c Thu Jan 25 20:39:10 2001 *************** *** 115,120 **** --- 115,121 ---- extern int setupterm(char *,int,int *); #ifdef sgi extern char *tigetstr(char *); + extern char *tparm(char *instring, ...); #endif #if defined(sgi) || defined(__sun__) Follow-Ups: Date: 2001-Jan-25 20:59 By: pj99 Comment: No - still wrong (still loosing leading spaces on each line). I give up. If someone knows how to submit patches without munging the spacing. I'd be interested to learn. Sorry. ------------------------------------------------------- Date: 2001-Jan-25 20:57 By: pj99 Comment: Hmmm ... my original submission had some leading spaces removed. Lets try that patch one more time, to see if I can get it right. *** _cursesmodule.c.orig Thu Jan 25 19:37:29 2001 --- _cursesmodule.c Thu Jan 25 20:39:10 2001 *************** *** 115,120 **** --- 115,121 ---- extern int setupterm(char *,int,int *); #ifdef sgi extern char *tigetstr(char *); + extern char *tparm(char *instring, ...); #endif #if defined(sgi) || defined(__sun__) === Ok - the code lines above (in this little Netscape web editing window) each start in column two. Let's "Submit" and see if the end result shows that. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130117&group_id=5470 From noreply@sourceforge.net Fri Jan 26 15:25:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 07:25:02 -0800 Subject: [Python-bugs-list] [Bug #129762] Python 2.1a1 build on Irix - Makefile syntax Message-ID: Bug #129762, was updated on 2001-Jan-22 21:03 Here is a current snapshot of the bug. Project: Python Category: Build Status: Closed Resolution: Invalid Bug Group: Platform-specific Priority: 5 Submitted by: pj99 Assigned to : fdrake Summary: Python 2.1a1 build on Irix - Makefile syntax Details: A plain "./configure; make" of the new (Thanks!) alpha 1 of Python 2.1 fails on SGI's Irix 6.5.10, with a syntax error in Modules/Makefile.pre. The Make variable DLLLIBRARY is empty, causing the Makefile line: $(DLLLIBRARY): $(LIBRARY) to fail with the message: .../Python-2.1a1/Modules make: file `Makefile.pre' line 132: Syntax error *** Error code 1 (bu21) >From what I can tell, DLLLIBRARY is only useful on Cygnus. But I'd guess it would be better to set it to the same value as in LIBRARY on other platforms, rather than leave it empty, for those variants of make that don't like an empty target. In any case, the following change in Modules/Makefile.pre seems to workaround this problem and let the make continue, at least on Irix: Change line 108 from: DLLLIBRARY= to: DLLLIBRARY= $(LIBRARY) Follow-Ups: Date: 2001-Jan-26 07:25 By: fdrake Comment: Modules/Makefile.pre will no longer be used starting with 2.1a2, so no action is needed. (But thanks for reporting the problem!) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129762&group_id=5470 From noreply@sourceforge.net Fri Jan 26 15:28:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 07:28:17 -0800 Subject: [Python-bugs-list] [Bug #129759] typo Message-ID: Bug #129759, was updated on 2001-Jan-22 19:41 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: noah Assigned to : fdrake Summary: typo Details: URL to document page: http://www.python.org/doc/current/ref/programs.html search for the word "coplete" in this context: "The initial environment is identical to that of a coplete program; each statement is executed in the namespace of __main__. " I believe that the first word of that second line should be "complete", not "coplete". Yours, Noah Follow-Ups: Date: 2001-Jan-26 07:28 By: fdrake Comment: Fixed in Doc/ref/ref8.tex revision 1.12. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129759&group_id=5470 From noreply@sourceforge.net Fri Jan 26 15:29:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 07:29:19 -0800 Subject: [Python-bugs-list] [Bug #129788] cgi module. FieldStorage class returns keys blank fields. Message-ID: Bug #129788, was updated on 2001-Jan-23 01:28 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : akuchling Summary: cgi module. FieldStorage class returns keys blank fields. Details: In module cgi.py The FieldStorage class returns keys for blank values even though the keep_blank_values property is set to 0 The problem lies in the parse_qsl method. The second last line of the function r.append((name, value)) should read if (len(value) or keep_blank_values): r.append((name, value)) I hope this can be corrected. Thanks Follow-Ups: Date: 2001-Jan-26 07:29 By: fdrake Comment: Assigned to Andrew since he knows more about CGI stuff than I ever expect to. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129788&group_id=5470 From noreply@sourceforge.net Fri Jan 26 15:30:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 07:30:33 -0800 Subject: [Python-bugs-list] [Bug #129994] problem building readline extension on linux Message-ID: Bug #129994, was updated on 2001-Jan-24 16:40 Here is a current snapshot of the bug. Project: Python Category: Extension Modules Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: bcollar Assigned to : lemburg Summary: problem building readline extension on linux Details: Howdy Using debian stable, 2.2.18pre1. Configure ran fine, python built okay, but the readline extension failed to build with this error: building 'readline' extension gcc -g -O2 -Wall -Wstrict-prototypes -fPIC -fpic -I. -I/tmp/Python-2.1a1/./Include -IInclude/ -I/usr/local/include -c /tmp/Python-2.1a1/Modules/readline.c -o build/temp.linux-i586-2.1/readline.o gcc -shared build/temp.linux-i586-2.1/readline.o -L/usr/local/lib -lreadline -ltermcap -o build/lib.linux-i586-2.1/readline.so /usr/bin/ld: cannot find -ltermcap collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 make: *** [sharedmods] Error 1 Follow-Ups: Date: 2001-Jan-26 07:30 By: fdrake Comment: Assigned to Marc-Andre since he's already working on this one. I think this is a duplicate as well. ------------------------------------------------------- Date: 2001-Jan-24 16:51 By: bcollar Comment: I just looked at the setup.py script, and this line I'm figuring is the problem: if (self.compiler.find_library_file(lib_dirs, 'readline')): exts.append( Extension('readline', ['readline.c'], libraries=['readline', 'termcap']) ) since libraries includes termcap, the the find_library_file should also look for termcap, no? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129994&group_id=5470 From noreply@sourceforge.net Fri Jan 26 15:45:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 07:45:47 -0800 Subject: [Python-bugs-list] [Bug #130165] Python 2.1a1 Makefile changed OPT value not used in module c Message-ID: Bug #130165, was updated on 2001-Jan-26 06:46 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : akuchling Summary: Python 2.1a1 Makefile changed OPT value not used in module c Details: When the top level "Makefile" value used for the variable "OPT" is changed after executing "configure", that new value is used to compile "python", but is *not* used during the compilation of the modules. Follow-Ups: Date: 2001-Jan-26 07:45 By: nascheme Comment: Hmm, perhaps the makefile could pass OPT to the distutils setup.py script. Andrew knows better than I how to solve this. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130165&group_id=5470 From noreply@sourceforge.net Fri Jan 26 17:22:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 09:22:02 -0800 Subject: [Python-bugs-list] [Bug #129904] 2.1a1: lib-tk not in sys.path: import fails Message-ID: Bug #129904, was updated on 2001-Jan-23 22:22 Here is a current snapshot of the bug. Project: Python Category: Tkinter Status: Open Resolution: None Bug Group: Platform-specific Priority: 7 Submitted by: sdm7g Assigned to : gvanrossum Summary: 2.1a1: lib-tk not in sys.path: import fails Details: "import Tkinter" fails on the new 2.1a1 build. The new setup.py script correctly finds the libraries and builds it automatically, but lib-tk is no longer put into sys.path as it was in 2.0. -- Steve M. Follow-Ups: Date: 2001-Jan-26 09:22 By: jhylton Comment: Guido, can you take a look at this. It's a real hassle. ------------------------------------------------------- Date: 2001-Jan-24 00:44 By: tim_one Comment: Not a problem on Windows, so changed group to Platform-specific. Assigned to Guido at random. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129904&group_id=5470 From noreply@sourceforge.net Fri Jan 26 17:28:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 09:28:34 -0800 Subject: [Python-bugs-list] [Bug #129904] 2.1a1: lib-tk not in sys.path: import fails Message-ID: Bug #129904, was updated on 2001-Jan-23 22:22 Here is a current snapshot of the bug. Project: Python Category: Tkinter Status: Open Resolution: None Bug Group: Platform-specific Priority: 7 Submitted by: sdm7g Assigned to : jhylton Summary: 2.1a1: lib-tk not in sys.path: import fails Details: "import Tkinter" fails on the new 2.1a1 build. The new setup.py script correctly finds the libraries and builds it automatically, but lib-tk is no longer put into sys.path as it was in 2.0. -- Steve M. Follow-Ups: Date: 2001-Jan-26 09:28 By: gvanrossum Comment: Jeremy, alas, I have no time to look into this today. Maybe Neil or Andrew knows what to do? If a fix for the 2.1a1 distribution is conceived, I'll gladly add it to the 2.1 home page. ------------------------------------------------------- Date: 2001-Jan-26 09:22 By: jhylton Comment: Guido, can you take a look at this. It's a real hassle. ------------------------------------------------------- Date: 2001-Jan-24 00:44 By: tim_one Comment: Not a problem on Windows, so changed group to Platform-specific. Assigned to Guido at random. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129904&group_id=5470 From noreply@sourceforge.net Fri Jan 26 17:58:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 09:58:26 -0800 Subject: [Python-bugs-list] [Bug #129827] Mac OSX build of 2.1a needs "-traditional-cpp" Message-ID: Bug #129827, was updated on 2001-Jan-23 09:34 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: sdm7g Assigned to : nobody Summary: Mac OSX build of 2.1a needs "-traditional-cpp" Details: build of 2.1a1 fails on Mac OSX: compiling classobject.c generates a syntax error cc needs "-traditional-cpp" flag (This probably should have been in before, but changes to classobject uncovered the bug. ) -- Steve Follow-Ups: Date: 2001-Jan-26 09:58 By: fdrake Comment: It might be nice to know more about the specific error generated; what in classobject.c is causing a problem? ------------------------------------------------------- Date: 2001-Jan-23 22:05 By: dkwolfe Comment: Note: This is only true for Public Beta. Post public beta builds do not need this flag. (the bug in the pre-processor has been fixed.) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129827&group_id=5470 From noreply@sourceforge.net Fri Jan 26 18:05:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 10:05:12 -0800 Subject: [Python-bugs-list] [Bug #129994] problem building readline extension on linux Message-ID: Bug #129994, was updated on 2001-Jan-24 16:40 Here is a current snapshot of the bug. Project: Python Category: Extension Modules Status: Closed Resolution: Fixed Bug Group: Platform-specific Priority: 5 Submitted by: bcollar Assigned to : lemburg Summary: problem building readline extension on linux Details: Howdy Using debian stable, 2.2.18pre1. Configure ran fine, python built okay, but the readline extension failed to build with this error: building 'readline' extension gcc -g -O2 -Wall -Wstrict-prototypes -fPIC -fpic -I. -I/tmp/Python-2.1a1/./Include -IInclude/ -I/usr/local/include -c /tmp/Python-2.1a1/Modules/readline.c -o build/temp.linux-i586-2.1/readline.o gcc -shared build/temp.linux-i586-2.1/readline.o -L/usr/local/lib -lreadline -ltermcap -o build/lib.linux-i586-2.1/readline.so /usr/bin/ld: cannot find -ltermcap collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 make: *** [sharedmods] Error 1 Follow-Ups: Date: 2001-Jan-26 10:05 By: lemburg Comment: Fixed in CVS. Please verify the fix on your platform. ------------------------------------------------------- Date: 2001-Jan-26 07:30 By: fdrake Comment: Assigned to Marc-Andre since he's already working on this one. I think this is a duplicate as well. ------------------------------------------------------- Date: 2001-Jan-24 16:51 By: bcollar Comment: I just looked at the setup.py script, and this line I'm figuring is the problem: if (self.compiler.find_library_file(lib_dirs, 'readline')): exts.append( Extension('readline', ['readline.c'], libraries=['readline', 'termcap']) ) since libraries includes termcap, the the find_library_file should also look for termcap, no? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129994&group_id=5470 From noreply@sourceforge.net Fri Jan 26 18:28:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 10:28:21 -0800 Subject: [Python-bugs-list] [Bug #129718] file locking lossage Message-ID: Bug #129718, was updated on 2001-Jan-22 12:43 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : bwarsaw Summary: file locking lossage Details: (reference: http://www.erlenstar.demon.co.uk/unix/faq_3.html#SEC35) there are 4 ways to lock a file in unix. fcntl, lockf, flock and dotlocking. the only portable ways are fcntl and dotfiles. dotlocking is more nfs-resistant. (actually the only reliable nfs-resistant way seems to be a combination. see eg. http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=43491) both fcntl and dotlock require magic incantations to implement. therefore it is desireable to include code to do this in the standard python library. there is only one module in the python distribution that implements dot-locking or fcntl() locking: the posixfile module. however, it is marked as obsolete(!) because someone misguidedly thinked the sysv lockf is more portable. this leads to a situation where the most sensible low-effort way to implement file locking is to either cut-n-paste code from the posixfile module, or to call an external program (such as lockfile(1) from the procmail package) to do it. -- Erno Kuusela erno@iki.fi Follow-Ups: Date: 2001-Jan-26 10:28 By: fdrake Comment: Assigned to Barry, since he deals with file locking the most these days. ------------------------------------------------------- Date: 2001-Jan-22 13:25 By: nobody Comment: (i apologise for the irritated tone of the above report.) it apperas the approach used in posixfile is not so bullet-proof either. in addition of the layout of the flock struct being platform-dependent, it is also (at least on linux) dependent also of the compilation mode used. if python is compiled with a 64-bit file offsets, the start and len members can grow in size. so this would either need to be done in c code or the code should test for the file offset size (i don't know if it's possible to find this out in python code). -- erno ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129718&group_id=5470 From noreply@sourceforge.net Fri Jan 26 18:26:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 10:26:37 -0800 Subject: [Python-bugs-list] [Bug #129683] test___all__ expects all referenced modules to exist Message-ID: Bug #129683, was updated on 2001-Jan-22 07:40 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: jackjansen Assigned to : montanaro Summary: test___all__ expects all referenced modules to exist Details: Test___all__ expects that all the modules it knows about exist and are importable. This isn't always true: if bsddb isn't available on the platform then dbhash can't be imported. Follow-Ups: Date: 2001-Jan-26 10:26 By: fdrake Comment: Skip, I think you fixed this. Please confirm and update this report. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129683&group_id=5470 From noreply@sourceforge.net Fri Jan 26 19:11:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 11:11:59 -0800 Subject: [Python-bugs-list] [Bug #130197] --with-suffix removal breaks macosx build Message-ID: Bug #130197, was updated on 2001-Jan-26 11:11 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: sdm7g Assigned to : nobody Summary: --with-suffix removal breaks macosx build Details: Something between the 2.1a1 release (where it worked) and the current cvs tree broke the --with-suffix configuration build on macosx. It used to cd to Modules, build python and then mv Modules/python to python$(EXE) in the parent directory. Now: It looks like --with-suffix support has been taken out of configure and the build of: c++ [...] -o python Modules/python.o libpython2.1.a fails, as there is already a directory named "Python". -- Steve Majewski For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130197&group_id=5470 From noreply@sourceforge.net Fri Jan 26 19:43:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 11:43:15 -0800 Subject: [Python-bugs-list] [Bug #129827] Mac OSX build of 2.1a needs "-traditional-cpp" Message-ID: Bug #129827, was updated on 2001-Jan-23 09:34 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: sdm7g Assigned to : nobody Summary: Mac OSX build of 2.1a needs "-traditional-cpp" Details: build of 2.1a1 fails on Mac OSX: compiling classobject.c generates a syntax error cc needs "-traditional-cpp" flag (This probably should have been in before, but changes to classobject uncovered the bug. ) -- Steve Follow-Ups: Date: 2001-Jan-26 11:43 By: sdm7g Comment: Fred, FYI, the specific error message is: cc -c -g -O2 -Wall -Wstrict-prototypes -fPIC -I. -I./Include -DHAVE_CONFIG_H -o Objects/classobject.o Objects/classobject.c Objects/classobject.c:1415: illegal expression, found `->' Objects/classobject.c:1415: illegal expression, found `)' Objects/classobject.c:1415: illegal expression, found `)' make: *** [Objects/classobject.o] Error 1 FYI**2, gcc on macosx supports precompiling headers files and the docs state: -traditional-cpp Controls which preprocessor is used. The default is cpp_precomp ; if you specify this flag, the standard GNU cpp will be used instead. I think it's a bug in the precompiler cpp that produces the errors. Since Dan and his pals at apple are the only ones to have Post public beta builds, and if they change the default, it won't matter if it's in there explicitly (I don't know what the default for public dist. Darwin is) it won't hurt to add it. (But if it's a pain, then after Mar 24, non-apple folks will be able to get the version on which it doesn't matter! ) ------------------------------------------------------- Date: 2001-Jan-26 09:58 By: fdrake Comment: It might be nice to know more about the specific error generated; what in classobject.c is causing a problem? ------------------------------------------------------- Date: 2001-Jan-23 22:05 By: dkwolfe Comment: Note: This is only true for Public Beta. Post public beta builds do not need this flag. (the bug in the pre-processor has been fixed.) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129827&group_id=5470 From noreply@sourceforge.net Fri Jan 26 19:58:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 11:58:22 -0800 Subject: [Python-bugs-list] [Bug #129683] test___all__ expects all referenced modules to exist Message-ID: Bug #129683, was updated on 2001-Jan-22 07:40 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: jackjansen Assigned to : montanaro Summary: test___all__ expects all referenced modules to exist Details: Test___all__ expects that all the modules it knows about exist and are importable. This isn't always true: if bsddb isn't available on the platform then dbhash can't be imported. Follow-Ups: Date: 2001-Jan-26 11:58 By: montanaro Comment: I agree with Jack (Guido may have also brought it up). I just noticed that this bug had been filed. I believe the latest version in CVS fixes this problem, so I'm simply closing it. Skip ------------------------------------------------------- Date: 2001-Jan-26 10:26 By: fdrake Comment: Skip, I think you fixed this. Please confirm and update this report. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129683&group_id=5470 From noreply@sourceforge.net Sat Jan 27 04:09:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 20:09:40 -0800 Subject: [Python-bugs-list] [Bug #130242] PyMember_Set of T_CHAR always raises exception Message-ID: Bug #130242, was updated on 2001-Jan-26 20:09 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: davecole Assigned to : nobody Summary: PyMember_Set of T_CHAR always raises exception Details: Copied from patch 103453 (which I just submitted): There is a missing break at the end of the T_CHAR case in PyMember_Set, so the program fall through to the error case even when the member set is successful. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130242&group_id=5470 From noreply@sourceforge.net Sat Jan 27 05:59:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 21:59:27 -0800 Subject: [Python-bugs-list] [Bug #129827] Mac OSX build of 2.1a needs "-traditional-cpp" Message-ID: Bug #129827, was updated on 2001-Jan-23 09:34 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: sdm7g Assigned to : nobody Summary: Mac OSX build of 2.1a needs "-traditional-cpp" Details: build of 2.1a1 fails on Mac OSX: compiling classobject.c generates a syntax error cc needs "-traditional-cpp" flag (This probably should have been in before, but changes to classobject uncovered the bug. ) -- Steve Follow-Ups: Date: 2001-Jan-26 21:59 By: fdrake Comment: Try changing the first line of the expansion of the Py_DECREF macro to this: if (--_Py_RefTotal, (--((op)->ob_refcnt) != 0)) \ (note the additional sets of paretheses around the second half of the test expression) I'm not sure this will help, but if it does, that would be nice. ------------------------------------------------------- Date: 2001-Jan-26 11:43 By: sdm7g Comment: Fred, FYI, the specific error message is: cc -c -g -O2 -Wall -Wstrict-prototypes -fPIC -I. -I./Include -DHAVE_CONFIG_H -o Objects/classobject.o Objects/classobject.c Objects/classobject.c:1415: illegal expression, found `->' Objects/classobject.c:1415: illegal expression, found `)' Objects/classobject.c:1415: illegal expression, found `)' make: *** [Objects/classobject.o] Error 1 FYI**2, gcc on macosx supports precompiling headers files and the docs state: -traditional-cpp Controls which preprocessor is used. The default is cpp_precomp ; if you specify this flag, the standard GNU cpp will be used instead. I think it's a bug in the precompiler cpp that produces the errors. Since Dan and his pals at apple are the only ones to have Post public beta builds, and if they change the default, it won't matter if it's in there explicitly (I don't know what the default for public dist. Darwin is) it won't hurt to add it. (But if it's a pain, then after Mar 24, non-apple folks will be able to get the version on which it doesn't matter! ) ------------------------------------------------------- Date: 2001-Jan-26 09:58 By: fdrake Comment: It might be nice to know more about the specific error generated; what in classobject.c is causing a problem? ------------------------------------------------------- Date: 2001-Jan-23 22:05 By: dkwolfe Comment: Note: This is only true for Public Beta. Post public beta builds do not need this flag. (the bug in the pre-processor has been fixed.) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129827&group_id=5470 From noreply@sourceforge.net Sat Jan 27 06:12:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 22:12:55 -0800 Subject: [Python-bugs-list] [Bug #130242] PyMember_Set of T_CHAR always raises exception Message-ID: Bug #130242, was updated on 2001-Jan-26 20:09 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: davecole Assigned to : tim_one Summary: PyMember_Set of T_CHAR always raises exception Details: Copied from patch 103453 (which I just submitted): There is a missing break at the end of the T_CHAR case in PyMember_Set, so the program fall through to the error case even when the member set is successful. Follow-Ups: Date: 2001-Jan-26 22:12 By: tim_one Comment: Assigned to me. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130242&group_id=5470 From noreply@sourceforge.net Sat Jan 27 06:01:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 22:01:31 -0800 Subject: [Python-bugs-list] [Bug #130197] --with-suffix removal breaks macosx build Message-ID: Bug #130197, was updated on 2001-Jan-26 11:11 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: sdm7g Assigned to : nascheme Summary: --with-suffix removal breaks macosx build Details: Something between the 2.1a1 release (where it worked) and the current cvs tree broke the --with-suffix configuration build on macosx. It used to cd to Modules, build python and then mv Modules/python to python$(EXE) in the parent directory. Now: It looks like --with-suffix support has been taken out of configure and the build of: c++ [...] -o python Modules/python.o libpython2.1.a fails, as there is already a directory named "Python". -- Steve Majewski Follow-Ups: Date: 2001-Jan-26 22:01 By: fdrake Comment: Assigned to Neil since he's in charge of the new Makefile. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130197&group_id=5470 From noreply@sourceforge.net Sat Jan 27 06:22:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 22:22:43 -0800 Subject: [Python-bugs-list] [Bug #130242] PyMember_Set of T_CHAR always raises exception Message-ID: Bug #130242, was updated on 2001-Jan-26 20:09 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: davecole Assigned to : tim_one Summary: PyMember_Set of T_CHAR always raises exception Details: Copied from patch 103453 (which I just submitted): There is a missing break at the end of the T_CHAR case in PyMember_Set, so the program fall through to the error case even when the member set is successful. Follow-Ups: Date: 2001-Jan-26 22:22 By: tim_one Comment: Fixed and Closed, structmember.c rev 2.19, ACKS rev 1.75. Checkin comment: SF bug http://sourceforge.net/bugs/?func=detailbug&bug_id=130242&group_id=5470 SF patch http://sourceforge.net/patch/?func=detailpatch&patch_id=103453&group_id=5470 PyMember_Set of T_CHAR always raises exception. Unfortunately, this is a use of a C API function that Python itself never makes, so there's no .py test I can check in to verify this stays fixed. But the fault in the code is obvious, and Dave Cole's patch just as obviously fixes it. ------------------------------------------------------- Date: 2001-Jan-26 22:12 By: tim_one Comment: Assigned to me. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130242&group_id=5470 From noreply@sourceforge.net Sat Jan 27 07:21:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 23:21:25 -0800 Subject: [Python-bugs-list] [Bug #129904] 2.1a1: lib-tk not in sys.path: import fails Message-ID: Bug #129904, was updated on 2001-Jan-23 22:22 Here is a current snapshot of the bug. Project: Python Category: Tkinter Status: Open Resolution: Fixed Bug Group: Platform-specific Priority: 7 Submitted by: sdm7g Assigned to : akuchling Summary: 2.1a1: lib-tk not in sys.path: import fails Details: "import Tkinter" fails on the new 2.1a1 build. The new setup.py script correctly finds the libraries and builds it automatically, but lib-tk is no longer put into sys.path as it was in 2.0. -- Steve M. Follow-Ups: Date: 2001-Jan-26 23:21 By: nascheme Comment: I believe Andrew fixed this. Assigning it to him to close. ------------------------------------------------------- Date: 2001-Jan-26 09:28 By: gvanrossum Comment: Jeremy, alas, I have no time to look into this today. Maybe Neil or Andrew knows what to do? If a fix for the 2.1a1 distribution is conceived, I'll gladly add it to the 2.1 home page. ------------------------------------------------------- Date: 2001-Jan-26 09:22 By: jhylton Comment: Guido, can you take a look at this. It's a real hassle. ------------------------------------------------------- Date: 2001-Jan-24 00:44 By: tim_one Comment: Not a problem on Windows, so changed group to Platform-specific. Assigned to Guido at random. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129904&group_id=5470 From noreply@sourceforge.net Sat Jan 27 07:15:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 23:15:01 -0800 Subject: [Python-bugs-list] [Bug #130197] --with-suffix removal breaks macosx build Message-ID: Bug #130197, was updated on 2001-Jan-26 11:11 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: Fixed Bug Group: None Priority: 5 Submitted by: sdm7g Assigned to : nobody Summary: --with-suffix removal breaks macosx build Details: Something between the 2.1a1 release (where it worked) and the current cvs tree broke the --with-suffix configuration build on macosx. It used to cd to Modules, build python and then mv Modules/python to python$(EXE) in the parent directory. Now: It looks like --with-suffix support has been taken out of configure and the build of: c++ [...] -o python Modules/python.o libpython2.1.a fails, as there is already a directory named "Python". -- Steve Majewski Follow-Ups: Date: 2001-Jan-26 23:15 By: nascheme Comment: The --with-suffix option has been restored. ------------------------------------------------------- Date: 2001-Jan-26 22:01 By: fdrake Comment: Assigned to Neil since he's in charge of the new Makefile. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130197&group_id=5470 From noreply@sourceforge.net Sat Jan 27 07:15:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jan 2001 23:15:55 -0800 Subject: [Python-bugs-list] [Bug #130197] --with-suffix removal breaks macosx build Message-ID: Bug #130197, was updated on 2001-Jan-26 11:11 Here is a current snapshot of the bug. Project: Python Category: Build Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: sdm7g Assigned to : nobody Summary: --with-suffix removal breaks macosx build Details: Something between the 2.1a1 release (where it worked) and the current cvs tree broke the --with-suffix configuration build on macosx. It used to cd to Modules, build python and then mv Modules/python to python$(EXE) in the parent directory. Now: It looks like --with-suffix support has been taken out of configure and the build of: c++ [...] -o python Modules/python.o libpython2.1.a fails, as there is already a directory named "Python". -- Steve Majewski Follow-Ups: Date: 2001-Jan-26 23:15 By: nascheme Comment: Oops, close the bug. ------------------------------------------------------- Date: 2001-Jan-26 23:15 By: nascheme Comment: The --with-suffix option has been restored. ------------------------------------------------------- Date: 2001-Jan-26 22:01 By: fdrake Comment: Assigned to Neil since he's in charge of the new Makefile. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130197&group_id=5470 From noreply@sourceforge.net Sat Jan 27 14:18:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 27 Jan 2001 06:18:06 -0800 Subject: [Python-bugs-list] [Bug #129904] 2.1a1: lib-tk not in sys.path: import fails Message-ID: Bug #129904, was updated on 2001-Jan-23 22:22 Here is a current snapshot of the bug. Project: Python Category: Tkinter Status: Open Resolution: Fixed Bug Group: Platform-specific Priority: 7 Submitted by: sdm7g Assigned to : akuchling Summary: 2.1a1: lib-tk not in sys.path: import fails Details: "import Tkinter" fails on the new 2.1a1 build. The new setup.py script correctly finds the libraries and builds it automatically, but lib-tk is no longer put into sys.path as it was in 2.0. -- Steve M. Follow-Ups: Date: 2001-Jan-27 06:18 By: akuchling Comment: Fixed. ------------------------------------------------------- Date: 2001-Jan-26 23:21 By: nascheme Comment: I believe Andrew fixed this. Assigning it to him to close. ------------------------------------------------------- Date: 2001-Jan-26 09:28 By: gvanrossum Comment: Jeremy, alas, I have no time to look into this today. Maybe Neil or Andrew knows what to do? If a fix for the 2.1a1 distribution is conceived, I'll gladly add it to the 2.1 home page. ------------------------------------------------------- Date: 2001-Jan-26 09:22 By: jhylton Comment: Guido, can you take a look at this. It's a real hassle. ------------------------------------------------------- Date: 2001-Jan-24 00:44 By: tim_one Comment: Not a problem on Windows, so changed group to Platform-specific. Assigned to Guido at random. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129904&group_id=5470 From noreply@sourceforge.net Sat Jan 27 14:32:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 27 Jan 2001 06:32:10 -0800 Subject: [Python-bugs-list] [Bug #129904] 2.1a1: lib-tk not in sys.path: import fails Message-ID: Bug #129904, was updated on 2001-Jan-23 22:22 Here is a current snapshot of the bug. Project: Python Category: Tkinter Status: Closed Resolution: Fixed Bug Group: Platform-specific Priority: 7 Submitted by: sdm7g Assigned to : akuchling Summary: 2.1a1: lib-tk not in sys.path: import fails Details: "import Tkinter" fails on the new 2.1a1 build. The new setup.py script correctly finds the libraries and builds it automatically, but lib-tk is no longer put into sys.path as it was in 2.0. -- Steve M. Follow-Ups: Date: 2001-Jan-27 06:18 By: akuchling Comment: Fixed. ------------------------------------------------------- Date: 2001-Jan-26 23:21 By: nascheme Comment: I believe Andrew fixed this. Assigning it to him to close. ------------------------------------------------------- Date: 2001-Jan-26 09:28 By: gvanrossum Comment: Jeremy, alas, I have no time to look into this today. Maybe Neil or Andrew knows what to do? If a fix for the 2.1a1 distribution is conceived, I'll gladly add it to the 2.1 home page. ------------------------------------------------------- Date: 2001-Jan-26 09:22 By: jhylton Comment: Guido, can you take a look at this. It's a real hassle. ------------------------------------------------------- Date: 2001-Jan-24 00:44 By: tim_one Comment: Not a problem on Windows, so changed group to Platform-specific. Assigned to Guido at random. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129904&group_id=5470 From noreply@sourceforge.net Sun Jan 28 02:13:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 27 Jan 2001 18:13:24 -0800 Subject: [Python-bugs-list] [Bug #130306] statcache.py full of thread problems Message-ID: Bug #130306, was updated on 2001-Jan-27 18:13 Here is a current snapshot of the bug. Project: Python Category: Threads Status: Open Resolution: None Bug Group: None Priority: 6 Submitted by: tim_one Assigned to : tim_one Summary: statcache.py full of thread problems Details: From c.l.py (I'll skip including my reply): From: Randall Kern mailto:randy@spoke.net Sent: Saturday, January 27, 2001 7:20 PM Subject: threading issues with statcache Looking at the code for the statcache module from py 1.5.2, it looks like it isn't thread safe. While writing my own substitute, I realized I am unclear on when names are looked up. In particular, given two function like these (copied from statcache): cache = {} def stat(path): if cache.has_key(path): return cache[path] cache[path] = ret = os.stat(path) return ret def reset(): global cache cache = {} If the symbol 'cache' is looked up _once_ per function, then these two functions may be used across multiple threads. If it is looked up for every reference, than it would be possible to call reset() between a TRUE has_key() and the return in stat(), which would result in a KeyError. When are global variable's bound? Thanks, -Randy P.S. I realize that stat() might update the cache more than once for the same path, if it was called from multiple threads. But that's consistent with it's expected behavior, so not really a MT problem. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130306&group_id=5470 From noreply@sourceforge.net Sun Jan 28 05:08:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 27 Jan 2001 21:08:12 -0800 Subject: [Python-bugs-list] [Bug #130306] statcache.py full of thread problems Message-ID: Bug #130306, was updated on 2001-Jan-27 18:13 Here is a current snapshot of the bug. Project: Python Category: Threads Status: Closed Resolution: Fixed Bug Group: None Priority: 6 Submitted by: tim_one Assigned to : tim_one Summary: statcache.py full of thread problems Details: From c.l.py (I'll skip including my reply): From: Randall Kern mailto:randy@spoke.net Sent: Saturday, January 27, 2001 7:20 PM Subject: threading issues with statcache Looking at the code for the statcache module from py 1.5.2, it looks like it isn't thread safe. While writing my own substitute, I realized I am unclear on when names are looked up. In particular, given two function like these (copied from statcache): cache = {} def stat(path): if cache.has_key(path): return cache[path] cache[path] = ret = os.stat(path) return ret def reset(): global cache cache = {} If the symbol 'cache' is looked up _once_ per function, then these two functions may be used across multiple threads. If it is looked up for every reference, than it would be possible to call reset() between a TRUE has_key() and the return in stat(), which would result in a KeyError. When are global variable's bound? Thanks, -Randy P.S. I realize that stat() might update the cache more than once for the same path, if it was called from multiple threads. But that's consistent with it's expected behavior, so not really a MT problem. Follow-Ups: Date: 2001-Jan-27 21:08 By: tim_one Comment: Fixed and Closed, statcache.py rev 1.10, ACKS rev 1.76. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130306&group_id=5470 From noreply@sourceforge.net Sun Jan 28 12:16:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 28 Jan 2001 04:16:33 -0800 Subject: [Python-bugs-list] [Bug #130010] Nasty case for comparison performance Message-ID: Bug #130010, was updated on 2001-Jan-24 21:14 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: None Priority: 1 Submitted by: tim_one Assigned to : gvanrossum Summary: Nasty case for comparison performance Details: Test case: def timeeq(x, y): from time import clock import sys assert len(x) == len(y) print "comparing dicts of len", len(x), "...", sys.stdout.flush() s = clock() result = x == y f = clock() print round(f-s, 1), "seconds" sys.stdout.flush() d = {} e = {} timeeq(d, e) d[0] = d e[0] = e timeeq(d, e) d[1] = d e[1] = e timeeq(d, e) d[2] = d e[2] = e timeeq(d, e) Under current CVS, output is: comparing dicts of len 0 ... 0.0 seconds comparing dicts of len 1 ... 0.0 seconds comparing dicts of len 2 ... 6.5 seconds comparing dicts of len 3 ... There's no sign that the 3-element dict compare will ever terminate (killed it after 15 minutes on a quiet machine). This is actually a huge improvement over Python 2.0, though! There it spins (seemingly) forever comparing the 2-element dicts. Note that I put this at priority 1 (lowest). Follow-Ups: Date: 2001-Jan-28 04:16 By: nobody Comment: It is really good give me one send to leebinhao@hotmail.com ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130010&group_id=5470 From noreply@sourceforge.net Sun Jan 28 18:11:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 28 Jan 2001 10:11:33 -0800 Subject: [Python-bugs-list] [Bug #130117] Python-2.1a1 sgi build _curses Module fix Message-ID: Bug #130117, was updated on 2001-Jan-25 20:51 Here is a current snapshot of the bug. Project: Python Category: Build Status: Closed Resolution: Fixed Bug Group: Platform-specific Priority: 5 Submitted by: pj99 Assigned to : akuchling Summary: Python-2.1a1 sgi build _curses Module fix Details: The build of the _curses module on sgi (IRIX) fails, for want of an extern function declaration of tparm(). Without the following fix, the "setup.py build" fails on the _curses module with many complaints resembling: cc-1515 cc: ERROR File = /usr/people/pj/etc/python/Python-2.1a1/Python-2.1a1/Modules/_cursesmodule.c, Line = 2239 A value of type "int" cannot be assigned to an entity of type "char *". result = tparm(fmt); ^ With this fix, the compilation of _cursesmodule.c is clean. The patch is: *** _cursesmodule.c.orig Thu Jan 25 19:37:29 2001 --- _cursesmodule.c Thu Jan 25 20:39:10 2001 *************** *** 115,120 **** --- 115,121 ---- extern int setupterm(char *,int,int *); #ifdef sgi extern char *tigetstr(char *); + extern char *tparm(char *instring, ...); #endif #if defined(sgi) || defined(__sun__) Follow-Ups: Date: 2001-Jan-28 10:11 By: akuchling Comment: Checked into revision 2.48 of _cursesmodule.c; thanks! The safe way to submit patches is through the patch manager on SourceForge, though for a one-liner like this it doesn't much matter. ------------------------------------------------------- Date: 2001-Jan-25 20:59 By: pj99 Comment: No - still wrong (still loosing leading spaces on each line). I give up. If someone knows how to submit patches without munging the spacing. I'd be interested to learn. Sorry. ------------------------------------------------------- Date: 2001-Jan-25 20:57 By: pj99 Comment: Hmmm ... my original submission had some leading spaces removed. Lets try that patch one more time, to see if I can get it right. *** _cursesmodule.c.orig Thu Jan 25 19:37:29 2001 --- _cursesmodule.c Thu Jan 25 20:39:10 2001 *************** *** 115,120 **** --- 115,121 ---- extern int setupterm(char *,int,int *); #ifdef sgi extern char *tigetstr(char *); + extern char *tparm(char *instring, ...); #endif #if defined(sgi) || defined(__sun__) === Ok - the code lines above (in this little Netscape web editing window) each start in column two. Let's "Submit" and see if the end result shows that. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130117&group_id=5470 From noreply@sourceforge.net Sun Jan 28 22:22:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 28 Jan 2001 14:22:45 -0800 Subject: [Python-bugs-list] [Bug #130355] unicode capitalize method does the wrong thing Message-ID: Bug #130355, was updated on 2001-Jan-28 14:22 Here is a current snapshot of the bug. Project: Python Category: Unicode Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: mwh Assigned to : nobody Summary: unicode capitalize method does the wrong thing Details: We went around with this one on python-dev some time back; I stumbled accross the old mail and thought I'd add an entry here to make sure it doesn't get forgotten again. The problem: >>> u'AaAa'.capitalize() u'AaAa' >>> 'AaAa'.capitalize() 'Aaaa' Guido said the latter was correct. No time for a patch from me today :-( For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130355&group_id=5470 From noreply@sourceforge.net Sun Jan 28 23:31:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 28 Jan 2001 15:31:26 -0800 Subject: [Python-bugs-list] [Bug #130359] Run script should not appear in shell window Message-ID: Bug #130359, was updated on 2001-Jan-28 15:31 Here is a current snapshot of the bug. Project: Python Category: IDLE Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: loewis Assigned to : nobody Summary: Run script should not appear in shell window Details: When selecting "Run module" in the shell window, an error message "The buffer Python Shell is not saved..." is produced. Since running the shell window will fail in any case, these menu items should be removed from the shell window. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130359&group_id=5470 From noreply@sourceforge.net Mon Jan 29 02:42:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 28 Jan 2001 18:42:38 -0800 Subject: [Python-bugs-list] [Bug #121207] % operator on strings not documented Message-ID: Bug #121207, was updated on 2000-Nov-03 04:51 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: nobody Assigned to : fdrake Summary: % operator on strings not documented Details: Python string substitution with % is not documented -- the closest the doc gets is at which says the string is "interpreted as a C sprintf() format string", but doesn't say what that means or how the substitution is done. Follow-Ups: Date: 2001-Jan-28 18:42 By: fdrake Comment: Added documentation by Evelyn Mitchell in Doc/lib/libstdtypes.tex revision 1.51 (submitted as SF patch #103412). ------------------------------------------------------- Date: 2001-Jan-25 00:15 By: moshez Comment: 103412 patch is meant to solve this bug. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=121207&group_id=5470 From noreply@sourceforge.net Mon Jan 29 02:59:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 28 Jan 2001 18:59:39 -0800 Subject: [Python-bugs-list] [Bug #129788] cgi module. FieldStorage class returns keys blank fields. Message-ID: Bug #129788, was updated on 2001-Jan-23 01:28 Here is a current snapshot of the bug. Project: Python Category: Python Library Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : akuchling Summary: cgi module. FieldStorage class returns keys blank fields. Details: In module cgi.py The FieldStorage class returns keys for blank values even though the keep_blank_values property is set to 0 The problem lies in the parse_qsl method. The second last line of the function r.append((name, value)) should read if (len(value) or keep_blank_values): r.append((name, value)) I hope this can be corrected. Thanks Follow-Ups: Date: 2001-Jan-28 18:59 By: nobody Comment: I don't see why this is necessary. The r.append() call is inside an if block whose condition is 'if len(nv[1]) or keep_blank_values'. nv[1] then has + replaced with space characters and is run through urllib.unquote(). I'm unable to see how a non-empty string could result in an empty string after urllib.unquote, and in fact cgi.parse_qsl('abc=&foo=bar') returns [('foo', 'bar')]. Can you provide a test case? If a test case demonstrating the problem doesn't appear, this bug should be marked as 'Not a bug' and cgi.py left alone. ------------------------------------------------------- Date: 2001-Jan-26 07:29 By: fdrake Comment: Assigned to Andrew since he knows more about CGI stuff than I ever expect to. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129788&group_id=5470 From noreply@sourceforge.net Mon Jan 29 03:19:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 28 Jan 2001 19:19:13 -0800 Subject: [Python-bugs-list] [Bug #130165] Python 2.1a1 Makefile changed OPT value not used in module c Message-ID: Bug #130165, was updated on 2001-Jan-26 06:46 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : akuchling Summary: Python 2.1a1 Makefile changed OPT value not used in module c Details: When the top level "Makefile" value used for the variable "OPT" is changed after executing "configure", that new value is used to compile "python", but is *not* used during the compilation of the modules. Follow-Ups: Date: 2001-Jan-28 19:19 By: nobody Comment: I can't replicate this; when I edit the Makefile, the new OPT setting is picked up by the setup script. Does it still happen with the current CVS version? ------------------------------------------------------- Date: 2001-Jan-26 07:45 By: nascheme Comment: Hmm, perhaps the makefile could pass OPT to the distutils setup.py script. Andrew knows better than I how to solve this. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130165&group_id=5470 From noreply@sourceforge.net Mon Jan 29 10:35:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 02:35:33 -0800 Subject: [Python-bugs-list] [Bug #130355] unicode capitalize method does the wrong thing Message-ID: Bug #130355, was updated on 2001-Jan-28 14:22 Here is a current snapshot of the bug. Project: Python Category: Unicode Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: mwh Assigned to : lemburg Summary: unicode capitalize method does the wrong thing Details: We went around with this one on python-dev some time back; I stumbled accross the old mail and thought I'd add an entry here to make sure it doesn't get forgotten again. The problem: >>> u'AaAa'.capitalize() u'AaAa' >>> 'AaAa'.capitalize() 'Aaaa' Guido said the latter was correct. No time for a patch from me today :-( Follow-Ups: Date: 2001-Jan-29 02:35 By: lemburg Comment: I'll look into this. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130355&group_id=5470 From noreply@sourceforge.net Mon Jan 29 11:14:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 03:14:15 -0800 Subject: [Python-bugs-list] [Bug #130355] unicode capitalize method does the wrong thing Message-ID: Bug #130355, was updated on 2001-Jan-28 14:22 Here is a current snapshot of the bug. Project: Python Category: Unicode Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Submitted by: mwh Assigned to : lemburg Summary: unicode capitalize method does the wrong thing Details: We went around with this one on python-dev some time back; I stumbled accross the old mail and thought I'd add an entry here to make sure it doesn't get forgotten again. The problem: >>> u'AaAa'.capitalize() u'AaAa' >>> 'AaAa'.capitalize() 'Aaaa' Guido said the latter was correct. No time for a patch from me today :-( Follow-Ups: Date: 2001-Jan-29 03:14 By: lemburg Comment: Fixed in CVS. ------------------------------------------------------- Date: 2001-Jan-29 02:35 By: lemburg Comment: I'll look into this. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130355&group_id=5470 From noreply@sourceforge.net Tue Jan 30 00:01:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jan 2001 16:01:07 -0800 Subject: [Python-bugs-list] [Bug #129843] MacOSX case insensitivity bug resurfaces Message-ID: Bug #129843, was updated on 2001-Jan-23 11:38 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: nobody Assigned to : gvanrossum Summary: MacOSX case insensitivity bug resurfaces Details: The case insensitivity with HFS+ MacOSX bug has resurfaced with the 2.1a1 release. import FCNTL; import fcntl or import termios; import TERMIOS (and maybe others) will crash due to duplicate symbols as it tries to import the same shared libraries twice instead ot importing the .py file for one of them. This was handled in 2.0 by building those modules as built-in, not shared. ( I haven't yet figured out the new setup.py system. Maybe it should be fixed in import. ) -- Steve M. Follow-Ups: Date: 2001-Jan-29 16:01 By: sdm7g Comment: [Patch #103495] case sensitive import for case insensitive FileSystem I submitted a patch that fixes the problem. (#ifdefs around the code probably ought to be changed to also test __APPLE__ ) - Steve Majewski ------------------------------------------------------- Date: 2001-Jan-23 22:13 By: nobody Comment: There is also a clash between: lib/plat-Darwin1.2/SOCKET.py & lib/socket.py which can't be fixed by building one builtin. ( The .so is _socketmodule.so, so it doesn't clash. ) - sdm7g ------------------------------------------------------- Date: 2001-Jan-23 18:46 By: gvanrossum Comment: You can make them built-in by adding them to the Modules/Setup file -- that file still exists and works as before, it's just that most modules aren't listed there any more. See also the discussion at this patch: http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470 The long-term solution is to get rid of the FCNTL and TERMIOS modules and include the symbols in the extension -- as has been done for e.g. the socket module. (Some of the symbols of FCNTL are already exported by fcntl or os.) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129843&group_id=5470 From noreply@sourceforge.net Tue Jan 30 08:47:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 00:47:08 -0800 Subject: [Python-bugs-list] [Bug #130165] Python 2.1a1 Makefile changed OPT value not used in module c Message-ID: Bug #130165, was updated on 2001-Jan-26 06:46 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : akuchling Summary: Python 2.1a1 Makefile changed OPT value not used in module c Details: When the top level "Makefile" value used for the variable "OPT" is changed after executing "configure", that new value is used to compile "python", but is *not* used during the compilation of the modules. Follow-Ups: Date: 2001-Jan-30 00:47 By: nobody Comment: Updated more details by original submitter: The problem appears shortly after a "cd Modules" but shows up only during compilation of the ".so" extension modules. The first module compilation in the original 2.1a1 version to show the failure to use the changed value of "OPT" follows the line: "building 'regex' extension" ------------------------------------------------------- Date: 2001-Jan-28 19:19 By: nobody Comment: I can't replicate this; when I edit the Makefile, the new OPT setting is picked up by the setup script. Does it still happen with the current CVS version? ------------------------------------------------------- Date: 2001-Jan-26 07:45 By: nascheme Comment: Hmm, perhaps the makefile could pass OPT to the distutils setup.py script. Andrew knows better than I how to solve this. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130165&group_id=5470 From noreply@sourceforge.net Wed Jan 31 00:20:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 16:20:29 -0800 Subject: [Python-bugs-list] [Bug #130532] newest CVS won't build on AIX Message-ID: Bug #130532, was updated on 2001-Jan-30 16:20 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: bcollar Assigned to : nobody Summary: newest CVS won't build on AIX Details: AIX 4.2.1, CC=xlC, ./configure --prefix=/blah --without-gcc. make CC=xlC OPT="-O2 -qmaxmem=4000" dies: xlC -c -O2 -qmaxmem=4000 -I. -I./Include -DHAVE_CONFIG_H -o Python/ceval.o Python/ceval.c "Python/ceval.c", line 36.9: 1506-213 (S) Macro name REPR cannot be redefined. "Python/ceval.c", line 36.9: 1506-358 (I) "REPR" is defined on line 23 of Python/ceval.c. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130532&group_id=5470 From noreply@sourceforge.net Wed Jan 31 01:12:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 17:12:13 -0800 Subject: [Python-bugs-list] [Bug #130532] newest CVS won't build on AIX Message-ID: Bug #130532, was updated on 2001-Jan-30 16:20 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Open Resolution: None Bug Group: None Priority: 7 Submitted by: bcollar Assigned to : tim_one Summary: newest CVS won't build on AIX Details: AIX 4.2.1, CC=xlC, ./configure --prefix=/blah --without-gcc. make CC=xlC OPT="-O2 -qmaxmem=4000" dies: xlC -c -O2 -qmaxmem=4000 -I. -I./Include -DHAVE_CONFIG_H -o Python/ceval.o Python/ceval.c "Python/ceval.c", line 36.9: 1506-213 (S) Macro name REPR cannot be redefined. "Python/ceval.c", line 36.9: 1506-358 (I) "REPR" is defined on line 23 of Python/ceval.c. Follow-Ups: Date: 2001-Jan-30 17:12 By: tim_one Comment: Weird -- I'm surprised this didn't blow up everywhere! Assigned to me, boosted priority, took away platform-specific (the code isn't legal C, period), and changed the category to Core. In the meantime, just comment out either of the REPR #define's (they have the same effect, but aren't token-for-token identical). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130532&group_id=5470 From noreply@sourceforge.net Wed Jan 31 01:18:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 17:18:28 -0800 Subject: [Python-bugs-list] [Bug #130532] newest CVS won't build on AIX Message-ID: Bug #130532, was updated on 2001-Jan-30 16:20 Here is a current snapshot of the bug. Project: Python Category: Python Interpreter Core Status: Closed Resolution: Fixed Bug Group: None Priority: 7 Submitted by: bcollar Assigned to : tim_one Summary: newest CVS won't build on AIX Details: AIX 4.2.1, CC=xlC, ./configure --prefix=/blah --without-gcc. make CC=xlC OPT="-O2 -qmaxmem=4000" dies: xlC -c -O2 -qmaxmem=4000 -I. -I./Include -DHAVE_CONFIG_H -o Python/ceval.o Python/ceval.c "Python/ceval.c", line 36.9: 1506-213 (S) Macro name REPR cannot be redefined. "Python/ceval.c", line 36.9: 1506-358 (I) "REPR" is defined on line 23 of Python/ceval.c. Follow-Ups: Date: 2001-Jan-30 17:18 By: tim_one Comment: Fixed and Closed, ceval.c rev 2.225. ------------------------------------------------------- Date: 2001-Jan-30 17:12 By: tim_one Comment: Weird -- I'm surprised this didn't blow up everywhere! Assigned to me, boosted priority, took away platform-specific (the code isn't legal C, period), and changed the category to Core. In the meantime, just comment out either of the REPR #define's (they have the same effect, but aren't token-for-token identical). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130532&group_id=5470 From noreply@sourceforge.net Wed Jan 31 04:53:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 20:53:45 -0800 Subject: [Python-bugs-list] [Bug #129584] pythonpath registry value ignored in 2.0 Message-ID: Bug #129584, was updated on 2001-Jan-21 04:48 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: Works For Me Bug Group: Platform-specific Priority: 5 Submitted by: esasaki Assigned to : mhammond Summary: pythonpath registry value ignored in 2.0 Details: The value of the HKLM\software\python\pythoncore\2.0\pythonpath key is now ignored in Python 2.0 unless you have at least one subkey underneath it. Since the default installation program doesn't add any subkeys, users familiar with 1.5.2 who expect to just set pythonpath in the registry will be disappointed. I imagine that you all probably run with other extensions installed that add subkeys under pythonpath and thus never see this bug. However, the first thing I did after installing 2.0 was to try to point to my custom libs. 5 hours later I can finally start testing to see if they still work :). This problem is undoubtedly related to bug 127722. Fix that and you'll fix this one. Follow-Ups: Date: 2001-Jan-30 20:53 By: mhammond Comment: I can not reproduce this. I believe the "problem" is that since Python 1.6, Python's registry search mechanism has changed. If Python can locate its own "home" (which it usually can, given a vanilla install) then it _ignores_ the main registry key, and _only_ looks in subkeys. The rationalle is that this will allow you to have multiple installations of the same Python version (eg, the "official" release and the current CVS version). This will ensure the "core" path is always correct. To test this, copy "python.exe" to a temp directory, and run it from there. In this case Python will not be able to locate its home, and will use the registry key. I am leaving this bug open to remind me to add documentation on the registry somewhere appropriate. However, I am marking as "works for me". ------------------------------------------------------- Date: 2001-Jan-21 10:41 By: tim_one Comment: Mark? You know more about this than everyone else combined. Is that good news or bad ? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129584&group_id=5470 From noreply@sourceforge.net Wed Jan 31 05:01:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 21:01:08 -0800 Subject: [Python-bugs-list] [Bug #127722] getpythonregpath fails Message-ID: Bug #127722, was updated on 2001-Jan-05 21:16 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Closed Resolution: Works For Me Bug Group: Platform-specific Priority: 5 Submitted by: effbiae Assigned to : mhammond Summary: getpythonregpath fails Details: Hi, I'm on Win95 (regrettably). I found that while experimenting with embedding Python in C, I initialized the interpreter, and got the message: 'import site' failed; use -v for traceback If I putenv("PYTHONHOME=C:\python20"), this disappears. Also, if I put the executable in C:\python20, the problem disappears. Please excuse any stupidity that follows as I am a newby to the windows registy. in the file: Pc\getpathp.c in the function: static char * getpythonregpath(HKEY keyBase, int skipcore) in the call: rc = RegQueryInfoKey(newKey, NULL, NULL, NULL, &numKeys, NULL, NULL, NULL, NULL, &dataSize, NULL, NULL); numKeys is being set to 0 because in my installation of Python 2.0, the registry key: HKEY_LOCAL_MACHINE\\Software\\Python\\PythonCore\\PythonPath\ has no subkeys. It has the 'default' (?) value: C:\Python20\Lib\plat-win;C:\Python20\Lib;C:\Python20\DLLs;C:\Python20\Lib\lib-tk (I do not have HKEY_CURRENT_USER\\Software\\Python\\PythonCore\\PythonPath -- in fact I do not have HKEY_CURRENT_USER\\Software\\Python) Anyway, it looks like the code assumes 'numKeys > 0', which is not the case at my run-time. It appears that the the registry editing part of the installation program may have changed recently, and this file has not been updated accordingly. Also, the doco for the Python/C API says that the PATH environment variable may be examined to locate the python executable, but it appears that in the Win version of Python2.0, PATH is ignored. Is there a reason why PATH is not examined in the Win version? Follow-Ups: Date: 2001-Jan-30 21:01 By: mhammond Comment: This is "by design" - see my comments at https://sourceforge.net/bugs/?func=detailbug&group_id=5470&bug_id=129584 Note that there is no default that uses absolute paths (ie, the "C:\..." you referenced). This is the Python code determining its own core, and thereby ignoring the registry key for the core (sub-keys are still used) I believe the code you reference is fine, and working as designed (but that may not be how you like ). My testing shows the code working in an identical fashion regardless of the number of subkeys. Also, setting PYTHONHOME is working as designed - this env var tells Python to not search for its home, and to not use the registry key, but assume the directory specified is valid, and build its core path from that. Marking as "works for me" and closing. ------------------------------------------------------- Date: 2001-Jan-09 17:13 By: mhammond Comment: Happy to look at this, but it will probably need to wait until I return to Oz - early Feb. ------------------------------------------------------- Date: 2001-Jan-07 21:37 By: tim_one Comment: Assigned to MarkH cuz he might actually think he knows what the code is doing Bug #125891, was updated on 2000-Dec-15 05:53 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Closed Resolution: Fixed Bug Group: Platform-specific Priority: 5 Submitted by: aisaksen Assigned to : mhammond Summary: windows popen4 crashes python when not closed correctly Details: If you don't close both the istream file and ostream file return values after calling popen4, then it crashes in somewhere in MSVCRT.DLL Try the code included in this file. If you call Crash(), then python will crash after about 500 times through the loop. NoCrash() works ok, because you close both of the results. This bug happens on both the www.python.org release, as well as the ActivePython build. I'm running Windows 2000, with Visual Studio 6.0 installed. This seems to be a Windows bug. It dies in a call to setvbuf. Recompiling with the HAS_SETVBUF undefined still causes the same crash. It would be nice if python prevented this from happening. Ideally, you should be able to close the pipes, because there is no longer a reference to them. -Aaron Isaksen -- begin code -- import os def Crash(): n = 0 while 1: p = os.popen4('dir') p[0].close() n +=1 print n def NoCrash(): n = 0 while 1: p = os.popen4('dir') p[0].close() p[1].close() n +=1 print n -- end code -- Follow-Ups: Date: 2001-Jan-30 21:39 By: mhammond Comment: Fixed in Rev 2.182 of Modules/posixmodule.c ------------------------------------------------------- Date: 2001-Jan-19 09:44 By: mhammond Comment: I can repro this. It appears Python _never_ closes the file handles (the Win2k task manager shows the handle count for the process growing at a great rate). It happens for all popen calls. Although Python doesnt guarantee closing, the current implementation should not allow this to happen. I will look into this! ------------------------------------------------------- Date: 2001-Jan-19 00:11 By: tim_one Comment: Mark, got a clue? This is too painful for me: the NoCrash() case on my Win98SE box takes a full second for each popen4 call, while the Crash() case tries to pop up an infinite sequence of conagent.exe error boxes after just a few dozen (but much quicker ) calls; at that point the system gets too low on low-level resource to even open the Ctrl+Alt+Del box, and a reboot is the only way out. aisaksen, hate to say it, but I don't believe the popen family of functions will ever be robust under Windows; popen isn't a native Windows concept (it came from Unix), and MS's base support for it is simply hosed. Note that while Python may grow code to automagically close stuff when the object goes away, Python makes no guarantees about when (or even if) object destructors are called. So you should never rely on Python closing things for you. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=125891&group_id=5470 From noreply@sourceforge.net Wed Jan 31 07:32:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 23:32:31 -0800 Subject: [Python-bugs-list] [Bug #128685] popen on Win9x isnt smart enough about finding w9xpopen.exe Message-ID: Bug #128685, was updated on 2001-Jan-13 11:38 Here is a current snapshot of the bug. Project: Python Category: Extension Modules Status: Open Resolution: Remind Bug Group: Platform-specific Priority: 5 Submitted by: mhammond Assigned to : mhammond Summary: popen on Win9x isnt smart enough about finding w9xpopen.exe Details: The code in posixmodule that emulates popen*() isnt very smart about locating the .exe for the Win9x popen hacks. It assumes that w9xpopen.exe can be located in the directory of the main executable, which fails in may embedding situations. A reasonable fix would be to also attempt to locate the file in the "sys.prefix" directory - typically this will be set correctly. Im not at my main dev machine, hence I am submitting a bug rather than a patch. I will submit a patch ASAP. Follow-Ups: Date: 2001-Jan-30 23:32 By: mhammond Comment: Partial fix checked in Rev 2.183 of Modules/posixmodule.c As per the comments in that checkin, the code now tries sys.prefix, but in many embedded situations this is still NULL/empty. As soon as source-force is accepting new bugs I will close this and open a new one for sys.prefix being empty in some conditions. ------------------------------------------------------- Date: 2001-Jan-13 11:39 By: mhammond Comment: Giving to me! ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=128685&group_id=5470 From effbiae@bigpond.com Wed Jan 31 07:40:40 2001 From: effbiae@bigpond.com (Jack Andrews) Date: Wed, 31 Jan 2001 18:40:40 +1100 Subject: [Python-bugs-list] Re: [Bug #127722] getpythonregpath fails References: Message-ID: <3A77C178.4819C127@bigpond.com> I'm embedding Python -- it would be handy if PATH were inspected to find python.exe and deduce PYTHONHOME. The doco for the Python/C API says that the PATH environment variable is examined to locate the python executable, but it appears that in the Win version of Python2.0, PATH is ignored. Is there a reason why PATH is not examined in the Win version? noreply@sourceforge.net wrote: > > Bug #127722, was updated on 2001-Jan-05 21:16 > Here is a current snapshot of the bug. > > Project: Python > Category: Windows > Status: Closed > Resolution: Works For Me > Bug Group: Platform-specific > Priority: 5 > Submitted by: effbiae > Assigned to : mhammond > Summary: getpythonregpath fails > > Details: Hi, > > I'm on Win95 (regrettably). > > I found that while experimenting with embedding Python in C, I initialized > the interpreter, and got the message: > 'import site' failed; use -v for traceback > > If I putenv("PYTHONHOME=C:\python20"), this disappears. Also, if I put the > executable in C:\python20, the problem disappears. > > Please excuse any stupidity that follows as I am a newby to the windows > registy. > > in the file: > Pc\getpathp.c > > in the function: > static char * > getpythonregpath(HKEY keyBase, int skipcore) > > in the call: > rc = RegQueryInfoKey(newKey, NULL, NULL, NULL, &numKeys, NULL, NULL, > NULL, NULL, &dataSize, NULL, NULL); > > numKeys is being set to 0 because in my installation of Python 2.0, the > registry key: > HKEY_LOCAL_MACHINE\\Software\\Python\\PythonCore\\PythonPath\ > > has no subkeys. It has the 'default' (?) value: > > C:\Python20\Lib\plat-win;C:\Python20\Lib;C:\Python20\DLLs;C:\Python20\Lib\lib-tk > > (I do not have HKEY_CURRENT_USER\\Software\\Python\\PythonCore\\PythonPath > -- in fact I do not have HKEY_CURRENT_USER\\Software\\Python) > > Anyway, it looks like the code assumes 'numKeys > 0', which is not the case > at my run-time. > > It appears that the the registry editing part of the installation program > may have changed recently, and this file has not been updated accordingly. > > Also, the doco for the Python/C API says that the PATH environment variable > may be examined to locate the python executable, but it appears that in the > Win version of Python2.0, PATH is ignored. Is there a reason why PATH is > not examined in the Win version? > > Follow-Ups: > > Date: 2001-Jan-30 21:01 > By: mhammond > > Comment: > This is "by design" - see my comments at > https://sourceforge.net/bugs/?func=detailbug&group_id=5470&bug_id=129584 > > Note that there is no default that uses absolute paths (ie, the "C:\..." > you referenced). This is the Python code determining its own core, and > thereby ignoring the registry key for the core (sub-keys are still used) > > I believe the code you reference is fine, and working as designed (but that > may not be how you like ). My testing shows the code working in an > identical fashion regardless of the number of subkeys. > > Also, setting PYTHONHOME is working as designed - this env var tells Python > to not search for its home, and to not use the registry key, but assume the > directory specified is valid, and build its core path from that. > > Marking as "works for me" and closing. > ------------------------------------------------------- > > Date: 2001-Jan-09 17:13 > By: mhammond > > Comment: > Happy to look at this, but it will probably need to wait until I return to > Oz - early Feb. > ------------------------------------------------------- > > Date: 2001-Jan-07 21:37 > By: tim_one > > Comment: > Assigned to MarkH cuz he might actually think he knows what the code is > doing ------------------------------------------------------- > > Date: 2001-Jan-07 15:48 > By: fdrake > > Comment: > Assigned to Tim since this is on Windows. > ------------------------------------------------------- > > For detailed info, follow this link: > http://sourceforge.net/bugs/?func=detailbug&bug_id=127722&group_id=5470 From tim.one@home.com Wed Jan 31 07:52:24 2001 From: tim.one@home.com (Tim Peters) Date: Wed, 31 Jan 2001 02:52:24 -0500 Subject: [Python-bugs-list] Re: [Bug #127722] getpythonregpath fails In-Reply-To: <3A77C178.4819C127@bigpond.com> Message-ID: [Jack Andrews] > I'm embedding Python -- it would be handy if PATH were inspected to find > python.exe and deduce PYTHONHOME. > > The doco for the Python/C API says that the PATH environment variable > is examined to locate the python executable, but it appears that in the > Win version of Python2.0, PATH is ignored. Is there a reason why PATH > is not examined in the Win version? In the msg to which you replied, follow the link Mark gave: > This is "by design" - see my comments at > http://sourceforge.net/bugs/?func=detailbug&group_id=5470&bug_id=129584 From noreply@sourceforge.net Wed Jan 31 07:54:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jan 2001 23:54:55 -0800 Subject: [Python-bugs-list] [Bug #129584] pythonpath registry value ignored in 2.0 Message-ID: Bug #129584, was updated on 2001-Jan-21 04:48 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: Works For Me Bug Group: Platform-specific Priority: 5 Submitted by: esasaki Assigned to : mhammond Summary: pythonpath registry value ignored in 2.0 Details: The value of the HKLM\software\python\pythoncore\2.0\pythonpath key is now ignored in Python 2.0 unless you have at least one subkey underneath it. Since the default installation program doesn't add any subkeys, users familiar with 1.5.2 who expect to just set pythonpath in the registry will be disappointed. I imagine that you all probably run with other extensions installed that add subkeys under pythonpath and thus never see this bug. However, the first thing I did after installing 2.0 was to try to point to my custom libs. 5 hours later I can finally start testing to see if they still work :). This problem is undoubtedly related to bug 127722. Fix that and you'll fix this one. Follow-Ups: Date: 2001-Jan-30 23:54 By: mhammond Comment: Yep - I agree with that, I suppose. If all else fails, searching the path sounds reasonable. As per my comments in https://sourceforge.net/bugs/?func=detailbug&group_id=5470&bug_id=128685, I will soon be submitting a bug to enhance the PYTHONHOME determination, and will roll this into the same report. ------------------------------------------------------- Date: 2001-Jan-30 20:53 By: mhammond Comment: I can not reproduce this. I believe the "problem" is that since Python 1.6, Python's registry search mechanism has changed. If Python can locate its own "home" (which it usually can, given a vanilla install) then it _ignores_ the main registry key, and _only_ looks in subkeys. The rationalle is that this will allow you to have multiple installations of the same Python version (eg, the "official" release and the current CVS version). This will ensure the "core" path is always correct. To test this, copy "python.exe" to a temp directory, and run it from there. In this case Python will not be able to locate its home, and will use the registry key. I am leaving this bug open to remind me to add documentation on the registry somewhere appropriate. However, I am marking as "works for me". ------------------------------------------------------- Date: 2001-Jan-21 10:41 By: tim_one Comment: Mark? You know more about this than everyone else combined. Is that good news or bad ? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129584&group_id=5470 From noreply@sourceforge.net Wed Jan 31 08:00:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jan 2001 00:00:35 -0800 Subject: [Python-bugs-list] [Bug #129584] pythonpath registry value ignored in 2.0 Message-ID: Bug #129584, was updated on 2001-Jan-21 04:48 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: Works For Me Bug Group: Platform-specific Priority: 5 Submitted by: esasaki Assigned to : mhammond Summary: pythonpath registry value ignored in 2.0 Details: The value of the HKLM\software\python\pythoncore\2.0\pythonpath key is now ignored in Python 2.0 unless you have at least one subkey underneath it. Since the default installation program doesn't add any subkeys, users familiar with 1.5.2 who expect to just set pythonpath in the registry will be disappointed. I imagine that you all probably run with other extensions installed that add subkeys under pythonpath and thus never see this bug. However, the first thing I did after installing 2.0 was to try to point to my custom libs. 5 hours later I can finally start testing to see if they still work :). This problem is undoubtedly related to bug 127722. Fix that and you'll fix this one. Follow-Ups: Date: 2001-Jan-31 00:00 By: mhammond Comment: Doh - typing before thinking again :-( This could potentially be very dangerous. If you are embedding _and_ have your own Python installation used by your embedded app, there is a risk that a "vanilla" Python will be located by the path search. If I get my way and Python on Windows can determine its home based on the sys.path it has loaded, then this should solve your problem without resorting to a path search. If Python does this, then I can't think of a scenario where searching PATH will give a better results. Can you give a scenario for embedding where ------------------------------------------------------- Date: 2001-Jan-30 23:54 By: mhammond Comment: Yep - I agree with that, I suppose. If all else fails, searching the path sounds reasonable. As per my comments in https://sourceforge.net/bugs/?func=detailbug&group_id=5470&bug_id=128685, I will soon be submitting a bug to enhance the PYTHONHOME determination, and will roll this into the same report. ------------------------------------------------------- Date: 2001-Jan-30 20:53 By: mhammond Comment: I can not reproduce this. I believe the "problem" is that since Python 1.6, Python's registry search mechanism has changed. If Python can locate its own "home" (which it usually can, given a vanilla install) then it _ignores_ the main registry key, and _only_ looks in subkeys. The rationalle is that this will allow you to have multiple installations of the same Python version (eg, the "official" release and the current CVS version). This will ensure the "core" path is always correct. To test this, copy "python.exe" to a temp directory, and run it from there. In this case Python will not be able to locate its home, and will use the registry key. I am leaving this bug open to remind me to add documentation on the registry somewhere appropriate. However, I am marking as "works for me". ------------------------------------------------------- Date: 2001-Jan-21 10:41 By: tim_one Comment: Mark? You know more about this than everyone else combined. Is that good news or bad ? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129584&group_id=5470 From noreply@sourceforge.net Wed Jan 31 10:32:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jan 2001 02:32:32 -0800 Subject: [Python-bugs-list] [Bug #129293] zlib library used for binary win32 distribution can crash Message-ID: Bug #129293, was updated on 2001-Jan-18 12:41 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: Works For Me Bug Group: Platform-specific Priority: 5 Submitted by: greg Assigned to : mhammond Summary: zlib library used for binary win32 distribution can crash Details: The zlib .lib or .dll that is used for the binary distribution of python 2.0 (both from python.org and in activestate's "build 202" of python 2.0) contains a bug that only seems to show up on some people's win98 systems. When it does, it appears to be nasty and cause windows crashes (overwriting other memory, etc..?). I was able to fix it by building my own copy of the zlib library from sources and linking the zlib module against that. Using the win32 binary distribution of the zlib lib/dlls that is easily findable via a web search seems to cause the problem (I suspect that is the package used in the distribution build?). I can provide both broken and working zlib.pyd files as well as source archives I found and used to build zlib if desired. I used MSVC++ 6.0 sp4 to build. Follow-Ups: Date: 2001-Jan-31 02:32 By: mhammond Comment: Hopefully fixed in Rev 1.15 of PCbuild/zlib.dsp (with supporting comments added in Rev 2.37 of Modules/zlibmodules.c.) Marking as "works for me", but leaving open for a little while to see if the original error can be provoked once 2.1 hits the streets. ------------------------------------------------------- Date: 2001-Jan-19 09:48 By: mhammond Comment: It appears from the description that we could solve this by using the zlib sources, and building our own .dll from these sources. This guarantees the .h and .dll files etc are in synch, and allows us to have a single "zlib" directory. As Tim hinted, this is exactly what I tried to do around a year ago. The biggest problem is that it will "break" Python builds until people update their zlib directories. In particular, Guido commented something like "do what you want but dont break my build" - unfortunately, I can't promise that! I will submit a patch on this, but unfortunately, this wont be for a week or so. ------------------------------------------------------- Date: 2001-Jan-19 00:17 By: greg Comment: Sorry, I don't have a good test case. I only know that the problem exhibits itself in a semi-identifiable manner by sometimes causing win98 on other people's boxes (in the behavior of all annoying bugs: not on any of my machines) to pop up an application error dialog pointing to the zlib dll. Rebuilding zlib from its sources and linking zlib.pyd using that fixed it. For reference: the application we saw this in was mojonation (also a sourceforge project). I'll dig out the exact source package we're using for the zlib library as well as how I built it tomorrow. The prebuilt winimage.com zlib113dll.zip that you mention sounds like the one that I can confirm does not work well. ------------------------------------------------------- Date: 2001-Jan-18 23:39 By: tim_one Comment: Mark, this rings a bell. Not the claim of a bug (first I ever heard of that -- greg, have a short & executable test case?), but that you were keen at one time to change how we did zlib. For 2.0, the DLL came from http://www.winimage.com/zLibDll/zlib133dll.zip and the rest from ftp://ftp.uu.net/graphics/png/src/zlib133.zip If we don't build it ourselves, we've got no handle on possible bugs (IMO). ------------------------------------------------------- Date: 2001-Jan-18 19:25 By: gvanrossum Comment: Thanks! Doubt this comes in time for 2.1a1, but we'll gladly accept your services. I'll defer to our Windows cleaner, Tim, to take action on this. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129293&group_id=5470 From noreply@sourceforge.net Wed Jan 31 23:45:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jan 2001 15:45:10 -0800 Subject: [Python-bugs-list] [Bug #129827] Mac OSX build of 2.1a needs "-traditional-cpp" Message-ID: Bug #129827, was updated on 2001-Jan-23 09:34 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: sdm7g Assigned to : fdrake Summary: Mac OSX build of 2.1a needs "-traditional-cpp" Details: build of 2.1a1 fails on Mac OSX: compiling classobject.c generates a syntax error cc needs "-traditional-cpp" flag (This probably should have been in before, but changes to classobject uncovered the bug. ) -- Steve Follow-Ups: Date: 2001-Jan-31 15:45 By: sdm7g Comment: Modifying Py_DECREF macro in Include/object.h does not remove the error. -- Steve. ------------------------------------------------------- Date: 2001-Jan-31 15:43 By: sdm7g Comment: Modifying Py_DECREF macro in Include/object.h does not remove the error. -- Steve. ------------------------------------------------------- Date: 2001-Jan-26 21:59 By: fdrake Comment: Try changing the first line of the expansion of the Py_DECREF macro to this: if (--_Py_RefTotal, (--((op)->ob_refcnt) != 0)) \ (note the additional sets of paretheses around the second half of the test expression) I'm not sure this will help, but if it does, that would be nice. ------------------------------------------------------- Date: 2001-Jan-26 11:43 By: sdm7g Comment: Fred, FYI, the specific error message is: cc -c -g -O2 -Wall -Wstrict-prototypes -fPIC -I. -I./Include -DHAVE_CONFIG_H -o Objects/classobject.o Objects/classobject.c Objects/classobject.c:1415: illegal expression, found `->' Objects/classobject.c:1415: illegal expression, found `)' Objects/classobject.c:1415: illegal expression, found `)' make: *** [Objects/classobject.o] Error 1 FYI**2, gcc on macosx supports precompiling headers files and the docs state: -traditional-cpp Controls which preprocessor is used. The default is cpp_precomp ; if you specify this flag, the standard GNU cpp will be used instead. I think it's a bug in the precompiler cpp that produces the errors. Since Dan and his pals at apple are the only ones to have Post public beta builds, and if they change the default, it won't matter if it's in there explicitly (I don't know what the default for public dist. Darwin is) it won't hurt to add it. (But if it's a pain, then after Mar 24, non-apple folks will be able to get the version on which it doesn't matter! ) ------------------------------------------------------- Date: 2001-Jan-26 09:58 By: fdrake Comment: It might be nice to know more about the specific error generated; what in classobject.c is causing a problem? ------------------------------------------------------- Date: 2001-Jan-23 22:05 By: dkwolfe Comment: Note: This is only true for Public Beta. Post public beta builds do not need this flag. (the bug in the pre-processor has been fixed.) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129827&group_id=5470 From noreply@sourceforge.net Wed Jan 31 23:43:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jan 2001 15:43:02 -0800 Subject: [Python-bugs-list] [Bug #129827] Mac OSX build of 2.1a needs "-traditional-cpp" Message-ID: Bug #129827, was updated on 2001-Jan-23 09:34 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: sdm7g Assigned to : fdrake Summary: Mac OSX build of 2.1a needs "-traditional-cpp" Details: build of 2.1a1 fails on Mac OSX: compiling classobject.c generates a syntax error cc needs "-traditional-cpp" flag (This probably should have been in before, but changes to classobject uncovered the bug. ) -- Steve Follow-Ups: Date: 2001-Jan-31 15:43 By: sdm7g Comment: Modifying Py_DECREF macro in Include/object.h does not remove the error. -- Steve. ------------------------------------------------------- Date: 2001-Jan-26 21:59 By: fdrake Comment: Try changing the first line of the expansion of the Py_DECREF macro to this: if (--_Py_RefTotal, (--((op)->ob_refcnt) != 0)) \ (note the additional sets of paretheses around the second half of the test expression) I'm not sure this will help, but if it does, that would be nice. ------------------------------------------------------- Date: 2001-Jan-26 11:43 By: sdm7g Comment: Fred, FYI, the specific error message is: cc -c -g -O2 -Wall -Wstrict-prototypes -fPIC -I. -I./Include -DHAVE_CONFIG_H -o Objects/classobject.o Objects/classobject.c Objects/classobject.c:1415: illegal expression, found `->' Objects/classobject.c:1415: illegal expression, found `)' Objects/classobject.c:1415: illegal expression, found `)' make: *** [Objects/classobject.o] Error 1 FYI**2, gcc on macosx supports precompiling headers files and the docs state: -traditional-cpp Controls which preprocessor is used. The default is cpp_precomp ; if you specify this flag, the standard GNU cpp will be used instead. I think it's a bug in the precompiler cpp that produces the errors. Since Dan and his pals at apple are the only ones to have Post public beta builds, and if they change the default, it won't matter if it's in there explicitly (I don't know what the default for public dist. Darwin is) it won't hurt to add it. (But if it's a pain, then after Mar 24, non-apple folks will be able to get the version on which it doesn't matter! ) ------------------------------------------------------- Date: 2001-Jan-26 09:58 By: fdrake Comment: It might be nice to know more about the specific error generated; what in classobject.c is causing a problem? ------------------------------------------------------- Date: 2001-Jan-23 22:05 By: dkwolfe Comment: Note: This is only true for Public Beta. Post public beta builds do not need this flag. (the bug in the pre-processor has been fixed.) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129827&group_id=5470 From noreply@sourceforge.net Wed Jan 31 22:24:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jan 2001 14:24:23 -0800 Subject: [Python-bugs-list] [Bug #129293] zlib library used for binary win32 distribution can crash Message-ID: Bug #129293, was updated on 2001-Jan-18 12:41 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Closed Resolution: Fixed Bug Group: Platform-specific Priority: 5 Submitted by: greg Assigned to : mhammond Summary: zlib library used for binary win32 distribution can crash Details: The zlib .lib or .dll that is used for the binary distribution of python 2.0 (both from python.org and in activestate's "build 202" of python 2.0) contains a bug that only seems to show up on some people's win98 systems. When it does, it appears to be nasty and cause windows crashes (overwriting other memory, etc..?). I was able to fix it by building my own copy of the zlib library from sources and linking the zlib module against that. Using the win32 binary distribution of the zlib lib/dlls that is easily findable via a web search seems to cause the problem (I suspect that is the package used in the distribution build?). I can provide both broken and working zlib.pyd files as well as source archives I found and used to build zlib if desired. I used MSVC++ 6.0 sp4 to build. Follow-Ups: Date: 2001-Jan-31 14:24 By: mhammond Comment: Hrm - I have decided to close this. If it does appear in the future, then we will need some sort of test case or test zip file, and presumably work with the InfoZip people to resolve it - but at least now we have a decent build process that will stand up to scutiny. ------------------------------------------------------- Date: 2001-Jan-31 02:32 By: mhammond Comment: Hopefully fixed in Rev 1.15 of PCbuild/zlib.dsp (with supporting comments added in Rev 2.37 of Modules/zlibmodules.c.) Marking as "works for me", but leaving open for a little while to see if the original error can be provoked once 2.1 hits the streets. ------------------------------------------------------- Date: 2001-Jan-19 09:48 By: mhammond Comment: It appears from the description that we could solve this by using the zlib sources, and building our own .dll from these sources. This guarantees the .h and .dll files etc are in synch, and allows us to have a single "zlib" directory. As Tim hinted, this is exactly what I tried to do around a year ago. The biggest problem is that it will "break" Python builds until people update their zlib directories. In particular, Guido commented something like "do what you want but dont break my build" - unfortunately, I can't promise that! I will submit a patch on this, but unfortunately, this wont be for a week or so. ------------------------------------------------------- Date: 2001-Jan-19 00:17 By: greg Comment: Sorry, I don't have a good test case. I only know that the problem exhibits itself in a semi-identifiable manner by sometimes causing win98 on other people's boxes (in the behavior of all annoying bugs: not on any of my machines) to pop up an application error dialog pointing to the zlib dll. Rebuilding zlib from its sources and linking zlib.pyd using that fixed it. For reference: the application we saw this in was mojonation (also a sourceforge project). I'll dig out the exact source package we're using for the zlib library as well as how I built it tomorrow. The prebuilt winimage.com zlib113dll.zip that you mention sounds like the one that I can confirm does not work well. ------------------------------------------------------- Date: 2001-Jan-18 23:39 By: tim_one Comment: Mark, this rings a bell. Not the claim of a bug (first I ever heard of that -- greg, have a short & executable test case?), but that you were keen at one time to change how we did zlib. For 2.0, the DLL came from http://www.winimage.com/zLibDll/zlib133dll.zip and the rest from ftp://ftp.uu.net/graphics/png/src/zlib133.zip If we don't build it ourselves, we've got no handle on possible bugs (IMO). ------------------------------------------------------- Date: 2001-Jan-18 19:25 By: gvanrossum Comment: Thanks! Doubt this comes in time for 2.1a1, but we'll gladly accept your services. I'll defer to our Windows cleaner, Tim, to take action on this. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129293&group_id=5470 From noreply@sourceforge.net Wed Jan 31 20:23:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jan 2001 12:23:41 -0800 Subject: [Python-bugs-list] [Bug #129827] Mac OSX build of 2.1a needs "-traditional-cpp" Message-ID: Bug #129827, was updated on 2001-Jan-23 09:34 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: sdm7g Assigned to : fdrake Summary: Mac OSX build of 2.1a needs "-traditional-cpp" Details: build of 2.1a1 fails on Mac OSX: compiling classobject.c generates a syntax error cc needs "-traditional-cpp" flag (This probably should have been in before, but changes to classobject uncovered the bug. ) -- Steve Follow-Ups: Date: 2001-Jan-26 21:59 By: fdrake Comment: Try changing the first line of the expansion of the Py_DECREF macro to this: if (--_Py_RefTotal, (--((op)->ob_refcnt) != 0)) \ (note the additional sets of paretheses around the second half of the test expression) I'm not sure this will help, but if it does, that would be nice. ------------------------------------------------------- Date: 2001-Jan-26 11:43 By: sdm7g Comment: Fred, FYI, the specific error message is: cc -c -g -O2 -Wall -Wstrict-prototypes -fPIC -I. -I./Include -DHAVE_CONFIG_H -o Objects/classobject.o Objects/classobject.c Objects/classobject.c:1415: illegal expression, found `->' Objects/classobject.c:1415: illegal expression, found `)' Objects/classobject.c:1415: illegal expression, found `)' make: *** [Objects/classobject.o] Error 1 FYI**2, gcc on macosx supports precompiling headers files and the docs state: -traditional-cpp Controls which preprocessor is used. The default is cpp_precomp ; if you specify this flag, the standard GNU cpp will be used instead. I think it's a bug in the precompiler cpp that produces the errors. Since Dan and his pals at apple are the only ones to have Post public beta builds, and if they change the default, it won't matter if it's in there explicitly (I don't know what the default for public dist. Darwin is) it won't hurt to add it. (But if it's a pain, then after Mar 24, non-apple folks will be able to get the version on which it doesn't matter! ) ------------------------------------------------------- Date: 2001-Jan-26 09:58 By: fdrake Comment: It might be nice to know more about the specific error generated; what in classobject.c is causing a problem? ------------------------------------------------------- Date: 2001-Jan-23 22:05 By: dkwolfe Comment: Note: This is only true for Public Beta. Post public beta builds do not need this flag. (the bug in the pre-processor has been fixed.) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129827&group_id=5470 From noreply@sourceforge.net Wed Jan 31 20:22:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jan 2001 12:22:21 -0800 Subject: [Python-bugs-list] [Bug #130359] Run script should not appear in shell window Message-ID: Bug #130359, was updated on 2001-Jan-28 15:31 Here is a current snapshot of the bug. Project: Python Category: IDLE Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: loewis Assigned to : gvanrossum Summary: Run script should not appear in shell window Details: When selecting "Run module" in the shell window, an error message "The buffer Python Shell is not saved..." is produced. Since running the shell window will fail in any case, these menu items should be removed from the shell window. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130359&group_id=5470 From noreply@sourceforge.net Wed Jan 31 20:20:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jan 2001 12:20:27 -0800 Subject: [Python-bugs-list] [Bug #129995] segfaults on AIX if configured with threads Message-ID: Bug #129995, was updated on 2001-Jan-24 16:44 Here is a current snapshot of the bug. Project: Python Category: Threads Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: bcollar Assigned to : bwarsaw Summary: segfaults on AIX if configured with threads Details: Hi. AIX 4.2.1. ran ./configure --without-gcc --prefix=/development/utils. make CC=xlC OPT="-O2 -qmaxmem=4000". some of the make output follows. Let me know if you need all of it. if test ! -f ../Modules/hassignal; then echo adding sigcheck.o; ar r ../libpython2.1.a sigcheck.o; else echo leaving sigcheck.o out; fi leaving sigcheck.o out touch add2lib if test -f hassignal; then echo removing sigcheck.o intrcheck.o; ar d ../libpython2.1.a sigcheck.o intrcheck.o 2>/dev/null; else echo leaving sigcheck.o intrcheck.o in; fi removing sigcheck.o intrcheck.o make: 1254-004 The error code from the last command is 2. make: 1254-005 Ignored error code 2 from last command. ar cr ../libpython2.1.a gcmodule.o threadmodule.o posixmodule.o _sre.o signalmodule.o config.o getpath.o main.o getbuildinfo.o touch add2lib cd Modules; make OPT="-O2 -qmaxmem=4000" python.o xlC -O2 -qmaxmem=4000 -I./../Include -I.. -DHAVE_CONFIG_H -c python.c expr `cat buildno` + 1 >buildno1 mv -f buildno1 buildno xlC -c -O2 -qmaxmem=4000 -I. -DHAVE_CONFIG_H -DBUILD=`cat buildno` ./Modules/getbuildinfo.c ar cr libpython2.1.a getbuildinfo.o ranlib libpython2.1.a true cd Modules; make OPT="-O2 -qmaxmem=4000" VERSION="2.1" prefix="/development/utils/" exec_prefix="/development/utils/" LIBRARY=../libpython2.1.a link ./makexp_aix python.exp "" ../libpython2.1.a; xlC -Wl,-bE:python.exp -lld python.o ../libpython2.1.a -ldl -lpthreads -lm -o python mv python ../python ./python ./setup.py build pthread_mutex_init: Error 0 pthread_cond_init: Error 0 pthread_mutex_lock[1]: Error 0 make: 1254-059 The signal code from the last command is 11. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129995&group_id=5470 From noreply@sourceforge.net Wed Jan 31 20:19:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jan 2001 12:19:58 -0800 Subject: [Python-bugs-list] [Bug #129991] build process references ld_so_aix in lib before it exists Message-ID: Bug #129991, was updated on 2001-Jan-24 16:22 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Submitted by: bcollar Assigned to : akuchling Summary: build process references ld_so_aix in lib before it exists Details: Platform: AIX 4.2.1. performed ./configure --without-gcc --without-threads --prefix=/development/utils. Had to do --without-threads because otherwise it builds, but core dumps. make CC=xlC OPT="-O2 -qmaxmem=4000". make bombs because there is not a directory called /development/utils/lib/python2.1. Here is the relevant output from make: running build running build_ext building 'struct' extension skipping /development/utils/src/Python-2.1a1/Modules/structmodule.c (build/temp.aix-2-000310094C00-2.1/structmodule.o up-to-date) /development/utils/lib/python2.1/config/ld_so_aix cc -bI:/development/utils/lib/python2.1/config/python.exp build/temp.aix-2-000310094C00-2.1/structmodule.o -L/usr/local/lib -o build/lib.aix-2-000310094C00-2.1/struct.so unable to execute /development/utils/lib/python2.1/config/ld_so_aix: No such file or directory error: command '/development/utils/lib/python2.1/config/ld_so_aix' failed with exit status 1 make: 1254-004 The error code from the last command is 1. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129991&group_id=5470 From noreply@sourceforge.net Wed Jan 31 20:19:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jan 2001 12:19:19 -0800 Subject: [Python-bugs-list] [Bug #130006] /test/tokenize_tests_.py minor bug Message-ID: Bug #130006, was updated on 2001-Jan-24 20:00 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : jhylton Summary: /test/tokenize_tests_.py minor bug Details: There is a minor error on line 147 in the module /test/tokenize_tests.py of the new 2.1alpha1. The function d01v has the parameter name "rest" repeated in the function definition. This gives an error message when that function is reached during "make install" on a Debian 2.2 (potato) Linux system. Follow-Ups: Date: 2001-Jan-31 12:19 By: jhylton Comment: I can't reproduce this problem on my system. The file definitely has duplicate arguments, but that shouldn't affect the tokenize test. Can you provide the exact error output you see? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130006&group_id=5470