[issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Changes by Paweł Widera mo...@man.poznan.pl: -- nosy: +momat ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue670664 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6137] Make pickle generated by Python 3.x compatible with 2.x and vice-versa.
Hagen Fürstenau hfuerste...@gmx.net added the comment: The latest patch is missing the file Lib/_compat.pickle.py. (Seems as if you forgot to svn add it after patching.) -- nosy: +hagen ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6137 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Paweł Widera mo...@man.poznan.pl added the comment:
A simple workaround for the BeautifulSoup is the following wrapper. It
sanitize the javascript code before passing it to the parser by joining
the disjoint strings, so that /scr+ipt becomes /script.
def bs(input):
pattern = re.compile('\\+\')
match = lambda x:
massage = copy.copy(BeautifulSoup.MARKUP_MASSAGE)
massage.extend([(pattern, match)])
return BeautifulSoup(input, markupMassage=massage)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue670664
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6136] Make logging configuration files easier to use
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: Re point a) and opening files - why not use the delay parameter on FileHandlers, which delays opening until a message is actually logged? I can understand why one wouldn't want empty log files cluttering up the place, but the same argument doesn't apply to sockets. If you don't want an always-open connection, you could also use UDP. While the delay parameter takes care of files, why does it matter so much about sockets? Is it actually causing a practical problem, or does it just offend your aesthetic sensibilities? If you submit a patch for fileConfig that only created handlers that were used by at least one logger, I would certainly look at it - I have both accepted and rejected numerous patches over the years. Would your patch also consider unused formatters? As the new behaviour could conceivably create a backward-compatibility problem (some users may be relying on the current behaviour, no matter how broken it seems to you), the new behaviour should be accessible through another config setting (e.g. ignore_unused) which defaults to False (the existing behaviour) if not specified in the config file. Re point b), it only really covers the case where you have single-level loggers (qualname = word), and not actually a multi-level hierarchy (qualname = words-separated-by-dots). So I don't feel it's worth doing this, especially as there seems to be no widespread demand for this functionality. I'll mark the issue as pending for now. -- status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl
Ronald Oussoren ronaldousso...@mac.com added the comment: On 4 Jun, 2009, at 2:24, Brett Cannon wrote: Ronald, can you look at the changes I proposed on Makefile.pre.in to make sure LIBS from configure get used in the framework builds? If you do then that change with the configure.in change I suggested should solve all of this. The basic idea looks fine, I will have a more serious look later today. I'm not entirely sure of adding LIBS to the link line is 100% correct, or if it would be better to have a separate FRAMEWORKLIBS definition that only contains the files that must be linked into the framework. -- title: Python 3.1 rc1 will not build on OS X 10.5.7 withmacports libintl - Python 3.1 rc1 will not build on OS X 10.5.7with macports libintl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6154 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5648] OS X Installer: do not install obsolete documentation within Python.app bundle
Changes by Ronald Oussoren ronaldousso...@mac.com: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5648 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6191] HTMLParser attribute parsing - 2 test cases when it fails
New submission from Paweł Widera mo...@man.poznan.pl: Of course both are not correct HTML but are easy to guess, so I believe the parser should not give up too quick here. 1) extra comma between attributes form action=/xxx.php?a=1amp;b=2amp, method=post 2) missing closing quotation mark for the first attribute a href=http://xxx.org/xxx.php?a=1 target=_blankclick me/a -- components: Library (Lib) messages: 88867 nosy: momat severity: normal status: open title: HTMLParser attribute parsing - 2 test cases when it fails type: behavior versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6191 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5767] xmlrpclib loads invalid documents
Georg Brandl ge...@python.org added the comment: Applied in r73201, r73202. -- nosy: +georg.brandl resolution: - accepted status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5767 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3613] base64.encodestring does not actually accept strings
Georg Brandl ge...@python.org added the comment: Applied a patch to rename (and keep old aliases) in r73204. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3613 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3684] traceback.format_exception_only() misplaces the caret for certain SyntaxErrors
Georg Brandl ge...@python.org added the comment: Thanks, committed as r73206. -- nosy: +georg.brandl resolution: - accepted status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3684 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3791] bsddb not completely removed
Georg Brandl ge...@python.org added the comment: Removed the last traces of bsddb in r73208. -- nosy: +georg.brandl resolution: accepted - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3791 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3798] SystemExit incorrectly displays unicode message
Georg Brandl ge...@python.org added the comment: Ping? -- nosy: +georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3798 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue433028] SRE: (?flag:...) is not supported
Changes by Georg Brandl ge...@python.org: -- resolution: - duplicate status: open - closed superseder: - Major reworking of Python 2.5.2 re module ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue433028 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4186] type() doesn't accept bases and dict keyword arguments
Georg Brandl ge...@python.org added the comment: 2.6 has been released and out there some time, and there was no cry about this, so I guess this can be ignored. -- nosy: +georg.brandl resolution: - wont fix status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4186 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4199] add shorthand global and nonlocal statements
Georg Brandl ge...@python.org added the comment: Postponed to 3.2. -- nosy: +georg.brandl versions: +Python 3.2 -Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4199 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5967] PyList_GetSlice does not indicate negative ranges dont work as in python.
Georg Brandl ge...@python.org added the comment: Documented in r73213. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5967 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6176] Reference to a wrong version of flock's documentation
Georg Brandl ge...@python.org added the comment: Thanks, fixed in r73215. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6176 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6175] inet_aton documentation kind of lies
Georg Brandl ge...@python.org added the comment: Thanks, updated the docs in r73217. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6175 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6192] add disable_nagle_algorithm to SocketServer.TCPServer
New submission from Kristján Valur Jónsson krist...@ccpgames.com: It is useful to be able to disable the Nagle algoritm on socket connections from the TCPServer. These are typically used by HTTP servers. If combined with write buffering (setting RequestHangler.wbufsize = -1) it can make sure that http responses are not subject to Nagle/Delayed-ack delays. Disabling Nagle in addition to providing the buffering is necessary to make sure that the final wfile.flush() arrives promptly, in case a previous flush occurred and the final flush is small. A patch is provided. -- files: disable_nagle.patch keywords: easy, patch, patch messages: 88878 nosy: krisvale severity: normal status: open title: add disable_nagle_algorithm to SocketServer.TCPServer type: feature request versions: Python 2.7 Added file: http://bugs.python.org/file14185/disable_nagle.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6192 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6192] add disable_nagle_algorithm to SocketServer.TCPServer
Changes by Kristján Valur Jónsson krist...@ccpgames.com: -- components: +Library (Lib) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6192 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1943] improved allocation of PyUnicode objects
Marc-Andre Lemburg m...@egenix.com added the comment: Here's a new version of the unicode reference type, extended to run in both Python 2.6 and 3.1: http://downloads.egenix.com/python/unicoderef-0.0.2.tar.gz I've also included a benchmark implemented in C which measures Unicode/Bytes allocation performance at high resolution and without any VM overhead. These are the results on a 64-bit system using a regular UCS2 build of Python 2.6.1 and 3.1 on a single core AMD system: * Unicode allocation is always much slower than Bytes This depends a lot on how much data you have to handle. If the data fits into the pymalloc managed sizes, there's little difference. * CPU cache lines / memory boundaries obviously have some impact on the results If things are properly aligned, performance is better than in the unaligned case. Unfortunately, there's nothing much the CPython implementation can do to benefit from this, since the hardware layouts are too diverse. This explains why you see some unexpected figures in the results, e.g. Python 3.1, 4096 words, 32chars - Unicode being faster than Bytes. * Something must have improved in pymalloc The 4096 word tests perform better on 3.1 than on 2.6. Since such improvement have a great impact, more emphasis should be placed on these, e.g. by having pymalloc provide more space to fixed size objects such PyUnicodeObject, reducing the need to create new arenas. Dictionaries and other PyObjects such as instances objects would also benefit from such improvements. Note that the benchmark scales the bytes word sizes to match the internal allocation size of the Unicode objects, ie. 2chars maps to a length 4 bytes string on a UCS2 build. Testing Unicode/Bytes Allocation Speed with Python 3.1rc1+ === 1024 words Variant 2chars, 1024 words, Unicode: 0.005503 seconds = 0.054 us per object (best of 50 rounds) Variant 2chars, 1024 words, Bytes : 0.006838 seconds = 0.067 us per object (best of 50 rounds) Variant 9chars, 1024 words, Unicode: 0.008956 seconds = 0.087 us per object (best of 50 rounds) Variant 9chars, 1024 words, Bytes : 0.007380 seconds = 0.072 us per object (best of 50 rounds) Variant 16chars, 1024 words, Unicode: 0.009257 seconds = 0.090 us per object (best of 50 rounds) Variant 16chars, 1024 words, Bytes : 0.007291 seconds = 0.071 us per object (best of 50 rounds) Variant 32chars, 1024 words, Unicode: 0.009589 seconds = 0.094 us per object (best of 50 rounds) Variant 32chars, 1024 words, Bytes : 0.007803 seconds = 0.076 us per object (best of 50 rounds) Variant pep100, 1024 words, Unicode: 0.010569 seconds = 0.103 us per object (best of 50 rounds) Variant pep100, 1024 words, Bytes : 0.008198 seconds = 0.080 us per object (best of 50 rounds) === 2048 words Variant 2chars, 2048 words, Unicode: 0.011624 seconds = 0.057 us per object (best of 50 rounds) Variant 2chars, 2048 words, Bytes : 0.013941 seconds = 0.068 us per object (best of 50 rounds) Variant 9chars, 2048 words, Unicode: 0.018608 seconds = 0.091 us per object (best of 50 rounds) Variant 9chars, 2048 words, Bytes : 0.014773 seconds = 0.072 us per object (best of 50 rounds) Variant 16chars, 2048 words, Unicode: 0.018556 seconds = 0.091 us per object (best of 50 rounds) Variant 16chars, 2048 words, Bytes : 0.014550 seconds = 0.071 us per object (best of 50 rounds) Variant 32chars, 2048 words, Unicode: 0.018972 seconds = 0.093 us per object (best of 50 rounds) Variant 32chars, 2048 words, Bytes : 0.016377 seconds = 0.080 us per object (best of 50 rounds) Variant pep100, 2048 words, Unicode: 0.021005 seconds = 0.103 us per object (best of 50 rounds) Variant pep100, 2048 words, Bytes : 0.016636 seconds = 0.081 us per object (best of 50 rounds) === 4096 words Variant 2chars, 4096 words, Unicode: 0.022950 seconds = 0.056 us per object (best of 50 rounds) Variant 2chars, 4096 words, Bytes : 0.027813 seconds = 0.068 us per object (best of 50 rounds) Variant 9chars, 4096 words, Unicode: 0.037229 seconds = 0.091 us per object (best of 50 rounds) Variant 9chars, 4096 words, Bytes : 0.031123 seconds = 0.076 us per object (best of 50 rounds) Variant 16chars, 4096 words, Unicode: 0.037118 seconds = 0.091 us per object (best of 50 rounds) Variant 16chars, 4096 words, Bytes : 0.036433 seconds = 0.089 us per object (best of 50 rounds) Variant 32chars, 4096 words, Unicode: 0.040970 seconds = 0.100 us per object (best of 50 rounds) Variant 32chars, 4096 words, Bytes : 0.051422 seconds = 0.126 us per object (best of 50 rounds) Variant pep100, 4096 words, Unicode: 0.049630 seconds = 0.121 us per object (best of 50 rounds) Variant pep100, 4096 words, Bytes : 0.034551 seconds = 0.084 us per object (best of 50 rounds)
[issue1943] improved allocation of PyUnicode objects
Marc-Andre Lemburg m...@egenix.com added the comment: Guido van Rossum wrote: Guido van Rossum gu...@python.org added the comment: On Wed, Jun 3, 2009 at 1:41 PM, Antoine Pitrou rep...@bugs.python.org wrote: Apart from the example Marc-André just posted (and which is a 0.0.1 proof of concept he apparently just wrote), the number of users is, AFAICT, zero. IIUC Marc-Andre extracted that from a larger code base (MX) which he owns and has been maintaining for a decade or so. Only part of it. I wrote the sub-type Unicode Reference sub-type implementation just a few days ago, in order to demonstrate how easy it is provided you have a PyObject (rather than a PyVarObject) to build on. We should really publicize how easy it is to write such type extensions. I'm sure that a lot of things which often generated heated discussions (such as the slicing patches for Unicode) could easily be solved by just adding a few such sub-types to the core. Unless there's some closed source extension which happens to extend unicode as a C subtype. I believe part of MX is closed source. True. A large part of the code base is not available to the wider public. Now, as for easing the subclassing of unicode in C, there are probably several possibilities which range from devising a clever set of macros to abusing the ob_size field for a tagged pointer. People who really care should do a concrete proposal (and I don't know who these people are, apart from Marc-André). Not really if the core code uses a macro that depends on the layout of the object (i.e. the data immediately following the header, like old 8-bit strings), unless you change the core (or the macro) to only use this if the type matches exactly, and for subtypes use a more expensive API. But that would slow down unnecessarily for subclasses written in Python (of which there are plenty). But I would like to point out that few people if any have ever complained about the contiguous allocation for 8-bit strings in Python [0-2].x. And we certainly wouldn't have given in. Now that Unicode is no longer some fancy-schmancy advanced concept but the basis for *all* Python string processing I think we should apply the same policy. I've spent enough time with this discussion. If you think it's better to make sub-typing harder and thereby closing the door for improvements which could really speed up e.g. template processing (by not requiring copying the same data over and over again), go for it. I still think that it's better to keep things the way they are and benefit from the fact that PyUnicodeObjects have a fixed size with the variable part being dealt with separately. Since pymalloc is being used to manage such objects, there's a lot of room for improvements, since the allocation scheme is under out control. E.g. we could have pymalloc allocate larger pools for PyUnicodeObjects. Doing the same for variable sized objects is a lot harder, consumes more memory and likely less efficient. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1943] improved allocation of PyUnicode objects
Antoine Pitrou pit...@free.fr added the comment: Since pymalloc is being used to manage such objects, there's a lot of room for improvements, since the allocation scheme is under out control. E.g. we could have pymalloc allocate larger pools for PyUnicodeObjects. I'm not sure what larger pools for PyUnicodeObjects means. pymalloc doesn't have separate pools per object type, only per object size. OTOH, we could grow the size limit under which pymalloc is used, especially on 64-bit systems. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5611] Auto-detect indentation in C source in vimrc
Johannes Hoff johan...@johanneshoff.com added the comment:
I came across this bug while searching for autodetecting tabs/spaces.
Thanks for the help.
To address Georg's question, the patch should be modified to say
if search('^\t', 'n', 100)
instead of
if search('^\t')
The former will not move the cursor, and will only search the first 100
lines.
--
nosy: +johshoff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5611
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1943] improved allocation of PyUnicode objects
Marc-Andre Lemburg m...@egenix.com added the comment: Antoine Pitrou wrote: Antoine Pitrou pit...@free.fr added the comment: Since pymalloc is being used to manage such objects, there's a lot of room for improvements, since the allocation scheme is under out control. E.g. we could have pymalloc allocate larger pools for PyUnicodeObjects. I'm not sure what larger pools for PyUnicodeObjects means. pymalloc doesn't have separate pools per object type, only per object size. I meant larger pools for objects of sizeof(PyUnicodeObject) bytes. The same could be done for other often used PyObjects (and only for those). pymalloc is a lot faster than the OS malloc() and was designed for Python object memory management, ie. for small blocks... /* A fast, special-purpose memory allocator for small blocks, to be used on top of a general-purpose malloc -- heavily based on previous art. */ /* Vladimir Marangozov -- August 2000 */ OTOH, we could grow the size limit under which pymalloc is used, especially on 64-bit systems. The limit is 256 bytes. Increasing it doesn't make much sense, since the pools are 4k each and managed in arenas of 256kb. Anything larger than 256 bytes goes straight to the OS malloc(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3684] traceback.format_exception_only() misplaces the caret for certain SyntaxErrors
Jean-Paul Calderone exar...@divmod.com added the comment: Any plans for a unit test for this change? -- nosy: +exarkun ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3684 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1943] improved allocation of PyUnicode objects
Antoine Pitrou pit...@free.fr added the comment: Anything larger than 256 bytes goes straight to the OS malloc(). Under a 64-bit system, a plain dict is more than 256 bytes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6192] add disable_nagle_algorithm to SocketServer.TCPServer
Antoine Pitrou pit...@free.fr added the comment: Looks ok to me. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6192 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4108] robotparser.py fail when more than one User-Agent: * is present
mARK python.mblo...@xoxy.net added the comment: this looks like a good fix. i've put it into my own copy. -- nosy: +mbloore ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4108 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5798] test_asynchat fails on Mac OSX
Jean Brouwers mrje...@gmail.com added the comment: Well, with fresh build of Python 3.1rc1 on MacOS X 10.4.11 Tiger (Intel) test_asynchat.py rev 73183 still seems to fail, perhaps differently. Here is 3 different results. First, rev 73183: % ./python.exe Lib/test/test_asynchat73183.py test_close_when_done (__main__.TestAsynchat) ... ok test_empty_line (__main__.TestAsynchat) ... ok test_line_terminator1 (__main__.TestAsynchat) ... ok test_line_terminator2 (__main__.TestAsynchat) ... ok test_line_terminator3 (__main__.TestAsynchat) ... ok test_none_terminator (__main__.TestAsynchat) ... ok test_numeric_terminator1 (__main__.TestAsynchat) ... ok test_numeric_terminator2 (__main__.TestAsynchat) ... ok test_simple_producer (__main__.TestAsynchat) ... ok test_string_producer (__main__.TestAsynchat) ... ok test_close_when_done (__main__.TestAsynchat_WithPoll) ... ok test_empty_line (__main__.TestAsynchat_WithPoll) ... error: uncaptured python exception, closing channel __main__.echo_client at 0x10835b0 (class 'socket.error':[Errno 9] Bad file descriptor [../Python- 3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-3.1rc1/Lib/asyncore.py|handle_expt_event|440]) ok test_line_terminator1 (__main__.TestAsynchat_WithPoll) ... error: uncaptured python exception, closing channel __main__.echo_client at 0x1083550 (class 'socket.error':[Errno 9] Bad file descriptor [../Python- 3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-3.1rc1/Lib/asyncore.py|handle_expt_event|440]) error: uncaptured python exception, closing channel __main__.echo_client at 0x1083610 (class 'socket.error':[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Python- 3.1rc1/Lib/asyncore.py|handle_expt_event|440]) error: uncaptured python exception, closing channel __main__.echo_client at 0x10835f0 (class 'socket.error':[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Python- 3.1rc1/Lib/asyncore.py|handle_expt_event|440]) ok test_line_terminator2 (__main__.TestAsynchat_WithPoll) ... error: uncaptured python exception, closing channel __main__.echo_client at 0x1083630 (class 'socket.error':[Errno 9] Bad file descriptor [../Python- 3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-3.1rc1/Lib/asyncore.py|handle_expt_event|440]) error: uncaptured python exception, closing channel __main__.echo_client at 0x1083870 (class 'socket.error':[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Python- 3.1rc1/Lib/asyncore.py|handle_expt_event|440]) error: uncaptured python exception, closing channel __main__.echo_client at 0x10838b0 (class 'socket.error':[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Python- 3.1rc1/Lib/asyncore.py|handle_expt_event|440]) ok test_line_terminator3 (__main__.TestAsynchat_WithPoll) ... error: uncaptured python exception, closing channel __main__.echo_client at 0x1083610 (class 'socket.error':[Errno 9] Bad file descriptor [../Python- 3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-3.1rc1/Lib/asyncore.py|handle_expt_event|440]) error: uncaptured python exception, closing channel __main__.echo_client at 0x1083550 (class 'socket.error':[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Python- 3.1rc1/Lib/asyncore.py|handle_expt_event|440]) error: uncaptured python exception, closing channel __main__.echo_client at 0x10835f0 (class 'socket.error':[Errno 9] Bad file descriptor [../Python-3.1rc1/Lib/asyncore.py|readwrite|106] [../Python- 3.1rc1/Lib/asyncore.py|handle_expt_event|440]) ok test_none_terminator (__main__.TestAsynchat_WithPoll) ... error: uncaptured python exception, closing channel __main__.echo_client at 0x1083550 (class 'socket.error':[Errno 9] Bad file descriptor [../Python- 3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-3.1rc1/Lib/asyncore.py|handle_expt_event|440]) ok test_numeric_terminator1 (__main__.TestAsynchat_WithPoll) ... error: uncaptured python exception, closing channel __main__.echo_client at 0x1083630 (class 'socket.error':[Errno 9] Bad file descriptor [../Python- 3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-3.1rc1/Lib/asyncore.py|handle_expt_event|440]) ok test_numeric_terminator2 (__main__.TestAsynchat_WithPoll) ... error: uncaptured python exception, closing channel __main__.echo_client at 0x10837f0 (class 'socket.error':[Errno 9] Bad file descriptor [../Python- 3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-3.1rc1/Lib/asyncore.py|handle_expt_event|440]) ok test_simple_producer (__main__.TestAsynchat_WithPoll) ... error: uncaptured python exception, closing channel __main__.echo_client at 0x1083910 (class 'socket.error':[Errno 9] Bad file descriptor [../Python- 3.1rc1/Lib/asyncore.py|readwrite|106] [../Python-3.1rc1/Lib/asyncore.py|handle_expt_event|440]) ok test_string_producer (__main__.TestAsynchat_WithPoll) ... error: uncaptured python exception, closing channel
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl
Changes by Martin v. Löwis mar...@v.loewis.de: Removed file: http://bugs.python.org/file14183/smime.p7s ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6154 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl
Changes by Martin v. Löwis mar...@v.loewis.de: Removed file: http://bugs.python.org/file14182/smime.p7s ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6154 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl
Changes by Martin v. Löwis mar...@v.loewis.de: Removed file: http://bugs.python.org/file14181/smime.p7s ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6154 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl
Changes by Martin v. Löwis mar...@v.loewis.de: Removed file: http://bugs.python.org/file14180/smime.p7s ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6154 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5798] test_asynchat fails on Mac OSX
R. David Murray rdmur...@bitdance.com added the comment: I presume you mean a fresh build of 3.1rc1+ (from svn)? 3.1rc1 does not contain the most recent fix. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5798 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5798] test_asynchat fails on Mac OSX
Josiah Carlson josiahcarl...@users.sourceforge.net added the comment: I installed 3.1rc1 on my OS X (10.5.?) machine, updated asynchat, and ran the test with and without my change. Without my change, it breaks in the way described numerous times. With my change, it seems to work fine on OS X, linux, and Windows for me. Looking at line 106 in py3k/Lib/asyncore.py (http://svn.python.org/view/python/branches/py3k/Lib/asyncore.py? annotate=73183) gets me obj.handle_close(). Your tracebacks show line 106 calling obj.handle_expt_event(), which is the old code. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5798 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1590864] import deadlocks when using PyObjC threads
Brett Cannon br...@python.org added the comment: Been thinking about it and as a compromise to people who view this as a bug I am re-opening it but lowering the priority. -- components: +Interpreter Core -Library (Lib) priority: normal - low resolution: wont fix - stage: committed/rejected - test needed status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1590864 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl
Changes by Brett Cannon br...@python.org: -- title: Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl - Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6154 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1590864] Function-level import in os triggering an threaded import deadlock
Changes by Brett Cannon br...@python.org: -- components: +Library (Lib) -Interpreter Core title: import deadlocks when using PyObjC threads - Function-level import in os triggering an threaded import deadlock ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1590864 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6182] Remove ipaddr library from py3k before 3.1rc2
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: r73230 and r73223 -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6182 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3684] traceback.format_exception_only() misplaces the caret for certain SyntaxErrors
Georg Brandl ge...@python.org added the comment: Good point. Added a test in r73232. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3684 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6193] urllib: ... IOError: ... unknown url type: 'c'
New submission from Sridhar Ratnakumar sridh...@activestate.com:
On Windows, urllib fails to open local files:
python -c import urllib; urllib.urlopen(r'C:\test.txt').read()
Traceback (most recent call last):
File C:\HOME\as\pypm\bin\python-script.py, line 33, in module
exec _val
File string, line 1, in module
File C:\Python26\lib\urllib.py, line 87, in urlopen
return opener.open(url)
File C:\Python26\lib\urllib.py, line 200, in open
return self.open_unknown(fullurl, data)
File C:\Python26\lib\urllib.py, line 212, in open_unknown
raise IOError, ('url error', 'unknown url type', type)
IOError: [Errno url error] unknown url type: 'c'
However, on Unix this is not an issue:
$ python -c import urllib; print urllib.urlopen('/tmp/test.txt').read()
Foo
$
--
components: Library (Lib)
messages: 88894
nosy: srid
severity: normal
status: open
title: urllib: ... IOError: ... unknown url type: 'c'
type: behavior
versions: Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6193
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6193] urllib: ... IOError: ... unknown url type: 'c'
Sridhar Ratnakumar sridh...@activestate.com added the comment: This also happens on 3.1 (urllib.urlrequest) .. and I believe must also happen on 2.7 and 3.0. -- components: +Windows versions: +Python 2.7, Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6193 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6193] urllib: ... IOError: ... unknown url type: 'c'
Georg Brandl ge...@python.org added the comment: You should use file:// to open local files with urllib. -- nosy: +georg.brandl resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6193 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6193] urllib: ... IOError: ... unknown url type: 'c'
Sridhar Ratnakumar sridh...@activestate.com added the comment: Relevant discussion: http://osdir.com/ml/python.py2exe/2008-03/msg00013.html [quote]'The only thing I could think of was editing urllib.py and changing the splittype method (...)'[endquote] -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6193 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6193] urllib: ... IOError: ... unknown url type: 'c'
Sridhar Ratnakumar sridh...@activestate.com added the comment: [Brandl] You should use file:// to open local files with urllib. Hmm, that is strange. How come it works on Unix without file://? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6193 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6191] HTMLParser attribute parsing - 2 test cases when it fails
Georg Brandl ge...@python.org added the comment: I do not think HTMLParser should guess. Guessing always opens the door to misinterpretation. -- nosy: +georg.brandl resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6191 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6193] urllib: ... IOError: ... unknown url type: 'c'
R. David Murray rdmur...@bitdance.com added the comment: Because in unix the filename starts with a '/', while in windows your filename started with a 'C:'. That looks like the urltype portion of a url, and it isn't a valid one, so urllib correctly rejects it. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6193 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6137] Make pickle generated by Python 3.x compatible with 2.x and vice-versa.
Alexandre Vassalotti alexan...@peadrop.com added the comment: Oops. Here is a new patch with _compat_pickle.py. -- Added file: http://bugs.python.org/file14186/compat_pickle7.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6137 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6137] Make pickle generated by Python 3.x compatible with 2.x and vice-versa.
Antoine Pitrou pit...@free.fr added the comment: Committed in r73236 in the hope that it gets a bit more testing before rc2/final. -- assignee: alexandre.vassalotti - resolution: - fixed stage: patch review - committed/rejected status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6137 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6191] HTMLParser attribute parsing - 2 test cases when it fails
Paweł Widera mo...@man.poznan.pl added the comment: It depends whether you want a HTMLParser to be an useful tool that can deal with real world HTML or just a toy without practical meaning. Crashing on every little deviation from the standard, where more relaxed approach is possible, doesn't sound to me as a reasonable choice. Maybe guess is not a proper word... If the standard strict approach fails, the parser should fall back to a less strict one in an attempt to actually parse the document. Throwing an exception and giving up is just not good enough. Can we have somebody else commenting on this one please? -- status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6191 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6194] fcntl footnote about O_SHLOCK and O_EXLOCK is misleading
New submission from R. David Murray rdmur...@bitdance.com: At the bottom of http://docs.python.org/library/fcntl.html there is a see also section for the os module that says: If the locking flags O_SHLOCK and O_EXLOCK are present in the os module, the os.open() function provides a more platform-independent alternative to the lockf() and flock() functions. However, those flags are documented as being unix only (ie: no windows), and in fact Linux does not support them. Alan Cox rejected support for them back in 2000 according to this linux kernel posting: http://lkml.indiana.edu/hypermail/linux/kernel/0005.1/1309.html so it doesn't seem likely linux will ever support them. Thus, to say that they provide a more platform independent-alternative would appear to be false, since they appear to only be supported on BSD and derivitives. -- assignee: georg.brandl components: Documentation keywords: easy messages: 88904 nosy: georg.brandl, r.david.murray priority: low severity: normal stage: needs patch status: open title: fcntl footnote about O_SHLOCK and O_EXLOCK is misleading type: behavior versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6194 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl
Roumen Petrov bugtr...@roumenpetrov.info added the comment: The current check for *gettext/*textdomain* functions is not so correct. It mix(!?!) checks for headers with check for functions. GNU libc include them and on linux we will see in pyconfig.h (trunk): --- /* #undef WITH_LIBINTL */ #define HAVE_LIBINTL_H 1 #define HAVE_BIND_TEXTDOMAIN_CODESET 1 --- If system C library don't include them then configure check(search) in additional libraries (-lintl) but in this case bind_textdomain_codeset is not detected. As the current check is AC_CHECK_LIB(intl, textdomain, [ACTION], ... the library is not added to LIBS (see autoconf texinfo pages as reference). Another file is setup.py . Trunk version add library intl if WITH_LIBINTL is defined and on darwin adds '-framework', 'CoreFoundation' to link flags. It seems to me that patch is not so simple. May i propose following changes: - remove current check for function bind_textdomain_codeset; - remove current check for header libintl.h - replace AC_CHECK_LIB(intl, textdomain, ... with AC_SEARCH_LIBS(bindtextdomain, intl, #ACTION-IF-FOUND check for header libintl.h check for function bind_textdomain_codeset - adjust use of defines in locale module - adjust setup.py if necessary (I don't know p3k branch) In a more advanced check I won't add library intl to $LIBS. The check will be similar to the check for readline + restore of LIBS after check and I will move line for locale module from Setup.dist into Setup.config.in as example: _locale _localemodule.c @LOCALE_LIBS@ # where LOCALE_LIBS is substituted by configure script. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6154 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6191] HTMLParser attribute parsing - 2 test cases when it fails
Georg Brandl ge...@python.org added the comment: Throwing an exception and giving up is just not good enough. Yes it is, in some cases. There are forgiving HTML parsers out there, HTMLParser does not strive to be one. There are *so many* cases where HTML is a bit malformed that it takes more than just two exceptions to get it right. It's for a reason that browsers' parsers are so complex. If you add these corner cases, people will come asking for this exception, and that one, etc. -- status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6191 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6195] Serious regression in doctest in Py3.1rc1
New submission from Lisandro Dalcin dalc...@gmail.com: When doctests are written in docstrings from C extension modules, 'doctest' reads the binary extension module file. The attached one-line patch seems to fix the problem, it is in fact very similar to patch for issue4050 related to 'inspect'. -- components: Library (Lib), Tests files: doctest.diff keywords: patch messages: 88907 nosy: dalcinl, scoder severity: normal status: open title: Serious regression in doctest in Py3.1rc1 versions: Python 3.1 Added file: http://bugs.python.org/file14187/doctest.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6195 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6196] tarfile.extractall(readaccess=True)
Sridhar Ratnakumar sridh...@activestate.com added the comment: Here's a test data from PyPI: http://pypi.python.org/packages/source/g/generator_tools/generator_tools-0.3.5.tar.gz -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6196 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6191] HTMLParser attribute parsing - 2 test cases when it fails
R. David Murray rdmur...@bitdance.com added the comment: In doing web scraping I started using BeautifulSoup precisely because it was very lenient in what html it accepted (I haven't written such an ap for a while, so I'm not sure what BeautifulSoup currently does...I thought I heard it was now using HTMLParser...). There are a lot of messed up web pages out there. I don't have time right now to evaluate your particular cases, but my rule of thumb would be that if the major web browsers do something reasonable with these cases, then a python tool designed to read web pages should do so as well, where possible. (Be liberal in what you accept, and strict in what you generate.) That said, I'm not sure what HTMLParser's design goals are, so this may not be an appropriate goal for the module. -- nosy: +r.david.murray priority: - normal status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6191 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6196] tarfile.extractall(readaccess=True)
Sridhar Ratnakumar sridh...@activestate.com added the comment: Considering this bug where tarfile fails to set g+s, https://bugs.launchpad.net/pyopenssl/+bug/236190 a more general approach could be: tarfile.extractall(safe_perms=True) where if safe_perms is set, tarfile can 1) ignore +/-s on all files, 2) ignore u-x on directories and 3) ignore u-r on files. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6196 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6196] tarfile.extractall(readaccess=True)
New submission from Sridhar Ratnakumar sridh...@activestate.com: If a tarball has a-x perms set on its root directory, one cannot access its contents. $ tar zxf generator_tools-0.3.5.tar.gz. $ ls generator_tools-0.3.5/ ls: cannot access generator_tools-0.3.5/README.txt: Permission denied ... sridh...@double:/tmp/i$ This is fine for GNU tar (the user can always do a chmod +x later). But for the tarfile library, it would be better to have a flag such as readaccess=True that will force ``extractall`` to enforce *minimum* permissions required for the basic read access. This means, tarfile would ignore u-x on directories and u-r on files. The reason I make this feature request (instead of working around the issue myself in a verbose way) is that the very reason to write a program to extract tarball (instead of doing it manually) is to automate it .. which automation is more effective and simple if ``extractall`` had a flag such as readaccess=True. -- components: Library (Lib) messages: 88908 nosy: srid severity: normal status: open title: tarfile.extractall(readaccess=True) type: feature request versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6196 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6196] tarfile.extractall(readaccess=True)
R. David Murray rdmur...@bitdance.com added the comment: I don't see why the tarfile case should be different from the tar case. You can always chmod it later in python, too (with os.walk and os.chmod). Perhaps the real need is for a recursive chmod in shutil? -- nosy: +r.david.murray priority: - low ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6196 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6191] HTMLParser attribute parsing - 2 test cases when it fails
Georg Brandl ge...@python.org added the comment: So BeautifulSoup is using HTMLParser? That is interesting, because they claim to support broken HTML. In any case, if a quirky mode is added, it should have to be turned on explicitly by a flag. -- resolution: wont fix - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6191 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6127] Unexpected universal newline behavior (newline duplication) in Windows
Alexandre Vassalotti alexan...@peadrop.com added the comment: Can you check if the patch in issue #5645 fix the bug? -- nosy: +alexandre.vassalotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6127 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6196] tarfile.extractall(readaccess=True)
Sridhar Ratnakumar sridh...@activestate.com added the comment: [David] I don't see why the tarfile case should be different from the tar case. (...) As I explained, Viz: [quote]'(...)the very reason to write a program to extract tarball (instead of doing it manually) is to automate it .. which automation is *more effective and simple* if ``extractall`` had a flag such as readaccess=True'[endquote] (emphasis added) [David] You can always chmod it later in python, too (with os.walk and os.chmod). (...) Of course, I can. Or: EXECUTE = 0100 READ = 0400 dir_perm = EXECUTE file_perm = EXECUTE | READ for tarinfo in f.getmembers(): tarinfo.mode |= (dir_perm if tarinfo.isdir() else file_perm) As you can see, for a tarfile with huge list of files.. this can be a performance issue. [David] (...) Perhaps the real need is for a recursive chmod in shutil? The real need is to fix the weird permissions on some tarballs (such as generator_tools-0.3.5.tar.gz in PyPI and the above mentioned pyopenssl tarball). This need usually leads to designing workarounds. I just think it is not simple (as in, keeping the code off from such hacks that are tangential to the problem being solved) and effective (as in, not having to deal with potential unintended side effects like bugs in the post-fix chmoding or in the pre-fix tarinfo mode modifications). Hence the feature request. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6196 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6195] Serious regression in doctest in Py3.1rc1
Changes by R. David Murray rdmur...@bitdance.com: -- assignee: - r.david.murray nosy: +r.david.murray priority: - high stage: - test needed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6195 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6195] Serious regression in doctest in Py3.1rc1
R. David Murray rdmur...@bitdance.com added the comment: Here's a test case which fails with the existing code and passes with the patch applied. However, with the patch applied some of the other doctest tests fail with an off-by-one error in the source line number output. I'd like to understand that difference before committing the patch, but haven't figured it out yet. -- stage: test needed - patch review type: - behavior Added file: http://bugs.python.org/file14188/doctest-test.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6195 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6127] Unexpected universal newline behavior (newline duplication) in Windows
Jason R. Coombs jar...@jaraco.com added the comment: Indeed, that patch works. I'm attaching the same patch applicable to branches/release26-maint. -- keywords: +patch Added file: http://bugs.python.org/file14189/issue5645_release26-maint.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6127 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5645] test_memoryio fails for py3k on windows
Jason R. Coombs jar...@jaraco.com added the comment: Patch is also applicable to #6127. -- nosy: +jaraco ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5645 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6197] test__locale fails with RADIXCHAR on Windows
New submission from James Abbatiello abb...@gmail.com: regrtest.py test__locale fails with: test__locale test test__locale crashed -- type 'exceptions.ImportError': cannot import name RADIXCHAR 1 test failed: test__locale The attached patch backports the fix from issue5643 -- components: Tests, Windows files: test__locale_on_windows.patch keywords: patch messages: 88919 nosy: abbeyj, benjamin.peterson, ocean-city severity: normal status: open title: test__locale fails with RADIXCHAR on Windows versions: Python 2.7 Added file: http://bugs.python.org/file14190/test__locale_on_windows.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6197 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5798] test_asynchat fails on Mac OSX
Jean Brouwers mrje...@gmail.com added the comment: Correct. With new Lib/asyncore.py file rev 73183 all 23 tests in the original test_asynchat.py pass in Python 3.1rc1 built from source on MacOS X 10.4.11 Tiger (Intel). % ./python.exe Lib/test/test_asynchat.py test_close_when_done (__main__.TestAsynchat) ... ok test_empty_line (__main__.TestAsynchat) ... ok test_line_terminator1 (__main__.TestAsynchat) ... ok test_line_terminator2 (__main__.TestAsynchat) ... ok test_line_terminator3 (__main__.TestAsynchat) ... ok test_none_terminator (__main__.TestAsynchat) ... ok test_numeric_terminator1 (__main__.TestAsynchat) ... ok test_numeric_terminator2 (__main__.TestAsynchat) ... ok test_simple_producer (__main__.TestAsynchat) ... ok test_string_producer (__main__.TestAsynchat) ... ok test_close_when_done (__main__.TestAsynchat_WithPoll) ... ok test_empty_line (__main__.TestAsynchat_WithPoll) ... ok test_line_terminator1 (__main__.TestAsynchat_WithPoll) ... ok test_line_terminator2 (__main__.TestAsynchat_WithPoll) ... ok test_line_terminator3 (__main__.TestAsynchat_WithPoll) ... ok test_none_terminator (__main__.TestAsynchat_WithPoll) ... ok test_numeric_terminator1 (__main__.TestAsynchat_WithPoll) ... ok test_numeric_terminator2 (__main__.TestAsynchat_WithPoll) ... ok test_simple_producer (__main__.TestAsynchat_WithPoll) ... ok test_string_producer (__main__.TestAsynchat_WithPoll) ... ok test_find_prefix_at_end (__main__.TestHelperFunctions) ... ok test_basic (__main__.TestFifo) ... ok test_given_list (__main__.TestFifo) ... ok -- Ran 23 tests in 7.726s OK -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5798 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6137] Make pickle generated by Python 3.x compatible with 2.x and vice-versa.
Hagen Fürstenau hfuerste...@gmx.net added the comment: I think it is worth noting that now some Python 3.1 protocol 2 pickles can't be read by Python 3.0. We probably don't have to do anything about that, but perhaps it should be mentioned somewhere? Docs, release notes? -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6137 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6198] test_float fails on Windows
New submission from James Abbatiello abb...@gmail.com: test_float fails on Windows with: == FAIL: test_format_testfile (test.test_float.IEEEFormatTestCase) -- Traceback (most recent call last): File C:\Projects\python-trunk\lib\test\test_float.py, line 319, in test_format_testfile self.assertEqual(fmt % float(arg), rhs) AssertionError: '3' != '2' -- The problematic line from formatfloat_testcases.txt is: %.0f 2.5 - 2 On some systems *printf() uses round-to-even. But the Windows CRT uses round-half-away-from-zero. Consider the following C code: printf(%+.1f - %+.0f\n, -2.5, -2.5); printf(%+.1f - %+.0f\n, -1.5, -1.5); printf(%+.1f - %+.0f\n, +1.5, +1.5); printf(%+.1f - %+.0f\n, +2.5, +2.5); On Linux this will produce: -2.5 - -2 -1.5 - -2 +1.5 - +2 +2.5 - +2 And on Windows: -2.5 - -3 -1.5 - -2 +1.5 - +2 +2.5 - +3 -- components: Tests, Windows messages: 88922 nosy: abbeyj severity: normal status: open title: test_float fails on Windows versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6198 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
