[ python-Bugs-1472084 ] sgmllib do_tag description error
Bugs item #1472084, was opened at 2006-04-17 23:52 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472084&group_id=5470 Please note that this 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: James G. sack (jim) (jgsack) >Assigned to: A.M. Kuchling (akuchling) Summary: sgmllib do_tag description error Initial Comment: section 13.2 sgmllib -- Simple SGML parser do_tag(attributes) This method is called to process an opening tag that does not come with a matching closing tag... (that's incorrect) It should say something like This method is called to process an opening tag (only) if there is no corresponding start_tag function defined. -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-06-03 14:10 Message: Logged In: YES user_id=11375 Fixed on both the 2.4-maint branch and the trunk; thanks for the correction. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472084&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1489648 ] time module missing from global mod index
Bugs item #1489648, was opened at 2006-05-16 11:49 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489648&group_id=5470 Please note that this 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: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: time module missing from global mod index Initial Comment: The time module is not listed in the latest dev global module index: http://docs.python.org/dev/modindex.html Skip -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-06-03 14:24 Message: Logged In: YES user_id=11375 Closing this bug, then; it's a website issue, not a Python one. I've informed Neal Norwitz, who seems to be responsible for the dev. docs. -- Comment By: Skip Montanaro (montanaro) Date: 2006-05-24 23:10 Message: Logged In: YES user_id=44345 Okay, I'll open a ticket for the website and refer to this ticket. Skip -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-05-24 22:57 Message: Logged In: YES user_id=3066 Skip, I don't know how to make the update. When I build the docs on my machine, the "time" module link is included in the global module index. -- Comment By: Skip Montanaro (montanaro) Date: 2006-05-24 22:34 Message: Logged In: YES user_id=44345 I'm not sure what's to reproduce. I just observed that the dev version of the module index is missing the time module, at least when viewed from my Mac using Safari or Firefox. Does updating the dev docs restore it? Skip -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-05-24 21:51 Message: Logged In: YES user_id=3066 I can't reproduce this, even after doing a "make clobber" in the Doc/ directory. Was there anything weird about the environment? Windows/Cygwin? -- Comment By: George Yoshida (quiver) Date: 2006-05-16 14:44 Message: Logged In: YES user_id=671362 Same as bug #1109523 I can't reproduce this in my local environment but Fred should know the reason. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1489648&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1475554 ] Poorly worded description for socket.makefile()
Bugs item #1475554, was opened at 2006-04-24 10:19 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475554&group_id=5470 Please note that this 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: 3 Submitted By: Roy Smith (roysmith) >Assigned to: A.M. Kuchling (akuchling) Summary: Poorly worded description for socket.makefile() Initial Comment: On the "7.2.1 Socket Objects" page, under makefile(), it says "The socket should be in blocking mode". If I understand it correctly, it MUST be in blocking mode. "Must" implies a mandatory requirement, "should" implies a suggestion of the best way to do something. This comment applies to many places in the Python docs. There should be a comprehensive review of all the docs to clarify "should" vs. "must" usage. -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-06-03 14:34 Message: Logged In: YES user_id=11375 I've corrected the text for makefile() on the 2.4-maint and trunk branches. Thanks for the report! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475554&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1441864 ] Omission in docs for urllib2.urlopen()
Bugs item #1441864, was opened at 2006-03-02 11:44 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441864&group_id=5470 Please note that this 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: Kent Johnson (kjohnson) >Assigned to: A.M. Kuchling (akuchling) Summary: Omission in docs for urllib2.urlopen() Initial Comment: The docs for urllib2.urlopen() don't explicitly say that if the data parameter is provided then it will do a POST. I suggest replacing the second paragraph (beginning with "data should be a string") with this text: In HTTP requests, the optional data argument may be given to specify a POST request (normally the request type is GET). The data argument must be in standard application/x-www-form-urlencoded format, for example one returned from urllib.urlencode(). Kent -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-06-03 14:47 Message: Logged In: YES user_id=11375 I've used a modified version of your clarification. Thanks for the suggestion. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441864&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1464056 ] curses library in python 2.4.3 broken
Bugs item #1464056, was opened at 2006-04-04 04:47 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: nomind (vnainar) >Assigned to: A.M. Kuchling (akuchling) Summary: curses library in python 2.4.3 broken Initial Comment: My python programs using curses library do not work with version 2.4.3.Even the 'ncurses.py ' demo program in the Demo/curses directory does not work correctly. The problem seems to be in the 'panels' library -- Comment By: Paul Smedley (psmedley) Date: 2006-05-21 10:38 Message: Logged In: YES user_id=1359962 I have a similar problem on OS/2. When running any script that uses curses I get: [U:\dev\Python-2.4.3\PC\os2emx]python test_curses.py Traceback (most recent call last): File "test_curses.py", line 242, in ? curses.wrapper(main) File "U:/DEV/PYTHON-2.4.3/Lib/curses/wrapper.py", line 49, in wrapper curses.nocbreak() _curses.error: nocbreak() returned ERR If I remove the reference to nocbreak() from wrapper.py, I get the same error but in endwin(), removing endwin() from wrapper.py, I get an error in cbreak(), removing cbreak() then some scripts work. For example, from the demo folder, all work exceptlife.py & xmas.py, which both return an error "_curses.error: nocbreak() returned ERR" on various line numbers. Seems certain curses functions are working correctly, others aren't. The patch in this bug does NOT make any difference here. -- Comment By: Jan Palus (atler_) Date: 2006-04-17 14:50 Message: Logged In: YES user_id=1497957 /me confirms -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-15 11:30 Message: Logged In: YES user_id=21627 Good spotting! Can everybody please confirm that the attached patch fixes the problem? -- Comment By: Jan Palus (atler_) Date: 2006-04-15 10:48 Message: Logged In: YES user_id=1497957 Half day of debugging and it seems that I found an answer... just by accident ;). When curses module is linked against ncursesw it seems that it also should be linked against panelw not plain panel. After changing this in setup.py, ncurses.py demo finally runs fine. -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-15 03:05 Message: Logged In: YES user_id=21627 I couldn't reproduce the problem on a Linux console (although my console had a different size); so it remains unreproducable for me. -- Comment By: nomind (vnainar) Date: 2006-04-13 07:00 Message: Logged In: YES user_id=1493752 Well , it is the linux console (in VGA mode ). The local is en_US.The size of the console is 100X37. -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-11 01:32 Message: Logged In: YES user_id=21627 Ah, ok. vnainar, atler_: What terminal had you been using to make it crash? What is your locale? Any other conditions that might be relevant (e.g. dimension of the terminal)? -- Comment By: nomind (vnainar) Date: 2006-04-11 01:13 Message: Logged In: YES user_id=1493752 Removing 'ncursesw' (there are two references to it in 'setup.py') seems to solve the problem. I noticed one more oddity. Even before the above recompilation , it ran fine on an Xterm ! -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-10 18:28 Message: Logged In: YES user_id=21627 That's hard to tell. Somebody would have to debug ncurses to find out why it crashes. Notice that it crashes only on some installations, so it is likely rather a problem with your ncurses installation, than with Python (or even with ncurses itself). -- Comment By: Jan Palus (atler_) Date: 2006-04-10 17:24 Message: Logged In: YES user_id=1497957 loewis: removing lines refering to ncursesw solves the problem. ncurses.py runs fine as well as other programs. What is actual problem then? Something with ncursesw or with python? Anyway, Thanks for your help. -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-09 16:58 Message: Logged In: YES
[ python-Bugs-1500167 ] interpret termination, object deleting
Bugs item #1500167, was opened at 2006-06-03 20:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1500167&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jan Martinek (johnymart) Assigned to: Nobody/Anonymous (nobody) Summary: interpret termination, object deleting Initial Comment: Hello, I found out a strange behavior. This code #!/usr/bin/python class M: b = 0 def __del__(self): M.b = 0 a1 = M() results in exception when the program terminates. Exception exceptions.AttributeError: "'NoneType' object has no attribute 'b'" in > ignored Note that the code must be run from an executable file -not from the python interpretter. Otherwise the exception is not thrown. An interesting thing is that changing the last line to a = M() also prevents python from throwing the exception. Why does it depend on variable's name? bye Jan Martinek -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1500167&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1497414 ] __self reserved WATCOM 10.6 word
Bugs item #1497414, was opened at 2006-05-30 05:29 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497414&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: kbob_ru (kbob_ru) Assigned to: Nobody/Anonymous (nobody) Summary: __self reserved WATCOM 10.6 word Initial Comment: same as bug 1412837, but for Modules/_tkinter.c -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-06-03 15:03 Message: Logged In: YES user_id=11375 Fix committed to the trunk in rev. 46619. I'll wait for the buildbots to complete before applying to 2.4-maint. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497414&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1500179 ] re.escape incorrectly escape literal.
Bugs item #1500179, was opened at 2006-06-03 21:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1500179&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Regular Expressions
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Baptiste Lepilleur (blep)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: re.escape incorrectly escape literal.
Initial Comment:
Using Python 2.4.2.
Here is a small programm excerpt that reproduce the
issue (attached):
---
import re
literal = r'E:\prg\vc'
print 'Expected:', literal
print 'Actual:', re.sub('a', re.escape(literal), 'a' )
assert re.sub('a', re.escape(literal), 'a' ) == literal
---
And the output of the sample:
---
Expected: E:\prg\vc
Actual : E\:\prg\vc
Traceback (most recent call last):
File "re_escape_bug.py", line 5, in ?
assert re.sub('a', re.escape(literal), 'a' ) == literal
AssertionError
---
Looking at regular expression syntax of python
documentation I don't see why ':' is escaped as '\:'.
Baptiste.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1500179&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1488934 ] file.write + closed pipe = no error
Bugs item #1488934, was opened at 2006-05-15 12:10
Message generated for change (Comment added) made by akuchling
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488934&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Demaine (edemaine)
Assigned to: Nobody/Anonymous (nobody)
Summary: file.write + closed pipe = no error
Initial Comment:
I am writing a Python script on Linux that gets called
via ssh (ssh hostname script.py) and I would like it to
know when its stdout gets closed because the ssh
connection gets killed. I assumed that it would
suffice to write to stdout, and that I would get an
error if stdout was no longer connected to anything.
This is not the case, however. I believe it is because
of incorrect error checking in Objects/fileobject.c's
file_write.
Consider this example:
while True:
__print 'Hello'
__time.sleep (1)
If this program is run via ssh and then the ssh
connection dies, the program continues running forever
(or at least, over 10 hours). No exceptions are thrown.
In contrast, this example does die as soon as the ssh
connection dies (within one second):
while True:
__os.write (1, 'Hello')
__time.sleep (1)
I claim that this is because os.write does proper error
checking, but file.write seems not to. I was surprised
to find this intricacy in fwrite(). Consider the
attached C program, test.c. (Warning: If you run it,
it will create a file /tmp/hello, and it will keep
running until you kill it.) While the ssh connection
remains open, fwrite() reports a length of 6 bytes
written, ferror() reports no error, and errno remains
0. Once the ssh connection dies, fwrite() still
reports a length of 6 bytes written (surprise!), but
ferror(stdout) reports an error, and errno changes to 5
(EIO). So apparently one cannot tell from the return
value of fwrite() alone whether the write actually
succeeded; it seems necessary to call ferror() to
determine whether the write caused an error.
I think the only change necessary is on line 2443 of
file_write() in Objects/fileobject.c (in svn version
46003):
2441n2 = fwrite(s, 1, n, f->f_fp);
2442Py_END_ALLOW_THREADS
2443if (n2 != n) {
2444PyErr_SetFromErrno(PyExc_IOError);
2445clearerr(f->f_fp);
I am not totally sure whether the "n2 != n" condition
should be changed to "n2 != n || ferror (f->f_fp)" or
simply "ferror (f->f_fp)", but I believe that the
condition should be changed to one of these
possibilities. The current behavior is wrong.
Incidentally, you'll notice that the C code has to turn
off signal SIGPIPE (like Python does) in order to not
die right away. However, I could not get Python to die
by re-enabling SIGPIPE. I tried "signal.signal
(signal.SIGPIPE, signal.SIG_DFL)" and "signal.signal
(signal.SIGPIPE, lambda x, y: sys.exit ())" and neither
one caused death of the script when the ssh connection
died. Perhaps I'm not using the signal module correctly?
I am on Linux 2.6.11 on a two-CPU Intel Pentium 4, and
I am running the latest Subversion version of Python,
but my guess is that this error transcends most if not
all versions of Python.
--
>Comment By: A.M. Kuchling (akuchling)
Date: 2006-06-03 16:16
Message:
Logged In: YES
user_id=11375
I agree with your analysis, and think your suggested fixes are correct.
However, I'm unable to construct a small test case that exercises this bug. I
can't even replicate the problem with SSH; when I run a remote script with
SSH and then kill SSH with Ctrl-C, the write() gets a -1. Are you terminating
SSH in some other way? (I'd really like to have a test case for this problem
before committing the fix.)
--
Comment By: Erik Demaine (edemaine)
Date: 2006-05-15 12:26
Message:
Logged In: YES
user_id=265183
One more thing: fwrite() is used in a couple of other
places, and I think the same comment applies to them. They are:
- file_writelines() in Objects/fileobject.c
- w_string() in Python/marshal.c doesn't seem to have any
error checking? (At least no ferror() call in marhsal.c...)
- string_print() in Objects/stringobject.c doesn't seem to
have any error checking (but I'm not quite sure what this
means in Python land).
- flush_data() in Modules/_hotshot.c
- array_tofile() in Modules/arraymodule.c
- write_file() in Modules/cPickle.c
- putshort(), putlong(), writeheader(), writetab() [and the
functions that call them] in Modules/rgbimgmodule.c
- svc_writefile() in Modules/svmodule.c
--
You can respond by visiting:
https://sourceforge.net/t
[ python-Bugs-1500179 ] re.escape incorrectly escape literal.
Bugs item #1500179, was opened at 2006-06-03 15:32
Message generated for change (Comment added) made by akuchling
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1500179&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Regular Expressions
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Baptiste Lepilleur (blep)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: re.escape incorrectly escape literal.
Initial Comment:
Using Python 2.4.2.
Here is a small programm excerpt that reproduce the
issue (attached):
---
import re
literal = r'E:\prg\vc'
print 'Expected:', literal
print 'Actual:', re.sub('a', re.escape(literal), 'a' )
assert re.sub('a', re.escape(literal), 'a' ) == literal
---
And the output of the sample:
---
Expected: E:\prg\vc
Actual : E\:\prg\vc
Traceback (most recent call last):
File "re_escape_bug.py", line 5, in ?
assert re.sub('a', re.escape(literal), 'a' ) == literal
AssertionError
---
Looking at regular expression syntax of python
documentation I don't see why ':' is escaped as '\:'.
Baptiste.
--
>Comment By: A.M. Kuchling (akuchling)
Date: 2006-06-03 16:27
Message:
Logged In: YES
user_id=11375
The assertion is wrong, I think. The signature is re.sub(pattern,
replacement,
string), so the assertion is replacing 'a' with re.escape(literal), which is
obviously not going to equal literal.
re.escape() puts a backslash in front of all non-alphanumeric characters; ':'
is
non-alphanumeric, so it will be escaped. The regex parser will ignore
unknown escapes, so \: is the same as : -- the redundant escaping is
harmless.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1500179&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1498146 ] optparse does not hande unicode help strings
Bugs item #1498146, was opened at 2006-05-31 07:52 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1498146&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tom Cato Amundsen (tomcato) >Assigned to: Greg Ward (gward) Summary: optparse does not hande unicode help strings Initial Comment: Unicode strings with non-ascii chars in generate a UnicodeEncodeError File "/usr/lib/python2.3/optparse.py", line 1370, in print_help file.write(self.format_help()) UnicodeEncodeError: 'ascii' codec can't encode characters in position 200-202: +ordinal not in range(128) I'm subclassing OptionParser and adds the following method to get it to work. Should something like this be done for python 2.5? def print_help(self, file=None): if file is None: file = sys.stdout file.write(self.format_help().encode(file.encoding, 'replace')) Tom Cato -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1498146&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1497414 ] __self reserved WATCOM 10.6 word
Bugs item #1497414, was opened at 2006-05-30 05:29 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497414&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Tkinter Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: kbob_ru (kbob_ru) >Assigned to: A.M. Kuchling (akuchling) Summary: __self reserved WATCOM 10.6 word Initial Comment: same as bug 1412837, but for Modules/_tkinter.c -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-06-03 16:35 Message: Logged In: YES user_id=11375 The buildbots seemed to still compile _tkinter.c, so I've applied the change to the release24-maint branch in rev. 46620 and will now close this bug. Thanks for reporting this problem! -- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-03 15:03 Message: Logged In: YES user_id=11375 Fix committed to the trunk in rev. 46619. I'll wait for the buildbots to complete before applying to 2.4-maint. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497414&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 (Settings changed) made by akuchling 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: 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
[ python-Bugs-1495229 ] W3C <-> Python DOM type mapping docs need updating
Bugs item #1495229, was opened at 2006-05-25 16:33 Message generated for change (Comment added) made by mike_j_brown 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: Mike Brown (mike_j_brown) Date: 2006-06-03 14: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 13: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
[ python-Bugs-1500179 ] re.escape incorrectly escape literal.
Bugs item #1500179, was opened at 2006-06-03 21:32
Message generated for change (Settings changed) made by blep
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1500179&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Regular Expressions
Group: Python 2.4
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Baptiste Lepilleur (blep)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: re.escape incorrectly escape literal.
Initial Comment:
Using Python 2.4.2.
Here is a small programm excerpt that reproduce the
issue (attached):
---
import re
literal = r'E:\prg\vc'
print 'Expected:', literal
print 'Actual:', re.sub('a', re.escape(literal), 'a' )
assert re.sub('a', re.escape(literal), 'a' ) == literal
---
And the output of the sample:
---
Expected: E:\prg\vc
Actual : E\:\prg\vc
Traceback (most recent call last):
File "re_escape_bug.py", line 5, in ?
assert re.sub('a', re.escape(literal), 'a' ) == literal
AssertionError
---
Looking at regular expression syntax of python
documentation I don't see why ':' is escaped as '\:'.
Baptiste.
--
>Comment By: Baptiste Lepilleur (blep)
Date: 2006-06-03 23:45
Message:
Logged In: YES
user_id=196852
You are correct. Though, the 'repl' string parameter is not
a literal string and is interpreted. The correct escape
function to preserve the literal is
literal.replace('\\','') not re.escape(). It would
preserve any interpretation of the repl pattern. I believe
this fact should be clearly stated in the documentation as
it is not that obvious.
The following assertion pass:
---
import re
literal = r'e:\prg\vc\1'
assert re.sub( '(a+)',
literal.replace('\\',''),
'aabac' ) == (literal+'b'+literal+'c')
---
In the above example neither \v nor \1 are interpreted.
Regards,
Baptiste.
--
Comment By: A.M. Kuchling (akuchling)
Date: 2006-06-03 22:27
Message:
Logged In: YES
user_id=11375
The assertion is wrong, I think. The signature is re.sub(pattern,
replacement,
string), so the assertion is replacing 'a' with re.escape(literal), which is
obviously not going to equal literal.
re.escape() puts a backslash in front of all non-alphanumeric characters; ':'
is
non-alphanumeric, so it will be escaped. The regex parser will ignore
unknown escapes, so \: is the same as : -- the redundant escaping is
harmless.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1500179&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1500293 ] Memory leak in subprocess module
Bugs item #1500293, was opened at 2006-06-04 05:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1500293&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leak in subprocess module Initial Comment: The memory leak is in _subprocess module in functions getint and gethandle. They forget to decref the objects returned by PyObject_GetAttrString(). The bug is present in version 2.4 as well as in the trunk. Few more bugs in the subprocess module that I found while looking for the leak: - class STARTUPINFO is missing a wShowWindow attribute (this is hidden because _subprocess.CreateProcess() ignores most of the exceptions) - _execute_child() had a nonsensical test (if not None in tuple_of_posible_file_handles) - _execute_child() is assigning attributes to a default_startupinfo, which isn't used if user supplies another one. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1500293&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1500293 ] Memory leak in subprocess module
Bugs item #1500293, was opened at 2006-06-04 12:30 Message generated for change (Settings changed) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1500293&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: iga Seilnacht (zseil) >Assigned to: Peter à strand (astrand) Summary: Memory leak in subprocess module Initial Comment: The memory leak is in _subprocess module in functions getint and gethandle. They forget to decref the objects returned by PyObject_GetAttrString(). The bug is present in version 2.4 as well as in the trunk. Few more bugs in the subprocess module that I found while looking for the leak: - class STARTUPINFO is missing a wShowWindow attribute (this is hidden because _subprocess.CreateProcess() ignores most of the exceptions) - _execute_child() had a nonsensical test (if not None in tuple_of_posible_file_handles) - _execute_child() is assigning attributes to a default_startupinfo, which isn't used if user supplies another one. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1500293&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
