[issue2275] urllib2 header capitalization
Changes by Senthil [EMAIL PROTECTED]: Added file: http://bugs.python.org/file11024/issue2275-py3k.diff ___ 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
Senthil [EMAIL PROTECTED] added the comment:
I am submitting a revised patch for this issue.
I did some analysis on the history of this issue and found that this
.capitalize() vs .title() changes had come up earlier too (
issue1542948)and decision was taken to:
- To retain the Header format in .capitalize() to maintain backward
compatibility.
- However, when the headers are passed to httplib, they are converted to
.title() format ( see AbstractHTTPHandler method )
- It is encouraged that users uses .add_header(), .has_header(),
.get_header() methods to check for headers instead of using the .headers
dict directly (which will still remain undocumented interface).
Note to Hans-Peter would be: Changing the headers to .title() tends to
make the .header_items() retrieval backward incompatible, so the headers
will still be stored in .capitalize() format.
And I have made the following changes to the patch:
1) Support for case insensitive dict look up which will work with for
.has_header, .get_header(). So when .has_header(User-Agent) will
return True even when .headers give {User-agent:blah}
2) Added tests to tests the behavior.
3) Changes to doc to reflect upon this issue.
Btw, the undocumented .headers interface will also support
case-insensitive lookup, so I have added tests for that too.
Let me know if you have any comments. Lets plan to close this issue.
Thanks,
___
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
[issue3482] re.split, re.sub and re.subn should support flags
New submission from Benoit Thiell [EMAIL PROTECTED]: Given that the search operations support flags, it seems natural for a developer that the other functions in the module support flags as well. So when running re.split(pattern, string, re.I), the split() command seems to not work and don't return a message error (I understand that 're.I' is understood as 'maxsplit=0'.) This is confusing and I think that it should be changed so that all functions in the module are consistent. -- messages: 70543 nosy: benoit severity: normal status: open title: re.split, re.sub and re.subn should support flags ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3482 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3482] re.split, re.sub and re.subn should support flags
Changes by Benoit Thiell [EMAIL PROTECTED]: -- components: +Regular Expressions type: - behavior ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3482 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3392] subprocess fails in select when descriptors are large
Changes by David Kågedal [EMAIL PROTECTED]: -- nosy: +d_kagedal ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3392 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3436] csv.DictReader inconsistency
Andrii V. Mishkovskyi [EMAIL PROTECTED] added the comment: Oh, so this is how the process looks like... /me removes patches I've uploaded both py3k and trunk patches just because I'm fixing things the other way round -- first I write a patch for 3.0 and only after that I backport it to 2.6. Stupid me. :) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3436 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3436] csv.DictReader inconsistency
Changes by Andrii V. Mishkovskyi [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file11016/issue3436.py3k.csv.py.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3436 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3436] csv.DictReader inconsistency
Changes by Andrii V. Mishkovskyi [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file11017/issue3436.trunk.csv.py.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3436 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2260] conditional jump to a POP_TOP optimization
Changes by Raymond Hettinger [EMAIL PROTECTED]: -- assignee: - rhettinger nosy: +rhettinger ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2260 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2819] Full precision summation
Mark Dickinson [EMAIL PROTECTED] added the comment: Toned down note in docs (at Raymond's request) in r65366. While I'd really like to see an lsum-based version go in instead, I think it's too close to the release to make this change right now. There was also originally some talk of a complex math version. What do people think about this? Personally, I suspect that the use cases would be few and far between, and anyone who *really* needs a complex high- precision sum can just apply math.fsum to real and imaginary parts. (This is easier now that x.imag and x.real make sense for integers as well as floats.) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2819 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2260] conditional jump to a POP_TOP optimization
Antoine Pitrou [EMAIL PROTECTED] added the comment: While this patch is interesting, I think it would be more efficient to introduce variants of JUMP_IF_FALSE and JUMP_IF_TRUE which pop their argument rather than leaving it on the stack (like I did in #2459). -- nosy: +pitrou ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2260 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3436] csv.DictReader inconsistency
Nick Coghlan [EMAIL PROTECTED] added the comment: Skip's patch looks good to me (as Skip discovered, I left out the necessary step of putting the first row back into an iterable before invoking chain in my example code) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3436 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2690] Precompute range length
Nick Coghlan [EMAIL PROTECTED] added the comment: Guido, does that mean we can apply this patch to get the cleaner list-like behaviour for 3.0, and then work on the sq_item/sq_len fixes for 3.1 as a separate issue? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2690 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2860] re module fails to handle byte strings
Antoine Pitrou [EMAIL PROTECTED] added the comment: This is a duplicate of #3231 and was fixed in r65185. -- nosy: +pitrou resolution: - duplicate status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2860 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1342811] Tkinter.Menu.delete doesn't delete command of entry
Robert Schuppenies [EMAIL PROTECTED] added the comment: The problem does still exist (Python 2.6b2). I attached a patch for Tkinter.py which addresses this problem. It is the same as in the first proposed fix, but adds an additional check whether the menu item has a 'command' property. I also removed the INDEX2 (is included) comment, as it is not the desired behavior (see http://www.tcl.tk/man/tcl8.5/TkCmd/text.htm#M98). I cannot confirm the behavior, but it should be a separate issue nevertheless. -- keywords: +patch nosy: +schuppenies Added file: http://bugs.python.org/file11025/tkinter_menuleak.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1342811 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3399] Memory corruption in multiprocessing module, OS X 10.5.4
Mark Dickinson [EMAIL PROTECTED] added the comment: I finally found some more time to look at this. I cut down the test-suite to try to find a minimal failing example. I can fairly reliably make a debug build of the trunk crash using the following nine lines import multiprocessing.managers def sqr(x): return x*x manager = multiprocessing.managers.SyncManager() manager.start() pool = manager.Pool(4) it = pool.imap_unordered(sqr, range(1)) assert sorted(it) == map(sqr, range(1)) pool.terminate() manager.shutdown() Typical output is: Fatal Python error: UNREF invalid object (followed by traceback) or: Assertion failed: (bp != NULL), function PyObject_Malloc, file Objects/obmalloc.c, line 755. or: Debug memory block at address p=0x247778: 26 bytes originally requested The 4 pad bytes at p-4 are not all FORBIDDENBYTE (0xfb): at p-4: 0xdb *** OUCH at p-3: 0xdb *** OUCH at p-2: 0xdb *** OUCH at p-1: 0xdb *** OUCH Because memory is corrupted at the start, the count of bytes requested may be bogus, and checking the trailing pad bytes may segfault. The 4 pad bytes at tail=0x247792 are not all FORBIDDENBYTE (0xfb): at tail+0: 0x35 *** OUCH at tail+1: 0x00 *** OUCH at tail+2: 0xfb at tail+3: 0xfb The block was made by call #4227530756 to debug malloc/realloc. Data at p: 00 00 00 00 00 00 00 00 ... 00 00 08 00 00 00 b0 72 Fatal Python error: bad leading pad byte ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3399 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3420] 2to3 fails to run on Mac OS X 10.4 PPC 3.0b2
Benjamin Peterson [EMAIL PROTECTED] added the comment: This is a duplicate of #3131. -- nosy: +benjamin.peterson resolution: - duplicate status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3420 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3131] 2to3 can't find fixes_dir
Martin v. Löwis [EMAIL PROTECTED] added the comment: Installation of PatternGrammar pickle is now fixed in r65368 and r65369. HWJ, please don't report multiple problems in a single tracker issue; instead, create separate tracker issues for independent problems. -- nosy: +loewis ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3131 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3399] Memory corruption in multiprocessing module, OS X 10.5.4
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Assertion failed: (bp != NULL), function PyObject_Malloc, file Objects/obmalloc.c, line 755. This one gives one probable cause of the problem: - in Modules/_multiprocessing/connection.h, connection_send_obj() releases the GIL around a call to conn_send_string(). - in Modules/_multiprocessing/socket_connection.c, conn_send_string() uses PyMem_Malloc() This is wrong (the GIL must be held when using the PyMem_* and PyObject_* functions), and is probably the cause of the failed assertion. -- nosy: +amaury.forgeotdarc ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3399 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3139] bytearrays are not thread safe
Martin v. Löwis [EMAIL PROTECTED] added the comment: Amaury, I think the issue of thread-safety of the io library should be decoupled from this issue. I don't think it is release-critical that the io library is thread-safe (and even if it is release-critical, the problem should be tracked in a different issue, as it requires a completely independent patch). The original issue (bytearrays are not thread-safe) will not be completely resolved (for a certain definition of thread-safe): it will always be possible that one thread observes a locked byte object - this is by design of the buffer interface, and it is a good design. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3139 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3399] Memory corruption in multiprocessing module, OS X 10.5.4
Mark Dickinson [EMAIL PROTECTED] added the comment: This is wrong (the GIL must be held when using the PyMem_* and PyObject_* functions), and is probably the cause of the failed assertion. This sounds quite likely. I just managed (using the low-tech method of setting a static variable on entry and clearing it on exit) to confirm that PyObject_Malloc in obmalloc.c is being accessed simultaneously by multiple threads when test_multiprocessing is run. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3399 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3139] bytearrays are not thread safe
Antoine Pitrou [EMAIL PROTECTED] added the comment: Selon Martin v. Löwis [EMAIL PROTECTED]: Amaury, I think the issue of thread-safety of the io library should be decoupled from this issue. I don't think it is release-critical that the io library is thread-safe (and even if it is release-critical, the problem should be tracked in a different issue, as it requires a completely independent patch). Sorry Martin, I forgot to mention that I did open a separate issue in #3476. Regards Antoine. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3139 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3111] multiprocessing ppc Debian/ ia64 Ubuntu compilation error
jan matejek [EMAIL PROTECTED] added the comment: as it doesn't seem /dev/shm is the culprit Mounting /dev/shm seems to fix the problem in suse's autobuild (chroot) environment, so for me it actually was the culprit. Perhaps you should recheck your buildbots? -- nosy: +matejcik ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3139] bytearrays are not thread safe
Martin v. Löwis [EMAIL PROTECTED] added the comment: I have now updated the patch to fix the socket bug, and the rejects bytearray for t#. As for making Py_buffer own a reference to the object: what should be the semantics for PyObject_ReleaseBuffer? I see the following options: - Drop PyObject_ReleaseBuffer - make it DECREF the embedded object, whether or not it is the same as the object being passed in - leave it as-is, and require the caller to DECREF. Added file: http://bugs.python.org/file11026/s_star.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3139 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3139] bytearrays are not thread safe
Changes by Martin v. Löwis [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file10969/s_star.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3139 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3399] Memory corruption in multiprocessing module, OS X 10.5.4
Mark Dickinson [EMAIL PROTECTED] added the comment: Here's a patch that fixes the problem for me. It releases the GIL around the calls to _conn_sendall within conn_send_string, instead of releasing the GIL for the whole call to conn_send_string. -- keywords: +patch Added file: http://bugs.python.org/file11027/issue3399.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3399 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3139] bytearrays are not thread safe
Antoine Pitrou [EMAIL PROTECTED] added the comment: Selon Martin v. Löwis [EMAIL PROTECTED]: As for making Py_buffer own a reference to the object: what should be the semantics for PyObject_ReleaseBuffer? I see the following options: - Drop PyObject_ReleaseBuffer - make it DECREF the embedded object, whether or not it is the same as the object being passed in - leave it as-is, and require the caller to DECREF. I don't know, is there supposed to be a semantic difference between PyObject_ReleaseBuffer and PyBuffer_Release? If not, I'd say drop it. Also, I think it's fine if you commit your fix without adding an incref/decref. In the absence of the designer of the buffer API it is difficult to know what subtleties should be taken into account when trying to change that API... ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3139 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3476] BufferedWriter not thread-safe
Martin v. Löwis [EMAIL PROTECTED] added the comment: I don't think the proposed patch (file11012) makes it thread-safe, and I believe you cannot get it thread-safe without using thread synchronization. For example, if two threads simultaneously determine that there is still space left (len(b) = free), they might both write to self._write_buf and self._write_end, and the last writer would win. (In case it isn't clear how this might happen: thread 1 exhausts its Py_Ticker just after checking the size, then thread 2 runs a full .write(), then thread 1 continues filling the buffer) -- nosy: +loewis ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3476 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3476] BufferedWriter not thread-safe
Antoine Pitrou [EMAIL PROTECTED] added the comment: Hi, Selon Martin v. Löwis [EMAIL PROTECTED]: I don't think the proposed patch (file11012) makes it thread-safe, and I believe you cannot get it thread-safe without using thread synchronization. I should have precised that in the context of this issue, thread-safe does not mean produces perfectly correct output but simply does not raise exceptions when using the same buffered object from two different threads. The former would be preferable but is not required, IMHO, for a buffered IO library; the latter is much more critical because as Amaury points out, you otherwise get exceptions when printing e.g. debut output from multiple threads. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3476 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3483] sys.stdin.read won't return on EOF
New submission from Benjamin Peterson [EMAIL PROTECTED]: $ ./python.exe -c import sys; sys.stdin.read() ^D In 2.6, this returns, but in 3.0, it still hangs despite having gotten EOF. When a KeyboardInterrupt is given, this is the traceback: ^CTraceback (most recent call last): File string, line 1, in module File /temp/python/py3k/Lib/io.py, line 1692, in read decoder.decode(self.buffer.read(), final=True)) File /temp/python/py3k/Lib/io.py, line 923, in read chunk = self.raw.read() KeyboardInterrupt -- components: Library (Lib) messages: 70565 nosy: benjamin.peterson priority: release blocker severity: normal status: open title: sys.stdin.read won't return on EOF type: behavior versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3483 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3483] sys.stdin.read won't return on EOF
Benjamin Peterson [EMAIL PROTECTED] added the comment: I'm sorry. This is my oversight. -- resolution: - invalid status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3483 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3484] Sphinx tests fail because of missing dir
New submission from Rob Cakebread [EMAIL PROTECTED]: When I try to run the unit tests with tests/run.py they fail because this directory is missing: tests/root/_build If I simply create the directory and run the tests, they pass. Running Sphinx test suite... EEE... == ERROR: test_config.test_core_config -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/nose/case.py, line 182, in runTest self.test(*self.arg) File /var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/test_config.py, line 20, in test_core_config cfg = TestApp(confoverrides=overrides).config File /var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/util.py, line 106, in __init__ freshenv) File /var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/sphinx/application.py, line 101, in __init__ self.builder = builderclass(self, freshenv=freshenv) File /var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/sphinx/builder.py, line 58, in __init__ os.mkdir(self.doctreedir) OSError: [Errno 2] No such file or directory: '/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/root/_build/doctrees' == ERROR: test_config.test_extension_values -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/nose/case.py, line 182, in runTest self.test(*self.arg) File /var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/test_config.py, line 65, in test_extension_values app = TestApp() File /var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/util.py, line 106, in __init__ freshenv) File /var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/sphinx/application.py, line 101, in __init__ self.builder = builderclass(self, freshenv=freshenv) File /var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/sphinx/builder.py, line 58, in __init__ os.mkdir(self.doctreedir) OSError: [Errno 2] No such file or directory: '/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/root/_build/doctrees' == ERROR: Failure: OSError ([Errno 2] No such file or directory: '/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/root/_build/doctrees') -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/nose/loader.py, line 364, in loadTestsFromName addr.filename, addr.module) File /usr/lib/python2.5/site-packages/nose/importer.py, line 39, in importFromPath return self.importFromDir(dir_path, fqname) File /usr/lib/python2.5/site-packages/nose/importer.py, line 84, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File /var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/test_markup.py, line 21, in module app = TestApp() File /var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/util.py, line 106, in __init__ freshenv) File /var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/sphinx/application.py, line 101, in __init__ self.builder = builderclass(self, freshenv=freshenv) File /var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/sphinx/builder.py, line 58, in __init__ os.mkdir(self.doctreedir) OSError: [Errno 2] No such file or directory: '/var/tmp/portage/dev-python/sphinx-0.4.2-r1/work/Sphinx-0.4.2/tests/root/_build/doctrees' -- Ran 6 tests in 3.785s FAILED (errors=3) -- assignee: georg.brandl components: Documentation tools (Sphinx) messages: 70567 nosy: cakebread, georg.brandl severity: normal status: open title: Sphinx tests fail because of missing dir versions: Python 2.5 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3484 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3484] Sphinx tests fail because of missing dir
Benjamin Peterson [EMAIL PROTECTED] added the comment: Sorry, time machine! I fixed this just 2 days ago. :) -- nosy: +benjamin.peterson resolution: - out of date status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3484 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3399] Memory corruption in multiprocessing module, OS X 10.5.4
Mark Dickinson [EMAIL PROTECTED] added the comment: Thanks, Amaury! How's this? I have no access to a Windows machine, so this patch is untested on Windows. Added file: http://bugs.python.org/file11028/issue3399_2.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3399 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3419] multiprocessing module is racy
Mark Dickinson [EMAIL PROTECTED] added the comment: I'm also seeing the incref error occasionally, on OS X 10.5.4: == ERROR: test_remote (__main__.WithManagerTestRemoteManager) -- Traceback (most recent call last): File Lib/test/test_multiprocessing.py, line 1157, in test_remote queue = manager2.get_queue() File /Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py, line 635, in temp authkey=self._authkey, exposed=exp File /Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py, line 887, in AutoProxy incref=incref) File /Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py, line 696, in __init__ self._incref() File /Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py, line 743, in _incref dispatch(conn, None, 'incref', (self._id,)) File /Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py, line 79, in dispatch raise convert_to_error(kind, result) RemoteError: --- Traceback (most recent call last): File /Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py, line 181, in handle_request result = func(c, *args, **kwds) File /Users/dickinsm/python_source/trunk/Lib/multiprocessing/managers.py, line 397, in incref self.id_to_refcount[ident] += 1 KeyError: '6fdb78' --- -- nosy: +marketdickinson ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3419 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3485] os.path.normcase documentation/behaviour unclear on Mac OS X
New submission from Isaac Morland [EMAIL PROTECTED]:
$ python
Python 2.5.1 (r251:54863, Apr 15 2008, 22:57:26)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type help, copyright, credits or license for more information.
from os.path import normcase
normcase ('aB')
'aB'
From http://docs.python.org/lib/module-os.path.html: On Unix, this
returns the path unchanged; on case-insensitive filesystems, it converts
the path to lowercase. Of course, Mac OS X is both Unix and
case-insensitive, which is a rather bizarre combination, but that's it
is. Where is the item for make all file systems case-sensitive, put
the case-insensitivity in the user interface?
--
components: Macintosh
messages: 70571
nosy: ijmorlan
severity: normal
status: open
title: os.path.normcase documentation/behaviour unclear on Mac OS X
type: behavior
versions: Python 2.5
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3485
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3006] subprocess.Popen causes socket to remain open after close
Kevin Watters [EMAIL PROTECTED] added the comment: I found a workaround for this issue (attached) via the kernel32.dll function SetHandleInformation. You can patch the socket class to set all newly created sockets as uninheritable. It's not perfect--another thread could still spawn a subprocess in between. We probably need some kind of API for setting socket inheritance. Added file: http://bugs.python.org/file11029/socketinherit.py ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3006 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3486] bytes.join does not accept a sequence of bytearrays
New submission from Antoine Pitrou [EMAIL PROTECTED]: This works in py3k but not in 2.x. I don't know if it is deliberate: Python 3.0b2+ (py3k, Jul 27 2008, 12:52:40) [GCC 4.3.1 20080626 (prerelease)] on linux2 Type help, copyright, credits or license for more information. b.join([bytearray(b)]) b'' Python 2.6b2+ (trunk, Aug 1 2008, 01:47:52) [GCC 4.3.1 20080626 (prerelease)] on linux2 Type help, copyright, credits or license for more information. b.join([bytearray(b)]) Traceback (most recent call last): File stdin, line 1, in module TypeError: sequence item 0: expected string, bytearray found -- components: Interpreter Core messages: 70573 nosy: pitrou priority: normal severity: normal status: open title: bytes.join does not accept a sequence of bytearrays type: behavior versions: Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3486 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3487] sre bytecode verifier
New submission from Guido van Rossum [EMAIL PROTECTED]: Attached is a verifier for the binary code used by the _sre module (this is often called bytecode, though to distinguish it from Python bytecode I put it in quotes). I wrote this for Google App Engine, and am making the patch available as open source under the Apache 2 license. Below are the copyright statement and license, for completeness. Barry, I'm assigning this to you only so that you can decide whether this is okay to check in before beta3. The patch works for 2.6 as well as for 3.0 (and even for 2.5, but I don't think it's worth changing that -- or is it?). If you agree (which I hope you will do), please assign back to me with instructions and I'll submit it. The performance impact is minimal: it only runs when the compiled bytecode is passed from the re compiler (written in Python) to the C code, during the sre compilation stage. All tests pass. We've had this code in use in App Engine since April without complaints. # Copyright 2008 Google Inc. # # Licensed under the Apache License, Version 2.0 (the License); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an AS IS BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. It's not necessary to include these copyrights and bytecode in the source file. Google has signed a contributor's agreement with the PSF already. -- assignee: barry files: sre-verifier.diff keywords: patch, patch messages: 70574 nosy: barry, gvanrossum priority: release blocker severity: normal status: open title: sre bytecode verifier versions: Python 2.5, Python 2.6, Python 3.0 Added file: http://bugs.python.org/file11030/sre-verifier.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3487 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3486] bytes.join does not accept a sequence of bytearrays
Benjamin Peterson [EMAIL PROTECTED] added the comment: I suppose this is because bytes is simply aliased to str. I propose we just leave it as is. The ultimate solution is probably backporting th py3k PyBytes type. -- nosy: +benjamin.peterson ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3486 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3489] add rotate{left,right} methods to bytearray
New submission from Antoine Pitrou [EMAIL PROTECTED]:
While tweaking the BufferedWriter implementation it came to me that it
would be useful to have rotate_left and rotate_right methods on
bytearray, so as to rotate the array by a number of bytes without any
wasteful memory allocations and copies.
(or, if memoryview is one day implemented it could be a memoryview
method instead...)
--
components: Interpreter Core
messages: 70579
nosy: pitrou
priority: normal
severity: normal
status: open
title: add rotate{left,right} methods to bytearray
type: feature request
versions: Python 2.7, Python 3.1
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3489
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3399] Memory corruption in multiprocessing module, OS X 10.5.4
Jesse Noller [EMAIL PROTECTED] added the comment: I added the semicolons Amaury, and have it teed up in my local repo for submit. Can you review this diff just to confirm? Added file: http://bugs.python.org/file11031/add_semicolons.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3399 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2688] Error when nesting many while loops
Jack Diederich [EMAIL PROTECTED] added the comment: This was fixed in more recent versions of 2.5, it now raises a SystemError: too many statically nested blocks Thanks for the tip Guilherme. Marking closed. -- nosy: +jackdied resolution: - out of date status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2688 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2935] rfc822.py line 395 strings connection
Jack Diederich [EMAIL PROTECTED] added the comment: This is a bug in the external ClientCookie module (and their website hasn't been updated since 2006). Marking closed. -- nosy: +jackdied resolution: - invalid status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2935 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3139] bytearrays are not thread safe
Antoine Pitrou [EMAIL PROTECTED] added the comment: Le vendredi 01 août 2008 à 17:53 +, Amaury Forgeot d'Arc a écrit : There is a small issue with the patch: in the w# format handler, bf_getwritebuffer(arg, 0, res) is wrong. The third argument should be res (there is a compilation warning on windows), And a few lines after, in the if (*format == '#') block, there should be a line like *p = res; otherwise the user code never sees the buffer... Nice catch! Making those changes actually fixes a segfault I had in testReadinto in test_file.py. By the way, please note bytearray.decode is broken: Traceback (most recent call last): File stdin, line 1, in module TypeError: ascii_decode() argument 1 must be string or pinned buffer, not bytearray bytearray(b).decode(utf8) Traceback (most recent call last): File stdin, line 1, in module File /home/antoine/cpython/bufferedwriter/Lib/encodings/utf_8.py, line 16, in decode return codecs.utf_8_decode(input, errors, True) TypeError: utf_8_decode() argument 1 must be string or pinned buffer, not bytearray bytearray(b).decode(latin1) Traceback (most recent call last): File stdin, line 1, in module TypeError: latin_1_decode() argument 1 must be string or pinned buffer, not bytearray ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3139 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3485] os.path.normcase documentation/behaviour unclear on Mac OS X
Ned Deily [EMAIL PROTECTED] added the comment:
Of course, Mac OS X is both Unix and case-insensitive
Not so. Case-{in|}sensitivity is an attribute of HFS+ file systems that is
specifiable when a file system is created; it's true that the default is
still case-insensitive. There are also other case-sensitive file systems
supported on OS X.
--
nosy: +nad
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3485
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2819] Full precision summation
Tim Peters [EMAIL PROTECTED] added the comment: Mark, changing API is something to avoid after beta cycles begin (so, e.g., it's late in the game to /add/ a new API, like a new method for complex summation). But there's no particular reason to fear changing implementation for an API that's already in. If the test suite supplies good coverage, the buildbots will catch significant portability snafus in plenty of time for the next release. The big attraction to the lsum-like approach for users is that it just works, without requiring weasel words in the docs about overflows, underflows, or esoteric details about various HW FP quirks. Integer arithmetic is just plain better behaved across platforms ;-) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2819 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3485] os.path.normcase documentation/behaviour unclear on Mac OS X
Isaac Morland [EMAIL PROTECTED] added the comment: Ok, good point. Perhaps the documentation should be updated to clarify that Mac OS is treated as Unix even though a default Mac OS X installation will have a case-insensitive file system. Wouldn't it be possible for a Windows machine to have a case-sensitive file system similarly? Or is it more built-in that the file system on a Windows box will be case-insensitive? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3485 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3139] bytearrays are not thread safe
Changes by Giampaolo Rodola' [EMAIL PROTECTED]: -- nosy: -giampaolo.rodola ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3139 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3399] Memory corruption in multiprocessing module, OS X 10.5.4
Jesse Noller [EMAIL PROTECTED] added the comment: I've committed this as-is based off my last patch. I will watch the buildbots for failures. Mark/Amaury - if I see you guys at pycon, I owe you a drink. -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3399 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3476] BufferedWriter not thread-safe
Antoine Pitrou [EMAIL PROTECTED] added the comment:
Attaching a new patch with better performance characteristics than my
previous one, and the non-blocking test rewritten in a sane way.
Some timeit runs:
-s import io; f=io.open('/dev/null', 'wb'); s=b'a'*1 for i in xrange(100):
f.write(s)
without patch: 533 usec per loop
with patch: 724 usec per loop
with builtin open(): 59.6 usec per loop
-s import io; f=io.open('/dev/null', 'wb'); s=b'a'*100 for i in xrange(100):
f.write(s)
without patch: 563 usec per loop
with patch: 768 usec per loop
with builtin open(): 67.8 usec per loop
-s import io; f=io.open('/dev/null', 'wb'); s=b'a'*1 for i in
xrange(100): f.write(s)
without patch: 1.35 msec per loop
with patch: 1.34 msec per loop
with builtin open(): 194 usec per loop
-s import io; f=io.open('/dev/null', 'wb'); s=b'a'*10 for i in
xrange(100): f.write(s)
without patch: 4.92 msec per loop
with patch: 1.34 msec per loop
with builtin open(): 199 usec per loop
-s import io; f=io.open('/dev/null', 'wb'); s=b'a'*100 for i in
xrange(100): f.write(s)
without patch: 173 msec per loop
with patch: 1.35 msec per loop
with builtin open(): 194 usec per loop
Added file: http://bugs.python.org/file11034/bufferedwriter2.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3476
___diff -r d73a32dd9bbc Lib/io.py
--- a/Lib/io.py Fri Aug 01 21:33:00 2008 +0200
+++ b/Lib/io.py Fri Aug 01 22:03:27 2008 +0200
@@ -1018,39 +1018,79 @@ class BufferedWriter(_BufferedIOMixin):
raw._checkWritable()
_BufferedIOMixin.__init__(self, raw)
self.buffer_size = buffer_size
-self.max_buffer_size = (2*buffer_size
-if max_buffer_size is None
-else max_buffer_size)
-self._write_buf = bytearray()
+self._write_buf = bytearray(b * self.buffer_size)
+self._reset_write_buf()
+
+def _reset_write_buf(self):
+# Just after the last byte actually written
+self._write_pos = 0
+# Just after the last buffered byte
+self._write_end = 0
def write(self, b):
if self.closed:
raise ValueError(write to closed file)
if isinstance(b, unicode):
raise TypeError(can't write unicode to binary stream)
-# XXX we can implement some more tricks to try and avoid partial writes
-if len(self._write_buf) self.buffer_size:
-# We're full, so let's pre-flush the buffer
-try:
-self.flush()
-except BlockingIOError as e:
-# We can't accept anything else.
-# XXX Why not just let the exception pass through?
-raise BlockingIOError(e.errno, e.strerror, 0)
-before = len(self._write_buf)
-self._write_buf.extend(b)
-written = len(self._write_buf) - before
-if len(self._write_buf) self.buffer_size:
-try:
-self.flush()
-except BlockingIOError as e:
-if (len(self._write_buf) self.max_buffer_size):
-# We've hit max_buffer_size. We have to accept a partial
-# write and cut back our buffer.
-overage = len(self._write_buf) - self.max_buffer_size
-self._write_buf = self._write_buf[:self.max_buffer_size]
-raise BlockingIOError(e.errno, e.strerror, overage)
-return written
+end = self._write_end
+free = self.buffer_size - end
+# If b is a bytearray, ensure it won't be mutated
+# (we must keep the internal buffer size constant)
+b = bytes(b)
+if len(b) = free:
+# Fast path: the data to write can be fully buffered
+self._write_buf[end:end+len(b)] = b
+self._write_end = end + len(b)
+return len(b)
+
+# First write the current buffer
+try:
+self.flush()
+except BlockingIOError as e:
+# Make some place by rotating the buffer
+pos = self._write_pos
+if pos 0:
+self._write_buf[:-pos] = self._write_buf[pos:]
+self._write_pos = 0
+end = self._write_end - pos
+avail = self.buffer_size - end
+# Buffer as much as possible
+if avail len(b):
+self._write_buf[end:] = b[:avail]
+self._write_end = self.buffer_size
+# The remaining bytes don't fit inside the buffer
+raise BlockingIOError(e.errno, e.strerror, avail)
+self._write_buf[end:end+len(b)] = b
+self._write_end = end + len(b)
+return len(b)
+
+# Then write b itself
+remaining = len(b)
+written = 0
+try:
+while remaining = self.buffer_size:
+
[issue3228] mailbox.mbox creates files with execute bit set
Jack Diederich [EMAIL PROTECTED] added the comment: mailbox.py uses os.open instead of the builtin open() because it wants to pass the exclusive flag (O_EXCL). As a result your 0077 umask gets combined with the default of 0777 like this: 0777 ~0077 == 0700 == '-rwx--' So you probably want to change your default umask when creating mailboxes. Or submit a patch to mailbox.py to allow a different default mode ;) -- nosy: +jackdied ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3228 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2951] ElementTree parsing bus error (but only from mod_python)
Jack Diederich [EMAIL PROTECTED] added the comment: It is a common apache problem. Elementree imports an expat parser (presumably cElementree doesn't) and different versions of expat play together very poorly. Lots of apache modules load one xml lib version or another and they tend to step on each others toes .. and then segfault. IIRC the only way to resolve this is to figure out which loaded apache modules are using expat and recompile them all against the same version. Not fun. -- nosy: +jackdied resolution: - invalid status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2951 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1563] asyncore and asynchat incompatible with Py3k str and bytes
Josiah Carlson [EMAIL PROTECTED] added the comment: The current revision of 3.0 handles the case where reading from the socket returns a Python 3.0 str object, which it then translates into bytes objects. This is sufficient for passing the 3.0 unittests. See asynchat.async_chat.use_encoding and asynchat.async_chat.encoding . From what I understand, the OP wants to be able to pass unicode strings across a network connection. I'm not sure that such is generally desirable to be within the standard library. I would actually argue that being able to transparently pass unicode across a socket is a misfeature; especially considering 1 unciode character can become 2 or more bytes when encoded as utf-8, etc., and sockets make no guarantees about an entire packet being delivered. In terms of sending (push_str), it should be an error that the user software is attempting to send textual data (all reasonable RFCs define protocols in terms of ascii, not utf). Handling incoming data (set_terminator_str) follows the same argument against handling unicode data as push_str, only in reverse. This should not be backported to any version of Python. Before discussion about actually applying any patch to asyncore/asynchat/smtpd continues, I would like to hear of a use-case for wanting to pass textual unicode data across a socket connection. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1563 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3488] Provide compress/uncompress functions on the gzip module
Anand B Pillai [EMAIL PROTECTED] added the comment: Uploading a file containing two functions which can be used to provide compress/uncompress on gzip. This is not a patch to gzip.py, but a stand-alone file. It this looks fine, I will make a patch. Added file: http://bugs.python.org/file11035/gzip_patch.py ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3488 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3139] bytearrays are not thread safe
Martin v. Löwis [EMAIL PROTECTED] added the comment: I don't know, is there supposed to be a semantic difference between PyObject_ReleaseBuffer and PyBuffer_Release? If not, I'd say drop it. There are existing callers of it which would need to be changed, perhaps outside the core also; plus it's in PEP 3118. Technically, they do the same. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3139 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3487] sre bytecode verifier
Terry J. Reedy [EMAIL PROTECTED] added the comment: Based on my understanding of the above and PyDev discussions, I see the arguments in favor of quick inclusion as being the following: 1. This will be user invisible, so it is not a new interface feature. 2. This will prevent possible interpreter crashes or other bad behavior as a result of malformed SREcode. So it could be considered a bug fix. 3. Google considered this enough of a potential problem to pre-emptively fix it. Now that that problem has been publicly exposed, other careful users will expect it to be fixed and will find Python more attractive when it has been. If this is included in the next betas, the announcement of such might say so and encourage re users to re-run any re-based test code. -- nosy: +tjreedy ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3487 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3476] BufferedWriter not thread-safe
Martin v. Löwis [EMAIL PROTECTED] added the comment: I should have precised that in the context of this issue, thread-safe does not mean produces perfectly correct output but simply does not raise exceptions when using the same buffered object from two different threads. In that case, I'm -1 for this patch. Raising exceptions is much more preferable to silently losing data, or writing garbage. The former would be preferable but is not required, IMHO, for a buffered IO library; the latter is much more critical because as Amaury points out, you otherwise get exceptions when printing e.g. debut output from multiple threads. And that's a good thing, when using a library that is not thread-safe. Either the library provides thread-safety, or it doesn't. If it doesn't, it's the application's responsibility to not use the library from multiple threads, or protect all access with appropriate synchronization. Now that print is a function, it's easy to implement a version of it that synchronizes all prints. With the status quo, people have at least a chance of learning that the library is not thread-safe. If the shallow problems are resolved, people will cry FOUL loudly when they learn about the deep problems. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3476 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3485] os.path.normcase documentation/behaviour unclear on Mac OS X
Martin v. Löwis [EMAIL PROTECTED] added the comment: On Windows, case-insensitivity is part of the API, not of the file system. NTFS itself is case-sensitive, and there are case-sensitive subsystems on top of it (e.g. the POSIX subsystem, Interix). Win32, when calling the file system, asks for case-insensitive lookup (which NTFS also supports efficiently). I believe FAT is inherently case-insensitive. -- nosy: +loewis ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3485 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3476] BufferedWriter not thread-safe
Antoine Pitrou [EMAIL PROTECTED] added the comment: Le vendredi 01 août 2008 à 21:51 +, Martin v. Löwis a écrit : With the status quo, people have at least a chance of learning that the library is not thread-safe. If the shallow problems are resolved, people will cry FOUL loudly when they learn about the deep problems. But the current implementation can also silently produce garbage without raising an exception. It's only if the context switch happens at a certain precise point that an exception is raised. If the internal buffer is mutated without resizing of the backing memory area (or without any buffer being currently held), there is no exception and still the behaviour is incorrect. Now that print is a function, it's easy to implement a version of it that synchronizes all prints. Well, if that resolution is prefered, I think it should be integrated to the builtin print function, rather than forcing users to monkeypatch it (but a debugging facility directly calling sys.stdout.write or equivalent will not be helped). ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3476 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1563] asyncore and asynchat incompatible with Py3k str and bytes
Daniel Arbuckle [EMAIL PROTECTED] added the comment: From what I understand, the OP wants to be able to pass unicode strings across a network connection. That's incorrect. At the time I formulated this patch, asyncore/asynchat were slated for removal from the standard lib unless somebody stepped up and made it work correctly after the str/bytes transition. That's what asyn_py3k.diff and its predecessors do, as well as adding sorely-needed docstrings to the module. This patch may be a little more complete than the currently committed code, or it may be largely redundant. The docstrings, at least, are still needed. The asyn_py3k_restructured.diff patch is a superset of asyn_py3k.diff, which additionally removes the producer type from the module, replacing it with iterators. This is controversial, and seems unlikely to be committed. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1563 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1563] asyncore and asynchat incompatible with Py3k str and bytes
Josiah Carlson [EMAIL PROTECTED] added the comment: Asyncore and asynchat are not going to be removed, and were not being seriously discussed as being removable in Python 3.0 since January of 2007 when I took over maintenance. If there was a miscommunication in an email thread on python-3000 or python-dev, then I'm sorry, as I was relatively incommunicado for about a year. As of right now, the tests for 3.0 pass, and when passing only bytes in and out of asyncore and asynchat, everything works just fine. Mixing and matching might or might not work, but explicitly allowing an error to pass silently (passing text where bytes should be passed) is the wrong thing to do. If you want to change the docstrings, that's fine, submit a patch that includes docstring changes only, and I'll probably commit it some time next week. Functionality changes will need to be discussed. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1563 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3419] multiprocessing module is racy
Mark Dickinson [EMAIL PROTECTED] added the comment: For the connection refused error, the following script fails for me (again, on OS X 10.5.4) with the message: errno: [Errno 61] Connection refused on most runs. (If xrange(10) is replaced by a smaller range like xrange(4) then the script usually runs without error.) Looks like something in semaphore.c needs fixing, but I've no idea what. from multiprocessing import Process, Manager sleeping = Manager().Semaphore(0) def f(): sleeping.release() for _ in xrange(10): Process(target=f).start() for _ in xrange(10): sleeping.acquire() ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3419 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1563] asyncore and asynchat incompatible with Py3k str and bytes
Daniel Arbuckle [EMAIL PROTECTED] added the comment: As of December 2007, Guido did not believe that you or anyone else cared enough about asyncore/asynchat to update them to py3k: http://mail.python.org/pipermail/python-dev/2007-December/075574.html Thankfully there's been a resurgence of activity on the modules, and they're well out of danger now. I _am_not_ proposing that passing unicode into asyncore should do anything other than fail. I have never proposed such, and my patch tightened those constraints rather than loosening them. Please stop beating that horse; it's dead. On a more positive note, I'll put together that docstring patch for you at the same time I'm evaluating whether any of the rest of my patch remains necessary. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1563 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3459] optimize bytes.join()
Terry J. Reedy [EMAIL PROTECTED] added the comment: How much does the optimization speed up (or slow down?) a more normal case when it is applicable? bl = [b'', b'a'] How much does the optimization slow down the normal case where it is not applied? bl = [b'a']*2 bl = [b'a']*1 Could not the .join user simply not add empty list items? Looking at the code, there appear to be 4 extra operations for every item in the normal case: assign item_size, test item_size, assign nonempty, increment nb_nonempty. I believe this alternative might be generally faster. Before the normal scan, if seplen == 0: for item in seq: if second non-null item: break else: do shortcut and return do normal process Then normal cases will bail out on the second item and continue without further impact. -- nosy: +tjreedy ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3459 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3487] sre bytecode verifier
Guido van Rossum [EMAIL PROTECTED] added the comment: 3. Google considered this enough of a potential problem to pre-emptively fix it. Now that that problem has been publicly exposed, other careful users will expect it to be fixed and will find Python more attractive when it has been. If this is included in the next betas, the announcement of such might say so and encourage re users to re-run any re-based test code. I should add that the protection this offers is against attempts to cause crashes by passing bad RE bytecode into the _sre.compile(). It is not possibly to generate such bad RE bytecode by writing an evil regular expression; you must have access to the _sre module in order to be able to exploit this vulnerability. In other words, the vulnerability is equivalent to having ctypes accessible. Thus, only people who are worried about malicious use of ctypes should be worried about this vulnerability. Google's App Engine is one of those (rare) places, since it lets anybody run their Python code in a Google datacenter. If you offer the ability to run arbitrary Python code to strangers, you should worry about this. Otherwise, there is no reason to worry. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3487 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3459] optimize bytes.join()
Antoine Pitrou [EMAIL PROTECTED] added the comment: bl = [b'', b'a'] gives a 20% speedup: before patch: 100 loops, best of 3: 0.443 usec per loop after patch: 100 loops, best of 3: 0.349 usec per loop (20% speedup) bl = [b'a']*2 gives a 2% slowdown: before patch: 100 loops, best of 3: 0.439 usec per loop after patch: 100 loops, best of 3: 0.447 usec per loop bl = [b'a']*1 gives a 1% slowdown: before patch: 1000 loops, best of 3: 510 usec per loop after patch: 1000 loops, best of 3: 515 usec per loop So, even in the worst case of joining the shortest possible non-empty strings, the overhead is still minimal. Could not the .join user simply not add empty list items? The .join user could also detect whether there is a single element in the list and the separator is empty, and then avoid calling join :) The point of integrating the optimization in bytes.join is that: 1) it makes it implicit, so that user code stays clean of performance hacks 2) the optimization itself has much less overhead, since it is written in C rather than in Python ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3459 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3419] multiprocessing module is racy
Mark Dickinson [EMAIL PROTECTED] added the comment: Looks like something in semaphore.c needs fixing, but I've no idea what. I take that back. It's nothing to do with semaphore.c. I'll keep trying. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3419 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3463] make life.py use more rendering characters
Terry J. Reedy [EMAIL PROTECTED] added the comment: Summary: This patch makes a non-essential change to a curses demo. It also reverses several 2.x to 3.0 edits, turning it back to 2.x code. So the current version must be rejected. Even if corrected, I would still recommend closing. To me, allowing any printable ascii char, even space, to represent live cells adds nothing to the file's value as a curses demo. Perhaps # as an altnative, but even that would be a distraction from the main purpose. The large bash-specific input chart is very nice. I wish I has had something like that when I worked with sh and csh. But it has little to do with this program in particular or Python as such and I think it would be a distraction if added. These diffs and others like them replace 3.0 code with 2.x code that in two cases will not work in 3.0. -raise ValueError(Coordinates out of range %i,%i% (y,x)) +raise ValueError, Coordinates out of range %i,%i% (y,x) -live = (i,j) in self.state +live = self.state.has_key( (i,j) ) -xpos, ypos = board.X//2, board.Y//2 +xpos, ypos = board.X/2, board.Y/2 -- nosy: +tjreedy ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3463 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3476] BufferedWriter not thread-safe
Martin v. Löwis [EMAIL PROTECTED] added the comment: Well, if that resolution is prefered, I think it should be integrated to the builtin print function, rather than forcing users to monkeypatch it (but a debugging facility directly calling sys.stdout.write or equivalent will not be helped). True. I think it is the stream's write method that must be synchronized, e.g. by renaming the current write function to _write_locked, and adding a write function that obtains a per-file lock, and calls write_locked. Other methods accessing the buffer need to get synchronized with the same lock as well. This is how it's done in about any stdio implementation I ever looked at. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3476 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3490] Example Code Error in Tutorial Documentation
New submission from Adam [EMAIL PROTECTED]: In section 4.4 of the Python Tutorial (http://docs.python.org/tut/node6.html) there is a code example using prime numbers that results extraneous output. The else is incorrectly indented one tab too far to the right and is nested under (for x in range) rather than (for n in range). Current: for n in range(2, 10): ... for x in range(2, n): ... if n % x == 0: ... print n, 'equals', x, '*', n/x ... break ... else: ... # loop fell through without finding a factor ... print n, 'is a prime number' ... Correct: for n in range(2, 10): ... for x in range(2, n): ... if n % x == 0: ... print n, 'equals', x, '*', n/x ... break ... else: ... # loop fell through without finding a factor ... print n, 'is a prime number' ... -- assignee: georg.brandl components: Documentation messages: 70613 nosy: georg.brandl, yoshokun severity: normal status: open title: Example Code Error in Tutorial Documentation ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3490 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3490] Example Code Error in Tutorial Documentation
Benjamin Peterson [EMAIL PROTECTED] added the comment: Thanks! Fixed in r65382. -- nosy: +benjamin.peterson resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3490 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3491] compile error fixing (_multiprocessing, windows)
New submission from Hirokazu Yamamoto [EMAIL PROTECTED]: This will fix the compile error on buildbot. Thank you. -- components: Windows files: fix_compile_error.patch keywords: patch, patch messages: 70615 nosy: ocean-city severity: normal status: open title: compile error fixing (_multiprocessing, windows) type: compile error versions: Python 2.6 Added file: http://bugs.python.org/file11036/fix_compile_error.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3491 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3490] Example Code Error in Tutorial Documentation
Benjamin Peterson [EMAIL PROTECTED] added the comment: Sorry, the example actually is correct. (reverted) -- resolution: fixed - rejected ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3490 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3491] compile error fixing (_multiprocessing, windows)
Benjamin Peterson [EMAIL PROTECTED] added the comment: Fixed in r65385. -- nosy: +benjamin.peterson resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3491 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3480] Fix_imports pattern optimization
Collin Winter [EMAIL PROTECTED] added the comment: Committed as r65397. Nice work! -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3480 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3358] 2to3 Iterative Wildcard Matching
Collin Winter [EMAIL PROTECTED] added the comment: Nick, what do you think about that? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3358 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3358] 2to3 Iterative Wildcard Matching
Nick Edds [EMAIL PROTECTED] added the comment: Sounds good to me. I should have a chance to implement this and submit it within the next couple of days. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3358 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
