[issue4195] Regression for executing packages
Nick Coghlan [EMAIL PROTECTED] added the comment: Added revised version of patch with test cases and documentation updates, as well as fixing a potential recursion issue with pathological packages where __main__ was also a package) -- keywords: +patch Added file: http://bugs.python.org/file11885/issue4195_runpy_package_support.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4195 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4194] Miserable subprocess.Popen performance
Winfried Plappert [EMAIL PROTECTED] added the comment: Hi is the dramatic difference on Solaris-10 / Python2.6: I dtraced the popentest.py and counted syscalls: with os_popen: read =243 with process:Popen read = 589018 That explains a lot! The rest of the system calls are similir in count and appearance. I have not looked into the C-source (yet). ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4194 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2275] urllib2 header capitalization
John J Lee [EMAIL PROTECTED] added the comment: I have attached a patch that just: * Improves doctests a bit * Changes .get_headers() and .has_header() to be case-insensitive * Documents .get_header() and .header_items(), fixes some incorrectly-documented argument names, and notes the case-sensitivity change * Note that the headers passed to httplib (the original issue for which this bug was raised) were already correctly Title-Cased, and that is unchanged by this patch Options: * Apply my patch. I'd be happy with this. * Apply my patch and begin the process of deprecating public interfaces .unredirected_hdrs and .headers. Perhaps provide another interface to tell whether a header will be redirected (only if there's a use case for that). I'd be happy with this too. * Bring back Senthil's case-normalized .headers and .unredirected_hdrs and document those interfaces. This a bad idea, because this would result in a very confusing set of interfaces for dealing with headers (see my previous comments on this -- Date: 2008-07-11 19:44). (For what it's worth, I have also attached a doctest to show some examples of the broken invariants issue with Senthil's patch. The doctest also comments on the fact that making .headers case-insensitive in this way is quite confusing in the case where multiple items of different case are present, but __getitem__ returns only a single item -- this is a relatively minor issue, but still worth avoiding. The variation of choosing to discard items that normalize to the same string would avoid this problem, though it might break working code that relies on sending multiple headers with differing case, so I think this would be no better overall.) Added file: http://bugs.python.org/file11886/issue2775.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2275 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2275] urllib2 header capitalization
Changes by John J Lee [EMAIL PROTECTED]: Added file: http://bugs.python.org/file11887/issue2775-problems.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2275 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2756] urllib2 add_header fails with existing unredirected_header
John J Lee [EMAIL PROTECTED] added the comment: I agree there is a bug here: clearly the methods on the Request class are inconsistent with AbstractHTTPHandler.do_open() . I think Facundo's patch is good, though it needs a test. The general principle when fixing earlier bugs has been that the .add_*header() methods override default headers, though there are some reasonable violations this where the implementation relies on specific headers being sent -- e.g. Connection: close. -- nosy: +jjlee ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2756 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4194] Miserable subprocess.Popen performance
Winfried Plappert [EMAIL PROTECTED] added the comment: The created testfile size is 588890 bytes, which implies that subprocess.Popen reads the file in completely unbuffered mode, one byte at a time. If I modify the popentest.py programme by specifying a bufsize of 1_000_000, the execution time drops quite a bit: time with os.popen 0.069 sec time with subprocess.Popen 0.118 sec This Solaris 9/Python 2.6. I think I have got it: Lib/subprocess.py should have a default bufsize of -1, not 0! I tested it by modifying the subprocess.Popen call and here is the result: time with os.popen 0.086 sec time with subprocess.Popen 0.080 sec See also Modules/posixmodule.c. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4194 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4194] Miserable subprocess.Popen performance
Skip Montanaro [EMAIL PROTECTED] added the comment: Using a nonzero bufsize parameter makes all the difference in the world: Using the default (bufsize=0 == unbuffered): % python popentest.py time with os.popen : 0.035032 time with subprocess.Popen : 1.496455 Creating the Popen object with bufsize=8192: % python popentest.py time with os.popen : 0.034642 time with subprocess.Popen : 0.041376 Creating the Popen object with bufsize=1 (== line buffered): % python popentest.py time with os.popen : 0.034658 time with subprocess.Popen : 0.04211 Maybe the default for that parameter shouldn't be zero? Skip ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4194 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4194] Miserable subprocess.Popen performance
Skip Montanaro [EMAIL PROTECTED] added the comment: Using a nonzero bufsize parameter makes all the difference in the world: ... In fact, looking at posix_popen in posixmodule.c it appears the default value for bufsize there is -1, implying that I/O is fully buffered. Even if the default bufsize value for subprocess.Popen is not changed its documentation should be corrected to reflect the different default values for bufsize between os.popen and subprocess.Popen: Replacing os.popen* --- pipe = os.popen(cmd, mode='r', [bufsize]) == pipe = Popen(cmd, shell=True, bufsize=bufsize, stdout=PIPE).stdout If you use the default bufsize with os.popen you must set bufsize to -1 when creating a Popen object. Otherwise your I/O will be unbuffered and you will be disappointed at the I/O performance. -- assignee: - georg.brandl components: +Documentation, Library (Lib) nosy: +georg.brandl versions: +Python 2.7, Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4194 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4203] adapt sphinx-quickstart for windows
New submission from Tim Michelsen [EMAIL PROTECTED]: Hello, for users on the windows platform, it could be of great help if the sphinx-quickstart would be adjuste to their platform. Here are my suggestions: * create a batch file instead of the Makefile * make-docs.bat, contents: sphinx-build -a source build * use _ as default suggestion for the dotfiles. Thanks for your great tool! -- assignee: georg.brandl components: Documentation tools (Sphinx) messages: 75212 nosy: georg.brandl, timmie severity: normal status: open title: adapt sphinx-quickstart for windows ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4203 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4203] adapt sphinx-quickstart for windows
Changes by Tim Michelsen [EMAIL PROTECTED]: -- type: - feature request ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4203 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3924] cookielib chokes on non-integer cookie version, should ignore it instead
John J Lee [EMAIL PROTECTED] added the comment: Patch with tests attached. The patch is slightly different to my first suggestion: in the patch, invalid version values cause the cookie to be ignored (but double quotes around valid versions are fine). -- keywords: +patch Added file: http://bugs.python.org/file11888/issue3924.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3924 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3924] cookielib chokes on non-integer cookie version, should ignore it instead
John J Lee [EMAIL PROTECTED] added the comment: The bug is present on trunk and on the py3k branch, so I've selected versions Python 2.7 and Python 3.0 This is a straightforward bug, so I selected 2.5.3 and 2.6 also, to indicate this is a candidate for backport. -- components: +Library (Lib) -None type: crash - behavior versions: +Python 2.5.3, Python 2.6, Python 2.7, Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3924 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4204] Cannot build _multiprocessing, math, mmap and readline of Python 2.6 on FreeBSD 4.11 w/ gcc 2.95.4
New submission from Akira Kitada [EMAIL PROTECTED]: I was trying to build Python 2.6 on FreeBSD 4.11 and found it failed to build some of the modules. Failed to find the necessary bits to build these modules: _bsddb _sqlite3 _tkinter gdbm linuxaudiodev spwd sunaudiodev To find the necessary bits, look in setup.py in detect_modules() for the module's name. Failed to build these modules: _multiprocessing math mmap readline Because I don't have Berkeley DB, SQLite3 tk, GDBM installed on the system and running FreeBSD, there is no wonder it failed to build _bsddb, _sqlite3, _tkinter, gdbm, linuxaudiodev, spwd and sunaudiodev. The problem is it failed to build _multiprocessing, math, mmap and readline. Here are the outputs of each build failure. building '_multiprocessing' extension creating build/temp.freebsd-4.11-RELEASE-i386-2.6/usr/home/build/dev/Python-2.6/Modules/_multiprocessing gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DHAVE_SEM_OPEN=1 -DHAVE_FD_TRANSFER=1 -DHAVE_SEM_TIMEDWAIT=1 -IModules/_multiprocessing -I. -I/usr/home/build/dev/Python-2.6/./ Include -I. -IInclude -I./Include -I/usr/local/include -I/usr/home/build/dev/Python-2.6/Include -I/usr/home/build/dev/Python-2.6 -c /usr/home/build/dev/Python-2.6/Modules/_multiprocessing/multiprocessing.c -o b uild/temp.freebsd-4.11-RELEASE-i386-2.6/usr/home/build/dev/Python-2.6/Modules/_multiprocessing/multiprocessing.o In file included from /usr/home/build/dev/Python-2.6/Modules/_multiprocessing/multiprocessing.h:24, from /usr/home/build/dev/Python-2.6/Modules/_multiprocessing/multiprocessing.c:9: /usr/include/arpa/inet.h:89: warning: parameter has incomplete type /usr/include/arpa/inet.h:92: warning: parameter has incomplete type /usr/include/arpa/inet.h:96: warning: parameter has incomplete type /usr/home/build/dev/Python-2.6/Modules/_multiprocessing/multiprocessing.c: In function `multiprocessing_sendfd': /usr/home/build/dev/Python-2.6/Modules/_multiprocessing/multiprocessing.c:102: storage size of `dummy_iov' isn't known /usr/home/build/dev/Python-2.6/Modules/_multiprocessing/multiprocessing.c:102: warning: unused variable `dummy_iov' /usr/home/build/dev/Python-2.6/Modules/_multiprocessing/multiprocessing.c: In function `multiprocessing_recvfd': /usr/home/build/dev/Python-2.6/Modules/_multiprocessing/multiprocessing.c:137: storage size of `dummy_iov' isn't known /usr/home/build/dev/Python-2.6/Modules/_multiprocessing/multiprocessing.c:137: warning: unused variable `dummy_iov' building 'cmath' extension gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/usr/home/build/dev/Python-2.6/./Include -I. -IInclude -I./Include -I/usr/local/include -I/usr/home/build/dev/Python-2.6/I nclude -I/usr/home/build/dev/Python-2.6 -c /usr/home/build/dev/Python-2.6/Modules/cmathmodule.c -o build/temp.freebsd-4.11-RELEASE-i386-2.6/usr/home/build/dev/Python-2.6/Modules/cmathmodule.o /usr/home/build/dev/Python-2.6/Modules/cmathmodule.c: In function `special_type': /usr/home/build/dev/Python-2.6/Modules/cmathmodule.c:79: warning: implicit declaration of function `copysign' /usr/home/build/dev/Python-2.6/Modules/cmathmodule.c: In function `c_acos': /usr/home/build/dev/Python-2.6/Modules/cmathmodule.c:152: warning: implicit declaration of function `asinh' /usr/home/build/dev/Python-2.6/Modules/cmathmodule.c: In function `c_atanh': /usr/home/build/dev/Python-2.6/Modules/cmathmodule.c:345: warning: implicit declaration of function `log1p' gcc -shared build/temp.freebsd-4.11-RELEASE-i386-2.6/usr/home/build/dev/Python-2.6/Modules/cmathmodule.o -L/usr/local/lib -lm -o build/lib.freebsd-4.11-RELEASE-i386-2.6/cmath.so building 'math' extension gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/usr/home/build/dev/Python-2.6/./Include -I. -IInclude -I./Include -I/usr/local/include -I/usr/home/build/dev/Python-2.6/I nclude -I/usr/home/build/dev/Python-2.6 -c /usr/home/build/dev/Python-2.6/Modules/mathmodule.c -o build/temp.freebsd-4.11-RELEASE-i386-2.6/usr/home/build/dev/Python-2.6/Modules/mathmodule.o /usr/home/build/dev/Python-2.6/Modules/mathmodule.c: In function `m_atan2': /usr/home/build/dev/Python-2.6/Modules/mathmodule.c:118: warning: implicit declaration of function `copysign' /usr/home/build/dev/Python-2.6/Modules/mathmodule.c: In function `math_acosh': /usr/home/build/dev/Python-2.6/Modules/mathmodule.c:272: `acosh' undeclared (first use in this function) /usr/home/build/dev/Python-2.6/Modules/mathmodule.c:272: (Each undeclared identifier is reported only once /usr/home/build/dev/Python-2.6/Modules/mathmodule.c:272: for each function it appears in.) /usr/home/build/dev/Python-2.6/Modules/mathmodule.c: In function `math_asinh': /usr/home/build/dev/Python-2.6/Modules/mathmodule.c:276: `asinh' undeclared (first use in this function)
[issue4194] Miserable subprocess.Popen performance
Changes by Giampaolo Rodola' [EMAIL PROTECTED]: -- nosy: +giampaolo.rodola ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4194 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4204] Cannot build _multiprocessing, math, mmap and readline of Python 2.6 on FreeBSD 4.11 w/ gcc 2.95.4
Martin v. Löwis [EMAIL PROTECTED] added the comment: Even if a certain platform is supported, you can't infer that all modules will build on it. Can you propose a patch? -- nosy: +loewis ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4204 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3876] multiprocessing does not compile on systems which do not define sem_timedwait
Piotr Meyer [EMAIL PROTECTED] added the comment: I confirm build failure on NetBSD 4.0.1 (latest stable) - but NetBSD-current is - probably - also affected: *** WARNING: renaming _multiprocessing since importing it failed: build/lib.netbsd-4.0.1-i386-2.6/_multiprocessing.so: Undefined PLT symbol sem_timedwait (symnum = 20) system: NetBSD 4.0.1 (i386) Python version: 2.6 -- nosy: +aniou ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3876 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4194] Miserable subprocess.Popen performance
Skip Montanaro [EMAIL PROTECTED] added the comment: I've been thinking about it, and I think even though it would be a slight change to the API, I agree with Winfried that the default value for bufsize should be -1, not 0. In my own use of os.popen and friends, almost all the time I use them to process the output of a traditional Unix pipeline, which means the output will be plain text, line buffered. In those cases it makes absolutely no sense to read from the pipe one character at a time. S ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4194 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4194] Miserable subprocess.Popen performance
Winfried Plappert [EMAIL PROTECTED] added the comment: On the other hand, we will silently break all those applications which are out there relying on the fact that a pipe is an unbuffered device. You might consider it for Python 3.0, but I don't know if it is a good idea for Python 2.x. The documentation of subprocess.Popen clear states that the default is unbuffered, bufsize=0. I quote from http://docs.python.org/library/subprocess.html: bufsize, if given, has the same meaning as the corresponding argument to the built-in open() function: 0 means unbuffered, 1 means line buffered, any other positive value means use a buffer of (approximately) that size. A negative bufsize means to use the system default, which usually means fully buffered. The default value for bufsize is 0 (unbuffered). ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4194 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4205] unexpected str.__init__() behaviour on b''
New submission from Eric Devolder [EMAIL PROTECTED]: creating a unicode string from an empty b'' does not result in '', but produces b'' instead. str(b'') b'' Workaround: if the encoding is specified, the resulting string is fine. str(b'', 'ascii') '' -- components: Interpreter Core, Unicode messages: 75220 nosy: keldonin severity: normal status: open title: unexpected str.__init__() behaviour on b'' type: behavior versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4205 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4205] unexpected str.__init__() behaviour on b''
Benjamin Peterson [EMAIL PROTECTED] added the comment: This is expected. There is no bytes.__str__ method, so the bytes.__repr__ is used. -- nosy: +benjamin.peterson resolution: - invalid status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4205 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4205] unexpected str.__init__() behaviour on b''
Eric Devolder [EMAIL PROTECTED] added the comment: Thanks for the tip - and sorry about the noise. I didn't catch this when reading through PEPs manual, however. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4205 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4206] multiprocessing docs
New submission from David W. Lambert [EMAIL PROTECTED]: http://docs.python.org/dev/3.0/library/multiprocessing.html map(func, iterable[, chunksize]) A parallel equivalent of the map() builtin function. It blocks till the result is ready. Not really, __builtins__.map returns a mapping object, Pool().map returns...a list? print(multiprocessing.Pool().map.__doc__) # rather lame doc string! Equivalent of `map()` builtin -- assignee: georg.brandl components: Documentation messages: 75223 nosy: LambertDW, georg.brandl severity: normal status: open title: multiprocessing docs versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4206 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
