[ python-Bugs-1112549 ] cgi.FieldStorage memory usage can spike in line-oriented ops
Bugs item #1112549, was opened at 2005-01-30 13:40 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 Status: Open Resolution: None >Priority: 8 Submitted By: Chris McDonough (chrism) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.FieldStorage memory usage can spike in line-oriented ops Initial Comment: Various parts of cgi.FieldStorage call its "read_lines_to_outerboundary", "read_lines" and "skip_lines" methods.These methods use the "readline" method of the file object that represents an input stream. The input stream is typically data supplied by an untrusted source (such as a user uploading a file from a web browser). The input data is not required by the RFC 822/1521/1522/1867 specifications to contain any newline characters. For example, it is within the bounds of the specification to supply a a multipart/form-data input stream with a "file-data" part that consists of a 2GB string composed entirely of "x" characters (which happens to be something I did that led me to noticing this bug). The simplest fix is to make use of the "size" argument of the readline method of the file object where it is used within all parts of FieldStorage that make use of it. A patch against the Python 2.3.4 cgi.py module that does this is attached. -- Comment By: Chris McDonough (chrism) Date: 2006-07-27 21:42 Message: Logged In: YES user_id=32974 The files I've just uploaded are revisions to the cgi and test_cgi modules for the current state of the SVN trunk. If someone could apply these, it would be appreciated, or give me access and I'll be happy to. FTR, this is a bug which exposes systems which use the cgi.FieldStorage class (most Python web frameworks do) to a denial of service potential. -- Comment By: Chris McDonough (chrism) Date: 2005-04-03 04:00 Message: Logged In: YES user_id=32974 FYI, I'd be happy to do the merging here if you wanted to give me checkin access. -- Comment By: Chris McDonough (chrism) Date: 2005-04-03 03:42 Message: Logged In: YES user_id=32974 An updated test_cgi.py is attached. I test both the readline behavior and add a test for basic multipart parsing. -- Comment By: Guido van Rossum (gvanrossum) Date: 2005-04-01 04:48 Message: Logged In: YES user_id=6380 Can I tweak you into uploading a unit test? -- Comment By: Chris McDonough (chrism) Date: 2005-04-01 02:56 Message: Logged In: YES user_id=32974 Re: parse_multipart.. yes, it looks like there's no use fixing that as it just turns around and puts the line into a list.. it is vulnerable but just by virtue of its non-use of a tempfile, it appears doomed anyway for large requests. I don't know of anything that uses it. Good catch wrt boundary recognition bug, I'm uploading another patch. -- Comment By: Guido van Rossum (gvanrossum) Date: 2005-03-31 22:13 Message: Logged In: YES user_id=6380 Methinks that the fix isn't quite right: it would incorrectly recognize as a boundary a very long line starting with "--" followed by the appropriate random string at offset 2**16. This could probably be taken care of by adding a flag that is true initially and after that keeps track of whether the previous line ended in \n. Also, there's a call to fp.readline() in parse_multipart() that you didn't patch -- it wouldn't help because that code is saving the lines in a list anyway, but isn't that code vulnerable as well? Or is it not used? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-835255 ] new.function() docs out of date
Bugs item #835255, was opened at 2003-11-03 20:26 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835255&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Jeremy Hylton (jhylton) Summary: new.function() docs out of date Initial Comment: The argument list for new.function() has grown to accomodate new runtime features (closure info, for example), but the docs have not kept up. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-07-29 08:51 Message: Logged In: YES user_id=849994 Documented closure argument in rev. 50922, 50923. -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-11-20 13:01 Message: Logged In: YES user_id=3066 Assigned to Jeremy since he made the changes and can explain what the new arguments are for. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835255&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1441397 ] compiler module loses docstrings
Bugs item #1441397, was opened at 2006-03-02 00:52
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441397&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: compiler module loses docstrings
Initial Comment:
this is svn head:
>>> import compiler
>>> compiler.transformer.parse("'doc'")
Module(None, Stmt([Discard(Const('doc'))]))
this is 2.4:
>>> import compiler
>>> compiler.transformer.parse("'doc'")
Module('doc', Stmt([]))
I think the problem may be rooted in the parser module rather than the
compiler module itself.
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-29 09:34
Message:
Logged In: YES
user_id=849994
The bug was transformer._doc_nodes missing or_test.
Fixed in rev. 50924, including test.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441397&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1014230 ] optparse: parser.remove_option("-h") inconsistency
Bugs item #1014230, was opened at 2004-08-23 10:04
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014230&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: strop (strop)
>Assigned to: Greg Ward (gward)
Summary: optparse: parser.remove_option("-h") inconsistency
Initial Comment:
remove_option("-h") method of OptionParser has a strange
behaviour : it can't be removed from 2 different OptionParser
objects.
It may be due to the fact that the help option seems to be a
unique object.
Even if this can be "solved" by addind add_help_option=0 to
OptionParser constructor parameters, it seems to be an
inconsistency wrt remove_option method
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014230&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1246405 ] Segmentation fault when importing expat from xml.parser
Bugs item #1246405, was opened at 2005-07-27 23:07 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246405&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.4 >Status: Pending >Resolution: Fixed Priority: 5 Submitted By: Jean-Pierre (jean-pierre24) Assigned to: Nobody/Anonymous (nobody) Summary: Segmentation fault when importing expat from xml.parser Initial Comment: Hello, I have a strange segmentation fault when importing expat from xml.parsers in the following program (I removed all that is un-necessary to reproduce the bug, which is why the code may look odd). I've also posted this bug on wxPython bug lists because I'm not sure if it's related to Python or wxPython, but anyway the backtrace told me that the segmentation fault occurs when importing expat. import wx import wx.html class MainFrame(wx.Frame): def __init__(self, prnt): wx.Frame.__init__(self, parent=prnt) wx.html.HtmlWindow(wx.Window(self, -1), -1) print "debug 1" from xml.parsers import expat print "debug 2" class BoaApp(wx.App): def OnInit(self): wx.InitAllImageHandlers() MainFrame(None) return True app = BoaApp() The segmentation fault occurs between 'debug 1' and 'debug 2'. If I try to remove anything else, it doesn't happen. I have confirmed the bug on SunOS 5.8, on linux Red Hat Enterprise Server 3 and linux Advanced Server 3. I'm working with Python 2.4.1 and wxPython 2.6.1.0 Here is in attached file, the backtrace from gdb. Feel free to ask me any additional information... -- >Comment By: Georg Brandl (gbrandl) Date: 2006-07-29 10:36 Message: Logged In: YES user_id=849994 Patch 1295808 should have fixed this. Can you try it with Python 2.5b2? -- Comment By: Bernhard Herzog (bernhard) Date: 2005-12-01 13:51 Message: Logged In: YES user_id=2369 Could this be the same problem as bug 1075984 ? URL: https://sourceforge.net/tracker/index.php?func=detail&aid=1075984&group_id=5470&atid=105470 -- Comment By: Jean-Pierre (jean-pierre24) Date: 2005-10-06 20:23 Message: Logged In: YES user_id=1247525 Yes I can try with different version of wx, but it will take time. Anyway for today here is in attachment the valgrind output on linux x86. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-05 03:34 Message: Logged In: YES user_id=33168 I don't have the problem with Python 2.3.4 and wx 2.5.5.1. Are you able to try different versions of wxPython? I notice that wx 2.6.2 is available. Are you able to run under valgrind or purify? If you run under valgrind, be sure to specify --suppressions=Misc/valgrind-python.supp The file is in the Python distribution. You can download it through SourceForge ViewCVS. -- Comment By: Jean-Pierre (jean-pierre24) Date: 2005-10-04 22:05 Message: Logged In: YES user_id=1247525 Link is : http://sourceforge.net/tracker/index.php?func=detail&aid=1246397&group_id=9863&atid=109863 Unfortunately, absolutely nothing has happened since I reported the bug. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-04 05:10 Message: Logged In: YES user_id=33168 Can you provide a link to the wx bug report? Has anything happend with it? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246405&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1075984 ] Memory fault pyexpat.so on SGI
Bugs item #1075984, was opened at 2004-11-30 13:13
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.4
>Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: Maik Hertha (mhertha)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Memory fault pyexpat.so on SGI
Initial Comment:
I build the latest RC1 of python 2.4.
System SGI Fuel IP35, Irix 6.5.26m
cc -version
MIPSpro Compilers: Version 7.3.1.3m
- make tests passes test_pyexpat without error
- running this code leads to a core dump
-- code ---
import xml.dom.minidom
doc = xml.dom.minidom.parseString(fstream)
<<< core dump >>>
--- runing python -v test.py
#
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
matches
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.py
import xml.dom.expatbuilder # precompiled from
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
import xml.parsers # directory
/opt/python24c1/lib/python2.4/xml/parsers
#
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
matches
/opt/python24c1/lib/python2.4/xml/parsers/__init__.py
import xml.parsers # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
# /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
matches /opt/python24c1/lib/python2.4/xml/parsers/expat.py
import xml.parsers.expat # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
dlopen("/opt/python24c1/lib/python2.4/lib-dynload/pyexpat.so",
2);
Memory fault(coredump)
- running this code from an interactive session leads
not to a coredump
I need some assistance howto provide further debug
information.
--maik./
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-29 10:39
Message:
Logged In: YES
user_id=849994
This should be addressed by patch #1295808.
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-10-02 08:24
Message:
Logged In: YES
user_id=21627
I think the problem will occur whenever somebody loads
libexpat.so with dlopen and RTLD_GLOBAL. IMO, this should be
avoided. I can't see in which of these different reports
this really is the case, but in those cases, this much looks
like a third-party bug.
If you import pyexpat first, it looks fine, since it will
resolve the symbols against its own copy, without exporting
them. Then, the later usage of libexpat cannot mistakenly go
into pyexpat because Python loaded this with RTLD_LOCAL.
However, it still may crash later when symbols are resolved
lazily, as more expat symbols might be needed when using
pyexpat, so different symbols might go to different libraries.
Linking pyexpat with -Bsymbolic (where available) should
also solve the problem.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-30 06:01
Message:
Logged In: YES
user_id=33168
The problem seems to be related (same?) as bug #1295808.
Does the patch there fix these problems?
--
Comment By: Steve Juranich (sjuranic)
Date: 2005-07-19 16:22
Message:
Logged In: YES
user_id=1315245
FWIW, this same problem crops up when using Python & VTK
together (which also ships with its own version of expat).
bos's workaround will make things work, though.
--
Comment By: Bernhard Herzog (bernhard)
Date: 2005-03-29 18:11
Message:
Logged In: YES
user_id=2369
I ran into this problem as well on a debian GNU/Linux system
on x86 hardware. It occurs both with pygtk 2.4 and wxPython
2.5 both built against gtk 2.4.
bos' patch at least solves the immediate problem of the
segmentation fault. It may be a good idea to print a
warning message if some of the error codes cannot be
translated to strings, though.
--
Comment By: Bryan O'Sullivan (bos)
Date: 2005-02-04 23:16
Message:
Logged In: YES
user_id=28380
With the GNU linker, you can pass in -Bstatic to force it to resolve the
symbols in the local shared library, instead of globally. This also works on
Irix. I don't know about other Unixes.
--
Comment By: Michael Hudson (mwh)
Date: 2005-02-02 10:35
Message:
Logged In: YES
user_id=6656
It's a nasty one, I'll give you that.
Fred, what do you think of bos's patch? It solves the immediate issue,
but I'm not sure it's a complete fix.
It seems to me that it would be better to resolve the expat symbols at
builf time, but I don't know how to arrange for that.
-
[ python-Bugs-1437785 ] Problems w/ expat 1.95.7 vs. Python 2.4
Bugs item #1437785, was opened at 2006-02-23 23:59 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437785&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.4 >Status: Pending >Resolution: Fixed Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Problems w/ expat 1.95.7 vs. Python 2.4 Initial Comment: This may apply to the trunk as well... Today I finished installing 2.4.2 and all our local libraries at work. Trying out the main application I use I discovered Python segfaulting when trying to import pyexpat. It turned out that during the import an earlier module (gtk.glade) also wanted libexpat. Apparently pyexpat was expecting to get Expat 1.95.8 (what's delivered with Python) but got 1.95.7 instead (what we had installed and what was already linked with all our other Expat-using code). The solution was rather simple. I just commented out those constants in the pyexpat initialization that were marked as 1.95.8. Fortunately there was a comment identifying the version dependency. Is there some way that Python's build process can detect the Expat version and conditionally include/exclude bits that are for later versions? -- >Comment By: Georg Brandl (gbrandl) Date: 2006-07-29 10:41 Message: Logged In: YES user_id=849994 Should be fixed by patch #1295808. -- Comment By: Skip Montanaro (montanaro) Date: 2006-03-03 20:15 Message: Logged In: YES user_id=44345 Martin, I'm sorry. If I understood it better I'd explain it better. Tell me if this helps. We have expat 1.95.7 installed. We have C++ libraries that link with that version and are wrapped for use with Python using SWIG. Python 2.4 comes with 1.95.8. Apparently setup.py finds that and compiles pyexpat against it. In the pyexpat init function I see this block of constant initialization: /* Added in Expat 1.95.8. */ MYCONST(XML_ERROR_UNDECLARING_PREFIX); MYCONST(XML_ERROR_INCOMPLETE_PE); MYCONST(XML_ERROR_XML_DECL); MYCONST(XML_ERROR_TEXT_DECL); MYCONST(XML_ERROR_PUBLICID); MYCONST(XML_ERROR_SUSPENDED); MYCONST(XML_ERROR_NOT_SUSPENDED); MYCONST(XML_ERROR_ABORTED); MYCONST(XML_ERROR_FINISHED); MYCONST(XML_ERROR_SUSPEND_PE); If they are left in there, Python reliably segfaults at the first of those lines. When I exclude those lines, everything works fine. If I run ldd over pyexpat.so I don't see that libexpat is dynamically linked in: % ldd pyexpat.so libgcc_s.so.1 => /opt/lang/gcc-3.3.2/lib/libgcc_s.so.1 libc.so.1 => /lib/libc.so.1 libm.so.2 => /lib/libm.so.2 I thus have a statically linked version of libexpat 1.95.8 which appears to be exporting symbols: % nm -p pyexpat.so | egrep XML 042312 T XML_DefaultCurrent 042380 T XML_ErrorString 042428 T XML_ExpatVersion 042452 T XML_ExpatVersionInfo 039164 T XML_ExternalEntityParserCreate 042232 T XML_FreeContentModel 040580 T XML_GetBase 041584 T XML_GetBuffer ... Elsewhere I have a C++ library that is dynamically linked to 1.95.7, so I essentially have libexpat linked into the system twice. Does that seem like a reasonable description of our setup? If so, I can understand that trying to use (for example) XML_ERROR_UNDECLARING_PREFIX (which is new to 1.95.8) with symbols from libexpat 1.95.7 might create problems. I don't see how it could cause problems during constant initialization, but it does, quite reliably. You're much more savvy about these things than I am. Maybe you can see how this would happen. How do we tell Python's build process not to use the bundled 1.95.8? My local C++ gurus tell me they are not willing to rebuild everything with 1.95.8 just to make pyexpat happy. If we tell it that, then those constant initialization lines need to be conditionally exposed to the compiler so that it works to compile with libexpat 1.95.7. -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-03 17:44 Message: Logged In: YES user_id=21627 I don't understand the problem. The build process should have picked-up the Python-provided expat, and should have ignored the system-installed one in all places (compiling, linking, running). What was the specific sequence of commands that you entered, what what the output you got, and what output would you have expected instead? -- You can respond by visiting: https://sourceforge.net/track
[ python-Bugs-883495 ] python crash in pyexpat's XmlInitUnknownEncodingNS
Bugs item #883495, was opened at 2004-01-24 07:15 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=883495&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.3 >Status: Closed Resolution: Works For Me Priority: 7 Submitted By: Matthias Klose (doko) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: python crash in pyexpat's XmlInitUnknownEncodingNS Initial Comment: [forwarded from http://bugs.debian.org/229281] seen with 2.3.3, works with 2.2.3 and 2.1.3 (after fixing the 2.1 incompatibilities). The pyexpat code used is the one direct from the distribution, no external library. The attached testcase demonstrates a bug in, apparently, /usr/lib/python2.3/lib-dynload/pyexpat.so. Here's the bug in gdb: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 28350)] 0x40566800 in XmlInitUnknownEncodingNS () from /usr/lib/python2.3/lib-dynload/pyexpat.so To try it youself, run "make" in the testcase directory. I apoligise for the size of this testcase; I would have whitteled it down to something simpler, but I am not a python programmer. I also apoligise if the bug is really in some library that python uses; I only went back as far as pyexpat.so. Some developers on IRC feel this may be exploitable. Talk with Scott James Remnant <[EMAIL PROTECTED]>, who also has some idea of the encoding problems in the rss file that are causing the crash. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-07-29 10:51 Message: Logged In: YES user_id=849994 Doesn't occur in 2.3.5, 2.4 head and SVN head. The patch doesn't apply to expat 2.0 anymore. => Closing. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-30 05:14 Message: Logged In: YES user_id=33168 Martin, this seems to work in Python 2.3.4, 2.4.2 and CVS. Has it been fixed and can it be closed? -- Comment By: Martin v. Löwis (loewis) Date: 2004-04-20 19:44 Message: Logged In: YES user_id=21627 The parser crashes because it invokes GetBuffer inside Parser, when Python is providing the next chunk of input, which reallocs the buffer to a different location. However, eventPtr is not updated inside GetBuffer (and neither is positionPtr). As a result, the next access to eventPtr (in XML_GetCurrentLineNumber, invoked from set_error), will cause a segfault. It is not clear to me why these pointers are not adjusted when the buffer is reallocated. However, a consistent fix appears to be to update the eventPtr close to the place where positionPtr is initialized, which is done in the attached patch exp.diff, which fixes this test case. Fred, can you please review this patch? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=883495&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1529157 ] readline module description should mention raw_input()
Bugs item #1529157, was opened at 2006-07-26 14:13 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529157&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Thom Harp (thomharp) >Assigned to: A.M. Kuchling (akuchling) Summary: readline module description should mention raw_input() Initial Comment: The description of the readline module in the library reference should mention that it alters the behavior of the input() and raw_input() functions. Without this change, it isn't obvious how to use readline to provide a command line in applications. The information requested *is* in the docs where input() and raw_input() are described, but an inexperienced python programmer, just learning his way around the standard library, won't know that and may conclude that the readline module exists only because it's used for interactive python. -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-07-29 10:25 Message: Logged In: YES user_id=11375 I've added a mention to the first paragraph of the module's docs. Thanks for the suggestion! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529157&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1519571 ] turtle.py Docs still incomplete
Bugs item #1519571, was opened at 2006-07-09 10:49 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519571&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Lingl (gregorlingl) >Assigned to: A.M. Kuchling (akuchling) Summary: turtle.py Docs still incomplete Initial Comment: There are three functions in turtle.py (which do not occur as methods of Pen), which are still not documented: setup() title() done() Regards, Gregor -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519571&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1519571 ] turtle.py Docs still incomplete
Bugs item #1519571, was opened at 2006-07-09 10:49 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519571&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Lingl (gregorlingl) Assigned to: A.M. Kuchling (akuchling) Summary: turtle.py Docs still incomplete Initial Comment: There are three functions in turtle.py (which do not occur as methods of Pen), which are still not documented: setup() title() done() Regards, Gregor -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-07-29 10:46 Message: Logged In: YES user_id=11375 I've added documentation for these methods in rev. 50932. Thanks for pointing out the omission! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519571&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1414697 ] inconsistency in help(set)
Bugs item #1414697, was opened at 2006-01-25 10:43 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1414697&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gregory Petrosyan (gregory_p) Assigned to: Raymond Hettinger (rhettinger) Summary: inconsistency in help(set) Initial Comment: >>> help(set) Help on class set in module __builtin__: class set(object) | set(iterable) --> set object | | Build an unordered collection. | | Methods defined here: | ... It would be better for docstring to be """Build an unordered collection with no duplicate elements.""" instead of """Build an unordered collection.""" -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-07-29 11:12 Message: Logged In: YES user_id=11375 Thanks for your suggestion; I've added 'unordered collection of unique elements' in rev. 50934. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1414697&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1530382 ] ssl object documentation lacks a couple of methods
Bugs item #1530382, was opened at 2006-07-28 09:20 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530382&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Lawrence Oluyede (rhymes) >Assigned to: A.M. Kuchling (akuchling) Summary: ssl object documentation lacks a couple of methods Initial Comment: According to http://docs.python.org/dev/lib/ssl-objects.html the SSL Objects expose only write() and read() but they also expose issuer() and server() methods. See Modueles/_ssl.c from line 557 to 565 -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-07-29 11:35 Message: Logged In: YES user_id=11375 I've documented these methods in rev. 50935. Thanks for pointing out this omission! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530382&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1504456 ] xmlcore needs to be documented
Bugs item #1504456, was opened at 2006-06-11 15:50 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504456&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Rejected Priority: 6 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: xmlcore needs to be documented Initial Comment: The change from the "xml" package to the "xmlcore" package needs to be documented for Python 2.5. -- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-07-29 11:41 Message: Logged In: YES user_id=3066 The switch from "xml" to "xmlcore" is being revoked; this no longer applies. -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-07-17 01:48 Message: Logged In: YES user_id=3066 I've added a brief mention of the xmlcore package in the chapter intro. Each module reference section needs to have something added still. -- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-20 09:20 Message: Logged In: YES user_id=11375 I've added this to rev. 47044 of the "What's New". -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504456&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1528258 ] urllib2 data argument
Bugs item #1528258, was opened at 2006-07-25 05:13 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528258&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: paul rubin (phr) >Assigned to: A.M. Kuchling (akuchling) Summary: urllib2 data argument Initial Comment: urllib2.Request takes constructor args (url, data, headers, ...) where data and headers are optional. data is described as a string which, if supplied, causes urlopen to process the request as a POST rather than a GET. And there's no way to set headers without passing a value for data. So if you want to send a GET with special headers, the docs leave you scratching your head. The solution is to pass None instead of a string for data. The doc should say that. In general the urllib2 docs are somewhat dependent on the urllib docs. Some refactoring would be good. -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-07-29 12:13 Message: Logged In: YES user_id=11375 I've added None as a value for 'data in rev. 50939. Thanks for pointing this out! -- Comment By: paul rubin (phr) Date: 2006-07-25 05:13 Message: Logged In: YES user_id=72053 Forgot to mention, this is Python 2.4.1. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528258&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1513611 ] xml.sax.ParseException weirdness in python 2.5b1
Bugs item #1513611, was opened at 2006-06-27 17:06
Message generated for change (Comment added) made by fdrake
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513611&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 9
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.sax.ParseException weirdness in python 2.5b1
Initial Comment:
There is something weird going on with xml.sax
exceptions, probably related to the xml/xmlcore shuffle:
from xml.sax import make_parser, SAXParseException
from StringIO import StringIO
parser = make_parser()
try:
parser.parse(StringIO('invalid'))
except SAXParseException:
print 'caught it!'
On python 2.4.3 this prints "caught it!". On python
2.5b1 the exception is not caught, because it is a
different exception: an
xmlcore.sax._exceptions.SAXParseException. Printing the
SAXParseException imported from xml.sax gives "".
Stumbled on this running the logilab-common (see
logilab.org) tests with python 2.5b1, but it seems
likely other code will be affected.
--
>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-29 13:04
Message:
Logged In: YES
user_id=3066
The xmlcore package has been reverted as of revision 50941.
This problem report no longer applies, but a test has been
added as part of the removal of the xmlcore package to
ensure this does not re-surface.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 23:31
Message:
Logged In: YES
user_id=33168
I think Martin is of the same opinion. This needs to be
resolved soon.
--
Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-26 23:03
Message:
Logged In: YES
user_id=3066
I've managed to come up with a patch that solves this
specific issue, but it really deals with the symptom and not
the real problems.
While I think the "xmlcore" package was the right idea, I'm
not convinced it can be correctly implemented without
enormous effort at this time. Given the release schedule,
it doesn't make sense to jump through those hoops. The
previous hackery that made allowed the PyXML distribution to
"replace" the standard library version of the "xml" package
worked only because there was only one public name for
whichever was being used. Moving to the "xmlcore" package
proved to be more than that hack could support.
I think the right thing to do for Python 2.5 is to revert
the changes that added the "xmlcore" package. Further
investigation into a better approach can be made for Python 2.6.
--
Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-26 22:36
Message:
Logged In: YES
user_id=3066
The patch attached contains the wrong bug number, but it
really is for this issue.
--
Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-26 22:01
Message:
Logged In: YES
user_id=3066
Patch #1519796 does not do anything for this, based on the
current trunk. I've attached a diff containing a test case.
--
Comment By: iga Seilnacht (zseil)
Date: 2006-07-10 03:37
Message:
Logged In: YES
user_id=1326842
This bug is simmilar to http://python.org/sf/1511497.
It is caused by absolute imports in xmlcore.sax.expatreader.
Patch #1519796 ( http://python.org/sf/1519796 )
should fix it.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513611&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1511497 ] xml.sax.expatreader is missing
Bugs item #1511497, was opened at 2006-06-23 14:14 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511497&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 9 Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: xml.sax.expatreader is missing Initial Comment: Hi, when testing the new Python 2.5 subversion tree I encountered this behaviour: $ python2.5 Python 2.5b1 (trunk:47065, Jun 22 2006, 20:56:23) [GCC 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import xml.sax.expatreader >>> print xml.sax.expatreader Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'expatreader' >>> So the import went ok, but using the attribute gave an error. This is very strange. Python 2.4 did not have this behaviour. -- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-07-29 13:07 Message: Logged In: YES user_id=3066 The xmlcore package has been renamed back to the original xml as of revision 50941. A test for this condition has been added as part of that change. -- Comment By: iga Seilnacht (zseil) Date: 2006-07-10 03:38 Message: Logged In: YES user_id=1326842 See patch #1519796: http://python.org/sf/1519796 -- Comment By: iga Seilnacht (zseil) Date: 2006-06-26 18:52 Message: Logged In: YES user_id=1326842 I see the same behaviour with the official Python 2.5 beta 1 Windows installer. The interesting thing is that the expatreader module is present in sys.modules: Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33) [MSC v.1310 32 bit (Intel)] on win32 ... >>> import xml.sax.expatreader >>> xml.sax.expatreader Traceback (most recent call last): ... AttributeError: 'module' object has no attribute 'expatreader' >>> import sys >>> sys.modules['xml.sax.expatreader'] All of the other modules in xml package can be imported without any trouble. I don't understand what is the real problem here, but it goes away if you import xmlcore.sax package before expatreader: [restart python] >>> import xmlcore.sax >>> import xml.sax.expatreader >>> xml.sax.expatreader The simplest fix would be to use at least one absolute import in ...\lib\xmlcore\sax\__init__.py, for example you could change line 22: from xmlreader import InputSource to: from xmlcore.sax.xmlreader import InputSource but that might just hide the real bug. -- Comment By: Wummel (calvin) Date: 2006-06-26 14:15 Message: Logged In: YES user_id=9205 I built Python directly from the SVN trunk repository with $ ./configure && make altinstall I attached the pyconfig.h that was generated. If you need more info, feel free to ask. After building and installing, I started up python2.5 and executed "import xml.sax.expatreader" and then "print xml.sax.expatreader", and nothing else. Another thing I tried is "import from", which works. But importing xml.sax.expatreader directly, as noted above, does not work. Here is the log with the "import from" test: Python 2.5b1 (trunk:47090, Jun 25 2006, 09:59:02) [GCC 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from xml.sax import expatreader >>> print expatreader >>> print xml.sax.expatreader Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'expatreader' -- Comment By: Martin v. Löwis (loewis) Date: 2006-06-24 06:39 Message: Logged In: YES user_id=21627 How precisely did you test it? What configure options did you set up, what commands did you provide to build Python? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1511497&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1476845 ] Finish PEP 343 terminology cleanup
Bugs item #1476845, was opened at 2006-04-26 07:57 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476845&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nick Coghlan (ncoghlan) Summary: Finish PEP 343 terminology cleanup Initial Comment: test_with.py was missed in the PEP 343 terminology cleanup for Python alpha 2 PEP 343 itself still needs to be updated, too. Creating this tracker item to record items needed to finish the terminology cleanup post-alpha 2. -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-07-29 13:13 Message: Logged In: YES user_id=11375 Nick, does anything still need to be done for this? What terminology needs to be fixed in test_with.py? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476845&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1465014 ] CSV regression in 2.5a1: multi-line cells
Bugs item #1465014, was opened at 2006-04-05 11:14 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: Rejected Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Skip Montanaro (montanaro) Summary: CSV regression in 2.5a1: multi-line cells Initial Comment: Running the attached csv_test.py under Python 2.4.2 (Windows XP SP1) produces: >c:\apps\python24\python.exe ./csv_test.py ['one', '2', 'three (line 1)\n(line 2)'] Note that the third item in the row contains a newline between "(line 1)" and "(line 2)". With Python 2.5a1, I get: >c:\apps\python25\python.exe ./csv_test.py ['one', '2', 'three (line 1)(line 2)'] Notice the missing newline, which is significant. The CSV module under 2.5a1 seems to lose data. -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-07-29 13:24 Message: Logged In: YES user_id=11375 I looked at this bug report, but I have no idea of exactly what behaviour has changed or what needs to be described. -- Comment By: Andrew McNamara (andrewmcnamara) Date: 2006-06-22 23:34 Message: Logged In: YES user_id=698599 Yep, your point about adding a comment to the documentation is fair. Skip, do you want to take my words and massage them into a form suitable for the docs? -- Comment By: David Goodger (goodger) Date: 2006-06-22 23:13 Message: Logged In: YES user_id=7733 I didn't realize that the previous behavior was buggy; I thought that the current behavior was a side-effect. The 2.5 behavior did cause a small problem in Docutils, but it's already been fixed. I just wanted to ensure that no regression was creeping in to 2.5. Thanks for the explanation! Perhaps it could be added to the docs in some form? Marking the bug report closed. -- Comment By: Andrew McNamara (andrewmcnamara) Date: 2006-06-22 20:27 Message: Logged In: YES user_id=698599 The previous behaviour caused considerable problems, particularly on platforms that did not use the unix line- ending conventions, or with files that originated on those platforms - users were finding mysterious newlines where they didn't expect them. Quoted fields exist to allow characters that would otherwise be considered part of the syntax to appear within the field. So yes, quoted fields are a special case, and necessarily so. The current behaviour puts the control back in the hands of the user of the module: if literal newlines are important within a field, they need to read their file in a way that preserves the newlines. The old behaviour would introduce spurious characters into quoted fields, with no way for the user to control that behaviour. I'm sorry that the change causes you problems. With a format that's as loosely defined as CSV, it's an unfortunate fact of life that there are going to be conflicting requirements. -- Comment By: David Goodger (goodger) Date: 2006-06-22 14:17 Message: Logged In: YES user_id=7733 I see what you're saying, but I disagree. In Python 2.4, csv.reader did not require newlines, but in Python 2.5 it does. That's a significant behavioral change. In the stdlib csv "Module Contents" docs for csv.reader, it says: "csvfile can be any object which supports the iterator protocol and returns a string each time its next method is called." It doesn't mention newline-terminated strings. In any case, the behavior is inconsistent: newlines are not required to terminate row-ending strings, but only strings which end inside cells split across rows. Why the discrepancy? -- Comment By: Andrew McNamara (andrewmcnamara) Date: 2006-06-20 19:17 Message: Logged In: YES user_id=698599 I think your problem is with str.splitlines(), rather than the csv.reader: splitlines ate the newline. If you pass it True as an argument, it will retain the end-of-line character in the resulting strings. -- Comment By: David Goodger (goodger) Date: 2006-05-02 17:04 Message: Logged In: YES user_id=7733 Assigned to Andrew McNamara, since his change appears to have caused this regression (revision 38290 on Modules/_csv.c). -- Comment By: David Goodger (goodger) Date: 2006-05-02 16:58 Me
[ python-Bugs-1429053 ] set documentation deficiencies
Bugs item #1429053, was opened at 2006-02-10 07:07 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1429053&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Keith Briggs (kbriggs) >Assigned to: A.M. Kuchling (akuchling) Summary: set documentation deficiencies Initial Comment: http://www.python.org/doc/current/lib/types-set.html has a dead link: "Module sets". Also, there does not seem to be any documentation on how to construct a set. Does set()==set([])? What is allowed as an argument to set()? Any iterable? -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-07-29 13:27 Message: Logged In: YES user_id=11375 This bug seems to be fixed; closing. -- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-13 14:29 Message: Logged In: YES user_id=1188172 The new location of the devel docs is http://docs.python.org/dev. -- Comment By: Keith Briggs (kbriggs) Date: 2006-02-13 07:12 Message: Logged In: YES user_id=888261 Where is it fixed? I see all the same problems at http://www.python.org/dev/doc/devel/lib/types-set.html. -- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-10 11:21 Message: Logged In: YES user_id=1188172 This is all already corrected, except for the empty set thing. -- Comment By: Keith Briggs (kbriggs) Date: 2006-02-10 10:53 Message: Logged In: YES user_id=888261 Furthermore, the operations update etc. are mutations of s, so wouldn't the definitions s.update(t) s |= t return set s with elements added from t s.intersection_update(t)s &= t return set s keeping only elements also found in t s.difference_update(t) s -= t return set s after removing elements found in t s.symmetric_difference_update(t)s ^= t return set s with elements from s or t but not both be better as s.update(t) s |= t add elements from t to s etc.? I'm not sure what the word "return" is doing here. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1429053&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1530959 ] distutils doesn't notice --with-pydebug
Bugs item #1530959, was opened at 2006-07-29 13:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530959&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: distutils doesn't notice --with-pydebug Initial Comment: As it stands (as of r50921), building a C extension module first with a debug build of Python (built with --with-pydebug), then with a regular Python build (without --with-pydebug) does not cause distutils to recompile the extension module as it should. This leads to undefined symbol errors at runtime when the module is loaded. The attached patch against Lib/distutils/command/build.py causes distutils.command.build to append '-pydebug' to the platform-specific directory name (e.g., 'linux-i686-2.5') if Python was compiled with --with-pydebug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530959&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1531003 ] __weaklist__ in typeobject.c
Bugs item #1531003, was opened at 2006-07-29 15:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531003&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Nobody/Anonymous (nobody) Summary: __weaklist__ in typeobject.c Initial Comment: typeobject.c:subtype_getweakref mentions __weaklist__ in an exception message that looks like it should refer to __weakref__. This exists in both 2.4 and the trunk. Fixing this should be just a matter of changing the message text; I don't see any other references to __weaklist__. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531003&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1193966 ] Weakref types documentation bugs
Bugs item #1193966, was opened at 2005-05-02 14:31 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193966&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Weakref types documentation bugs Initial Comment: This page (section 3.3.3 of the library reference manual): http://www.python.org/doc/current/lib/weakref-extension.html#weakref-extension contains a description of what you need to do to make your extension types weakrefable. There are a few problems with this page. First, it really belongs in the C API and/or extending and embedding documentation, not in the library reference manual. Second, the page describes having to set Py_TPFLAGS_HAVE_WEAKREFS in tp_flags, but that's unnecessary because Py_TPFLAGS_HAVE_WEAKREFS is already in Py_TPFLAGS_DEFAULT. -- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-07-29 16:05 Message: Logged In: YES user_id=3066 Fixed in revision 50952. The referenced section has been moved to the Extending & Embedding manual. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193966&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1465014 ] CSV regression in 2.5a1: multi-line cells
Bugs item #1465014, was opened at 2006-04-05 10:14 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Pending >Resolution: Fixed Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Skip Montanaro (montanaro) Summary: CSV regression in 2.5a1: multi-line cells Initial Comment: Running the attached csv_test.py under Python 2.4.2 (Windows XP SP1) produces: >c:\apps\python24\python.exe ./csv_test.py ['one', '2', 'three (line 1)\n(line 2)'] Note that the third item in the row contains a newline between "(line 1)" and "(line 2)". With Python 2.5a1, I get: >c:\apps\python25\python.exe ./csv_test.py ['one', '2', 'three (line 1)(line 2)'] Notice the missing newline, which is significant. The CSV module under 2.5a1 seems to lose data. -- >Comment By: Skip Montanaro (montanaro) Date: 2006-07-29 15:07 Message: Logged In: YES user_id=44345 I checked in a change to libcsv.tex (revision 50953). It adds a versionchanged bit to the reader doc that explains why the behavior changed in 2.5. Andrew & Andrew, please check my work. Sorry for the delay taking care of this. Skip -- Comment By: A.M. Kuchling (akuchling) Date: 2006-07-29 12:24 Message: Logged In: YES user_id=11375 I looked at this bug report, but I have no idea of exactly what behaviour has changed or what needs to be described. -- Comment By: Andrew McNamara (andrewmcnamara) Date: 2006-06-22 22:34 Message: Logged In: YES user_id=698599 Yep, your point about adding a comment to the documentation is fair. Skip, do you want to take my words and massage them into a form suitable for the docs? -- Comment By: David Goodger (goodger) Date: 2006-06-22 22:13 Message: Logged In: YES user_id=7733 I didn't realize that the previous behavior was buggy; I thought that the current behavior was a side-effect. The 2.5 behavior did cause a small problem in Docutils, but it's already been fixed. I just wanted to ensure that no regression was creeping in to 2.5. Thanks for the explanation! Perhaps it could be added to the docs in some form? Marking the bug report closed. -- Comment By: Andrew McNamara (andrewmcnamara) Date: 2006-06-22 19:27 Message: Logged In: YES user_id=698599 The previous behaviour caused considerable problems, particularly on platforms that did not use the unix line- ending conventions, or with files that originated on those platforms - users were finding mysterious newlines where they didn't expect them. Quoted fields exist to allow characters that would otherwise be considered part of the syntax to appear within the field. So yes, quoted fields are a special case, and necessarily so. The current behaviour puts the control back in the hands of the user of the module: if literal newlines are important within a field, they need to read their file in a way that preserves the newlines. The old behaviour would introduce spurious characters into quoted fields, with no way for the user to control that behaviour. I'm sorry that the change causes you problems. With a format that's as loosely defined as CSV, it's an unfortunate fact of life that there are going to be conflicting requirements. -- Comment By: David Goodger (goodger) Date: 2006-06-22 13:17 Message: Logged In: YES user_id=7733 I see what you're saying, but I disagree. In Python 2.4, csv.reader did not require newlines, but in Python 2.5 it does. That's a significant behavioral change. In the stdlib csv "Module Contents" docs for csv.reader, it says: "csvfile can be any object which supports the iterator protocol and returns a string each time its next method is called." It doesn't mention newline-terminated strings. In any case, the behavior is inconsistent: newlines are not required to terminate row-ending strings, but only strings which end inside cells split across rows. Why the discrepancy? -- Comment By: Andrew McNamara (andrewmcnamara) Date: 2006-06-20 18:17 Message: Logged In: YES user_id=698599 I think your problem is with str.splitlines(), rather than the csv.reader: splitlines ate the newline. If you pass it True as an argument, it will retain the end-of-line character in the resulting strings. -
[ python-Bugs-960860 ] botched html for index subheadings
Bugs item #960860, was opened at 2004-05-26 10:17 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=960860&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: botched html for index subheadings Initial Comment: In the index, if a topic has subtopics, it should be listed as """ topic subtopic1 subtopic2 """ In some cases (such as the reference manual entries for module, or object(continued)), it is correct. In other cases (such as the entries for name, or the first column of object), the "..." wrapper is left out, so that the subentries appear to be normal entries that just happen to be out of alphabetical order. -- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-07-29 16:15 Message: Logged In: YES user_id=3066 This appears to be fine in the 2.4.3 and development versions of the documentation. If I'm missing something, please be specific about what you think is wrong. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=960860&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1531016 ] Comman not allowed at the end of argument list for **argumen
Bugs item #1531016, was opened at 2006-07-29 20:21
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531016&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Roman Suzi (rnd0110)
Assigned to: Nobody/Anonymous (nobody)
Summary: Comman not allowed at the end of argument list for **argumen
Initial Comment:
This tells it all:
>>> str('sdfd', **a,)
File "", line 1
str('sdfd', **a,)
^
SyntaxError: invalid syntax
>>> str('sdfd', *a,)
File "", line 1
str('sdfd', *a,)
^
SyntaxError: invalid syntax
While the docs tell otherwise:
http://docs.python.org/ref/calls.html
While having arguments after ** doesn't make sense,
comma after ANY kinds of arguments seem to be more
consistent.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531016&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1531016 ] Comma not allowed at the end of argument list for **argument
Bugs item #1531016, was opened at 2006-07-29 20:21
Message generated for change (Settings changed) made by rnd0110
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531016&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 2
Submitted By: Roman Suzi (rnd0110)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Comma not allowed at the end of argument list for **argument
Initial Comment:
This tells it all:
>>> str('sdfd', **a,)
File "", line 1
str('sdfd', **a,)
^
SyntaxError: invalid syntax
>>> str('sdfd', *a,)
File "", line 1
str('sdfd', *a,)
^
SyntaxError: invalid syntax
While the docs tell otherwise:
http://docs.python.org/ref/calls.html
While having arguments after ** doesn't make sense,
comma after ANY kinds of arguments seem to be more
consistent.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531016&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1163367 ] correct/clarify documentation for super
Bugs item #1163367, was opened at 2005-03-14 18:39
Message generated for change (Comment added) made by fdrake
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: correct/clarify documentation for super
Initial Comment:
The current documentation for super is confusing. For
instance, it says that it returns "the superclass of
type" which is incorrect; it actually returns the next
type in type's MRO. Well, to be truthful, it doesn't
even do that; it returns a proxy object which makes
that type's attributes available, but that's just
another reason to fix the documentation.
I suggest changing the wording to something like:
"""super(type[, object-or-type])
Return an object that exposes the attributes available
through the type's superclasses, without exposing the
attributes of the type itself. Attributes will be
looked up using the normal resolution order, omitting
the first class in the MRO (that is, the type itself).
If the second argument is present, it should either be
an instance of object, in which case
isinstance(object-or-type, type) must be true, or it
should be an instance of type, in which case
issubclass(object-or-type, type) must be true. The
typical use for this form of super is to call a
cooperative superclass method:
class C(B):
def meth(self, arg):
super(C, self).meth(arg)
If the second argument to super is omitted, the super
object returned will not expose any attributes
directly. However, attributes will be accessible
whenever the descriptor machinery is invoked, e.g.
though explicit invocation of __get__.
Note that super is undefined for implicit lookups using
statements or operators such as "super(C, self)[name]".
These must be spelled out with their explicit lookup,
e.g. "super(C, self).__getitem__(name)". New in version
2.2.
"""
It's not perfect and I welcome suggestions for
re-wording, but I think it's substantially more
accurate about what super actually does. It also moves
the "second argument omitted" situation to the end,
since this is a vastly more uncommon use case.
--
>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-29 16:40
Message:
Logged In: YES
user_id=3066
I'm not sure what the paragraph following the \end{verbatim}
means. Can someone clarify?
--
Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-20 12:06
Message:
Logged In: YES
user_id=1188172
See also Bug #973579 (which I closed as duplicate) for
alternative wording.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-960860 ] botched html for index subheadings
Bugs item #960860, was opened at 2004-05-26 14:17 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=960860&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Pending Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: botched html for index subheadings Initial Comment: In the index, if a topic has subtopics, it should be listed as """ topic subtopic1 subtopic2 """ In some cases (such as the reference manual entries for module, or object(continued)), it is correct. In other cases (such as the entries for name, or the first column of object), the "..." wrapper is left out, so that the subentries appear to be normal entries that just happen to be out of alphabetical order. -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-07-29 20:15 Message: Logged In: YES user_id=3066 This appears to be fine in the 2.4.3 and development versions of the documentation. If I'm missing something, please be specific about what you think is wrong. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=960860&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1495229 ] W3C <-> Python DOM type mapping docs need updating
Bugs item #1495229, was opened at 2006-05-25 19:33 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495229&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Martin v. Löwis (loewis) Summary: W3C <-> Python DOM type mapping docs need updating Initial Comment: I believe the information at http://docs.python.org/lib/dom-type-mapping.html is outdated; most if not all boolean return values, at least in minidom, are handled as BooleanType, not IntegerType. This should be standard. Sorry, I don't have a patch to submit for this. Should be an easy fix though. -- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-07-30 00:56 Message: Logged In: YES user_id=3066 My position on this is that: 1) The docs are not wrong. 2) The docs should be updated to indicate that bool values are returned where appropriate. 3) It is reasonable that Python developers know the relationship between bool and int. That is not something that can reasonably change in Python 2.x. It seems unlikely to change for Python 3000. 4) The strict application of the IDL mapping really hasn't helped in creating a good DOM-like interface for Python. Dealing with the last item isn't within scope for handling this issue. -- Comment By: Mike Brown (mike_j_brown) Date: 2006-06-03 17:01 Message: Logged In: YES user_id=371366 If answer #1 is chosen and the others rejected, then the docs remain misleading, since the average reader just wants to know what types to expect from an implementation (or should code into their implementation), and shouldn't be expected to know the relationship between Booleans and integers. Is it even reasonable to expect that this relationship will always be true? In any case, I'd rather see it made explicit as to why minidom doesn't seem, at first, to respect the type mapping, at least in current implementations. It could be as simple as adding Andrew's comment, phrased as "This DOM mapping is derived from the IDL mapping for Python, which predates the introduction of BooleanType, which is currently a subtype of IntegerType. Implementations may use either type." or some such. -- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-03 16:42 Message: Logged In: YES user_id=11375 Martin, you probably need to make a pronouncement on this. The DOM mapping is supposed to be derived from the IDL mapping for Python, which predates Booleans, but methods such as hasChildNodes() return True/False. I can see at least three answers: 1) Booleans are subtypes of integers, so the docs are not wrong. 2) The docs are wrong and should say Boolean. 3) The methods should be returning regular 0 and 1, not True and False, and should be changed. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495229&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
