[issue41222] POpen bufsize=0 ignored with universal_newlines=True
Antoine Pitrou added the comment: Hmm, sorry for not responding earlier. Buffering is necessary for implementing the universal_newlines behaviour (I don't know how we could do otherwise?). This has the unavoidable side effect that the Python buffered file object is not in sync with the underlying file descriptor, so that using `p.stdout` in a `select` call will give you inaccurate information. So it seems like this is perhaps a documentation issue. What do you think? -- ___ Python tracker <https://bugs.python.org/issue41222> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15500] Python should support exporting thread names to the OS
Antoine Pitrou added the comment: Two things: 1) I agree this is an extremely valuable addition for any package or application that does a non-trivial use of threads in Python. 2) It should at least be exposed as a standalone function in the `threading` module, *and* ideally also be called automatically by the `Threading._bootstrap` method. -- ___ Python tracker <https://bugs.python.org/issue15500> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45554] multiprocessing exitcode is insufficiently documented
Change by Antoine Pitrou : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue45554> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40120] Undefined C behavior going beyond end of struct via a [1] arrays.
Antoine Pitrou added the comment: How about: #ifdef __cplusplus char array[1]; #else char array[]; #endif ? -- ___ Python tracker <https://bugs.python.org/issue40120> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46464] concurrent.futures.ProcessPoolExecutor can deadlock when tcmalloc is used
Antoine Pitrou added the comment: Indeed, it seems this should only be disabled when the "fork" model is used, especially as the optimization is mostly valuable when spawning a worker is expensive. -- nosy: +pitrou ___ Python tracker <https://bugs.python.org/issue46464> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46593] memoryview lacks support for half floats
New submission from Antoine Pitrou :
The struct module has support for half-floats (the "e" format code) but support
is not fully enabled in the memoryview object.
Let's contrast float32 (the "f" format code), which you can cast to, and read
as Python objects:
>>> a = np.array([0.0, -1.5], np.float32())
>>> list(memoryview(a))
[0.0, -1.5]
>>> memoryview(a.tobytes()).cast('f').tolist()
[0.0, -1.5]
and float16, where support is minimal (casting forbidden, reading as Python
objects unimplemented):
>>> a = np.array([0.0, -1.5], np.float16())
>>> list(memoryview(a))
Traceback (most recent call last):
File "", line 1, in
list(memoryview(a))
NotImplementedError: memoryview: format e not supported
>>> memoryview(a.tobytes()).cast('e').tolist()
Traceback (most recent call last):
File "", line 1, in
memoryview(a.tobytes()).cast('e').tolist()
ValueError: memoryview: destination format must be a native single character
format prefixed with an optional '@'
--
components: Interpreter Core
messages: 412205
nosy: mark.dickinson, meador.inge, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: memoryview lacks support for half floats
type: enhancement
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue46593>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13034] Python does not read Alternative Subject Names from SSL certificates larger than 1024 bits
Antoine Pitrou added the comment:
Thanks for reporting. This trivial patch seems to fix it (still needs a test):
diff -r 1b4fae183da3 Modules/_ssl.c
--- a/Modules/_ssl.cTue Aug 09 18:48:02 2011 -0500
+++ b/Modules/_ssl.cFri Sep 23 18:16:04 2011 +0200
@@ -590,7 +590,7 @@ _get_peer_alt_names (X509 *certificate)
/* get a memory buffer */
biobuf = BIO_new(BIO_s_mem());
-i = 0;
+i = -1;
while ((i = X509_get_ext_by_NID(
certificate, NID_subject_alt_name, i)) >= 0) {
Yay for undocumented OpenSSL APIs with weird semantics.
--
assignee: -> pitrou
versions: +Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue13034>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13034] Python does not read Alternative Subject Names from SSL certificates larger than 1024 bits
Antoine Pitrou added the comment: For the record, curl uses the (also undocumented) X509_get_ext_d2i() function instead. -- ___ Python tracker <http://bugs.python.org/issue13034> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13054] sys.maxunicode value after PEP-393
Antoine Pitrou added the comment: I think there's no point in deprecating a function (or data) with a perfectly valid definition. As for test_bigmem, better keep character_size hardwired to 1 (if all tests really use only ASCII chars, which I'm not sure they do). -- ___ Python tracker <http://bugs.python.org/issue13054> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13080] test_email fails in refleak mode
New submission from Antoine Pitrou :
$ ./python -m test -R 3:2 -uall test_email
[1/1] test_email
beginning 5 repetitions
12345
Warning -- sys.path was modified by test_email
test test_email failed -- Traceback (most recent call last):
File "/home/antoine/cpython/default/Lib/test/test_email/test_policy.py", line
136, in test_overriden_register_defect_works
self.assertEqual(my_policy.defects, [defect1])
AssertionError: Lists differ: [MyDefect('one',), MyDefect('t... !=
[MyDefect('one',)]
First differing element 0:
one
one
First list contains 2 additional elements.
First extra element 1:
two
- [MyDefect('one',), MyDefect('two',), MyDefect('one',)]
+ [MyDefect('one',)]
1 test failed:
test_email
--
components: Library (Lib), Tests
messages: 144700
nosy: barry, pitrou, r.david.murray
priority: normal
severity: normal
status: open
title: test_email fails in refleak mode
type: behavior
versions: Python 3.3
___
Python tracker
<http://bugs.python.org/issue13080>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13072] Getting a buffer from a Unicode array uses invalid format
Changes by Antoine Pitrou : -- nosy: +mark.dickinson, skrah ___ Python tracker <http://bugs.python.org/issue13072> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13070] segmentation fault in pure-python multi-threaded server
Antoine Pitrou added the comment: Shouldn't the test use "self.BufferedRWPair" instead of "io.BufferedRWPair"? Also, is it ok to just return NULL or should the error state also be set? -- ___ Python tracker <http://bugs.python.org/issue13070> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12804] make test should not enable the urlfetch resource
Antoine Pitrou added the comment: Please consider reverting this patch. If you have flaky network connection, you can override the test flags yourself. -- nosy: +brett.cannon, pitrou status: closed -> open ___ Python tracker <http://bugs.python.org/issue12804> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12804] make test should not enable the urlfetch resource
Antoine Pitrou added the comment: Change reverted. "make test" should run a comprehensive test of Python's facilities, and that includes network facilities. We only exclude functionality where testing is hostile to the user (largefile,audio,gui). You could add "make offlinetest" if you care, though. -- components: +Tests priority: normal -> low resolution: fixed -> stage: committed/rejected -> type: -> behavior ___ Python tracker <http://bugs.python.org/issue12804> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13034] Python does not read Alternative Subject Names from SSL certificates larger than 1024 bits
Antoine Pitrou added the comment: This should be fixed now. -- resolution: -> fixed stage: -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue13034> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13034] Python does not read Alternative Subject Names from some SSL certificates
Antoine Pitrou added the comment: (fixing the title) -- title: Python does not read Alternative Subject Names from SSL certificates larger than 1024 bits -> Python does not read Alternative Subject Names from some SSL certificates ___ Python tracker <http://bugs.python.org/issue13034> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13090] posix_read: memory leak
Changes by Antoine Pitrou : -- nosy: +haypo ___ Python tracker <http://bugs.python.org/issue13090> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13092] pep-393: memory leaks #2
Changes by Antoine Pitrou : -- nosy: +haypo ___ Python tracker <http://bugs.python.org/issue13092> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5001] Remove assertion-based checking in multiprocessing
Antoine Pitrou added the comment: Thank you. I've attached some comments, click on the "review" link to read them. -- assignee: jnoller -> nosy: +pitrou -BreamoreBoy stage: needs patch -> patch review versions: +Python 3.3 -Python 3.1 ___ Python tracker <http://bugs.python.org/issue5001> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12804] "make test" fails on systems without internet access
Antoine Pitrou added the comment: > > If it is easy to detect network availability programmatically, we could > > just use the skip system. > > +1. I don't know if there is a reasonable way to do this, but if so, that > would be the best solution. Actually, the skip system is already supposed to work for that if used properly (see test.support.transient_internet()). However, perhaps it actually doesn't work in all situations. -- ___ Python tracker <http://bugs.python.org/issue12804> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12911] Expose a private accumulator C API
Antoine Pitrou added the comment: New patch implementing Martin's suggested optimization (only instantiate the large list when necessary). -- Added file: http://bugs.python.org/file23299/accu3.patch ___ Python tracker <http://bugs.python.org/issue12911> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12911] Expose a private accumulator C API
Antoine Pitrou added the comment: > > That's another possibility. But we'd have to expose a > > C API anyway, and this one is as good as any other. > > No, it's not: it's additional clutter. If new API needs to be added, > adding it for existing structures is better. Notice that you don't > *need* new API, as you can use StringIO just fine from C also. Yes, but using StringIO without a dedicated C API is more tedious and quite slower. > > Note that StringIO will copy data twice (once when calling > > write(), once when calling getvalue()), while ''.join() only once (at > > the end, when concatenating all strings). > > Sounds like a flaw in StringIO to me. It could also manage a list of > strings that have been written, rather than only using a flat buffer. > Only when someone actually needs a linear buffer, it could convert it > (and use a plain string.join when getvalue is called and there is no > buffer at all). That's what I thought as well. However, that's probably too much for a bugfix release (and this issue is meant to allow test_bigmem to pass on 3.x). -- ___ Python tracker <http://bugs.python.org/issue12911> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12555] PEP 3151 implementation
Antoine Pitrou added the comment: > Should the input of OSError be checked? It could, but pre-PEP it is not, so I assumed it's better to minimize compatibility-breaking changes. -- ___ Python tracker <http://bugs.python.org/issue12555> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12555] PEP 3151 implementation
Changes by Antoine Pitrou : Added file: http://bugs.python.org/file23307/554524a74bbe.diff ___ Python tracker <http://bugs.python.org/issue12555> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12555] PEP 3151 implementation
Antoine Pitrou added the comment: Patch update against latest default. There shouldn't be anything interesting to see. -- ___ Python tracker <http://bugs.python.org/issue12555> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7689] Pickling of classes with a metaclass and copy_reg
Antoine Pitrou added the comment: +def __eq__(self, other): +r = (type(self) == type(other)) +if r: +return r I think this should be "if not r". -- ___ Python tracker <http://bugs.python.org/issue7689> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7689] Pickling of classes with a metaclass and copy_reg
Antoine Pitrou added the comment: Craig: I'm talking about the __eq__ version (durban's patch). The __cmp__ version is probably fine. -- ___ Python tracker <http://bugs.python.org/issue7689> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7689] Pickling of classes with a metaclass and copy_reg
Antoine Pitrou added the comment: No need, I'll do it myself. -- ___ Python tracker <http://bugs.python.org/issue7689> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7689] Pickling of classes with a metaclass and copy_reg
Antoine Pitrou added the comment: This is fixed now, thank you! -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: -Python 3.1 ___ Python tracker <http://bugs.python.org/issue7689> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Antoine Pitrou added the comment: Based on Amaury's report, I would suggest going forward integrating the xz module for configure-based systems, and letting someone else handle Windows integration later if a solution is found. -- ___ Python tracker <http://bugs.python.org/issue6715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13098] the struct module should support storage for size_t / Py_ssize_t C types
New submission from Antoine Pitrou : Title says it all. -- components: Library (Lib) messages: 144867 nosy: mark.dickinson, meador.inge, pitrou, skrah priority: normal severity: normal stage: needs patch status: open title: the struct module should support storage for size_t / Py_ssize_t C types type: feature request versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue13098> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13087] C BufferedReader seek() is inconsistent with UnsupportedOperation for unseekable streams
Antoine Pitrou added the comment: Committed, thanks! -- resolution: -> fixed stage: -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue13087> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12807] Optimization/refactoring for {bytearray, bytes, unicode}.strip()
Antoine Pitrou added the comment:
> The patch no longer applies cleanly. Is there enough interest in this to
> justify rebasing?
Yes, I think it's worth it.
--
title: Optimization/refactoring for {bytearray,bytes,unicode}.strip() ->
Optimization/refactoring for {bytearray, bytes, unicode}.strip()
___
Python tracker
<http://bugs.python.org/issue12807>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13070] segmentation fault in pure-python multi-threaded server
Antoine Pitrou added the comment: > > Also, is it ok to just return NULL or should the error state also be > > set? > > Well, I'm not sure, that why I made you and Amaury noisy :-) > AFAICT, this is the only case where _check_closed can encounter a NULL > self->writer. Probably. OTOH, not setting the error state when returning NULL is usually an error (and can result in difficult-to-debug problems), so let's stay on the safe side. > Furthermore, I'm not sure about what kind of error would make sense here. RuntimeError perhaps. -- ___ Python tracker <http://bugs.python.org/issue13070> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13063] test_concurrent_futures failures on Windows: IOError('[Errno 232] The pipe is being closed') on _send_bytes()
Antoine Pitrou added the comment: I think the solution would be to map ERROR_NO_DATA (232 - "The pipe is being closed") to EPIPE. Attached patch. -- keywords: +patch Added file: http://bugs.python.org/file23309/error_no_data.patch ___ Python tracker <http://bugs.python.org/issue13063> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13063] test_concurrent_futures failures on Windows: IOError('[Errno 232] The pipe is being closed') on _send_bytes()
Changes by Antoine Pitrou : -- components: +Tests nosy: +amaury.forgeotdarc stage: -> patch review type: -> behavior versions: +Python 3.2 ___ Python tracker <http://bugs.python.org/issue13063> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13099] Sqlite3 & turkish locale
Antoine Pitrou added the comment: Fixed, thank you. -- nosy: +pitrou resolution: -> fixed stage: test needed -> committed/rejected status: open -> closed versions: +Python 3.3 ___ Python tracker <http://bugs.python.org/issue13099> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13099] Sqlite3 & turkish locale
Antoine Pitrou added the comment: > Thanks, Antoine. Should I still try to write a regression test for it? I've had issues writing regression tests for other Turkish locale-related failures (namely, there are other bugs in some glibcs that could cause the test to fail anyway). I'm not sure it's worth it here. -- ___ Python tracker <http://bugs.python.org/issue13099> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13098] the struct module should support storage for size_t / Py_ssize_t C types
Changes by Antoine Pitrou : -- resolution: -> duplicate status: open -> closed superseder: -> module struct support for ssize_t and size_t ___ Python tracker <http://bugs.python.org/issue13098> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3163] module struct support for ssize_t and size_t
Antoine Pitrou added the comment: #3163 is a duplicate. -- nosy: +pitrou priority: low -> normal stage: patch review -> needs patch ___ Python tracker <http://bugs.python.org/issue3163> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3163] module struct support for ssize_t and size_t
Antoine Pitrou added the comment: Ooops, I meant #13098. -- ___ Python tracker <http://bugs.python.org/issue3163> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3163] module struct support for ssize_t and size_t
Antoine Pitrou added the comment: Here is a patch. -- Added file: http://bugs.python.org/file23310/struct_nn.patch ___ Python tracker <http://bugs.python.org/issue3163> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3163] module struct support for ssize_t and size_t
Antoine Pitrou added the comment: Thanks. I have answered one of your comments, and here is a new patch. -- Added file: http://bugs.python.org/file23311/struct_nn2.patch ___ Python tracker <http://bugs.python.org/issue3163> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3163] module struct support for ssize_t and size_t
Antoine Pitrou added the comment: New patch with cosmetic doc fix. -- Added file: http://bugs.python.org/file23312/struct_nn3.patch ___ Python tracker <http://bugs.python.org/issue3163> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7689] Pickling of classes with a metaclass and copy_reg
Antoine Pitrou added the comment: Yes, it will. -- ___ Python tracker <http://bugs.python.org/issue7689> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Antoine Pitrou added the comment: > > Based on Amaury's report, I would suggest going forward integrating > > the xz module for configure-based systems, and letting someone else > > handle Windows integration later if a solution is found. > > -1000. I feel quite strongly that this should not be added unless there > is also support in the Windows build process for it. Why? -- ___ Python tracker <http://bugs.python.org/issue6715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10348] multiprocessing: use SysV semaphores on FreeBSD
Antoine Pitrou added the comment: Agreed with Charles-François. -- nosy: +pitrou ___ Python tracker <http://bugs.python.org/issue10348> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Antoine Pitrou added the comment: > This module is only useful in the standard library if it is available > on all systems. Not really. xz is becoming a defacto standard under Linux (and perhaps other free Unices) while I guess it is marginal under Windows. We have other system-specific functionality, and nobody sees it as a bad thing. -- ___ Python tracker <http://bugs.python.org/issue6715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Antoine Pitrou added the comment: > That's because all system-specific functionality that we have really > depends on system features which just can't be available elsewhere. > For all functionality that in principle works on all systems, it also > actually works on all systems for Python. In cases where stuff was > only available on Linux even though it could work on other systems, > people *did* see it as a bad thing. Agreed, but it's a probably with the external library. That's like saying we are responsible if libffi fails building with the AIX compiler. -- ___ Python tracker <http://bugs.python.org/issue6715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Antoine Pitrou added the comment: > > That's because all system-specific functionality that we have really > > depends on system features which just can't be available elsewhere. > > For all functionality that in principle works on all systems, it also > > actually works on all systems for Python. In cases where stuff was > > only available on Linux even though it could work on other systems, > > people *did* see it as a bad thing. > > Agreed, but it's a probably with the external library. That's like > saying we are responsible if libffi fails building with the AIX > compiler. s/probably/problem/ ;) -- ___ Python tracker <http://bugs.python.org/issue6715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Antoine Pitrou added the comment: > I agree with Martin here. We should *NOT* have first and second class > OS support, if we can avoid it. The key word being "if we can avoid it". Jesus, if you are a Windows expert, your contribution is welcome. -- ___ Python tracker <http://bugs.python.org/issue6715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3163] module struct support for ssize_t and size_t
Antoine Pitrou added the comment: Thanks for the comments. Here is an updated patch. -- Added file: http://bugs.python.org/file23318/struct_nn4.patch ___ Python tracker <http://bugs.python.org/issue3163> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10141] SocketCan support
Antoine Pitrou added the comment: I don't have much to say about the patch, given that I don't know anything about CAN and my system doesn't appear to have a "vcan0" interface. I think it's ok to commit and refine later if something turns out insufficient. -- ___ Python tracker <http://bugs.python.org/issue10141> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10141] SocketCan support
Antoine Pitrou added the comment: > I had never heard about it before this issue, but the protocol is really > simple. > > If you want to try it out (just for fun :-), you just have to do the > following: > # modprobe vcan > # ip link add dev vcan0 type vcan > # ifconfig vcan0 up Ah, thanks! Can you add a comment about that in test_socket.py? I can confirm that all tests pass ok on my Linux system (kernel 2.6.38.8-desktop-5.mga). -- ___ Python tracker <http://bugs.python.org/issue10141> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13070] segmentation fault in pure-python multi-threaded server
Antoine Pitrou added the comment: The latest patch looks good to me. As for the error message, how about "the BufferedRWPair object is being garbage-collected". -- ___ Python tracker <http://bugs.python.org/issue13070> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7732] imp.find_module crashes Python if there exists a directory named "__init__.py"
Antoine Pitrou added the comment: This broke the Windows buildbots in Python 2.7. -- assignee: -> haypo ___ Python tracker <http://bugs.python.org/issue7732> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3163] module struct support for ssize_t and size_t
Antoine Pitrou added the comment: Thanks for the reviews! -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue3163> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13111] Error 2203 when installing Python/Perl?
Changes by Antoine Pitrou : -- nosy: +loewis ___ Python tracker <http://bugs.python.org/issue13111> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13115] tp_as_{number, sequence, mapping} can't be set using PyType_FromSpec
Changes by Antoine Pitrou : -- nosy: +amaury.forgeotdarc, loewis type: -> behavior versions: +Python 3.3 ___ Python tracker <http://bugs.python.org/issue13115> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12911] Expose a private accumulator C API
Antoine Pitrou added the comment: I added a comment insisting that the API is private and can be changed at any moment. StringIO can actually re-use that API, rather than the reverse. No need to instantiate a full-blown file object when all you want to do is to join a bunch of strings. -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue12911> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13063] test_concurrent_futures failures on Windows: IOError('[Errno 232] The pipe is being closed') on _send_bytes()
Antoine Pitrou added the comment: Hopefully this will fix the random failures (EPIPE is caught somewhere down in multiprocessing.Queue._feed). -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> pending ___ Python tracker <http://bugs.python.org/issue13063> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12823] Broken link in "SSL wrapper for socket objects" document
Antoine Pitrou added the comment: Fixed now. Hopefully the replacement resource is good enough. -- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue12823> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10141] SocketCan support
Antoine Pitrou added the comment: > Making the change in configure.in didn't lead to any change: no error > when I ran configure Did you run autoconf (or autoreconf) before? -- ___ Python tracker <http://bugs.python.org/issue10141> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13063] test_concurrent_futures failures on Windows: IOError('[Errno 232] The pipe is being closed') on _send_bytes()
Antoine Pitrou added the comment: Mmh, for some reason it seems it was not enough: http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/5328/steps/test/logs/stdio -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue13063> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12436] Missing items in installation/setup instructions
Antoine Pitrou added the comment: Oops. I just noticed this issue is not talking about the devguide, but the general docs. Please ignore the message above. -- ___ Python tracker <http://bugs.python.org/issue12436> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12436] Missing items in installation/setup instructions
Antoine Pitrou added the comment: > In addition to Notepad++ do you think it would be a good idea to at > least mention Vim and Emacs with a disclaimer about the learning curve? I'm a bit surprised. I would think the devguide is aimed are people who are *already* programmers, and have chosen their tools. Therefore I don't know how such material is useful, and the devguide is already hefty enough. -- nosy: +pitrou ___ Python tracker <http://bugs.python.org/issue12436> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13126] find() slower than rfind()
New submission from Antoine Pitrou :
With some gcc versions, str.find() is slower than str.rfind():
- 11.22 0.0 s="ABC"*33; ((s+"D")*500+s+"E").find(s+"E") (*100)
- 4.560.0 s="ABC"*33; ((s+"D")*500+"E"+s).find("E"+s) (*100)
- 6.710.0 s="ABC"*33; (s+"E") in ((s+"D")*300+s+"E") (*100)
- 11.22 0.0 s="ABC"*33; ((s+"D")*500+s+"E").index(s+"E") (*100)
- 11.52 0.0 s="ABC"*33; ((s+"D")*500+s+"E").partition(s+"E") (*100)
- 8.790.0 s="ABC"*33; ("E"+s+("D"+s)*500).rfind("E"+s) (*100)
- 3.860.0 s="ABC"*33; (s+"E"+("D"+s)*500).rfind(s+"E") (*100)
- 8.800.0 s="ABC"*33; ("E"+s+("D"+s)*500).rindex("E"+s) (*100)
- 9.800.0 s="ABC"*33; ("E"+s+("D"+s)*500).rpartition("E"+s) (*100)
- 9.830.0 s="ABC"*33; ("E"+s+("D"+s)*500).rsplit("E"+s, 1) (*100)
- 11.56 0.0 s="ABC"*33; ((s+"D")*500+s+"E").split(s+"E", 1) (*100)
Attached patch seems to fix it.
--
components: Interpreter Core
files: findperf.patch
keywords: patch
messages: 145136
nosy: haypo, pitrou
priority: low
severity: normal
status: open
title: find() slower than rfind()
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file23339/findperf.patch
___
Python tracker
<http://bugs.python.org/issue13126>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13063] test_concurrent_futures failures on Windows: IOError('[Errno 232] The pipe is being closed') on _send_bytes()
Antoine Pitrou added the comment: Ah, this is because IOError is raised because of WindowsError, thus there's no errno translation. Ok, I'd like to wait for PEP 3151 to be merged, then, because it should solve this. -- ___ Python tracker <http://bugs.python.org/issue13063> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11085] expose _abcoll as collections.abc
Antoine Pitrou added the comment: > > collections is one of those modules everyone will use in their code. > > Simply untrue, and definitely not in every program. It is also > irrelevant for bringing up the interactive interpreter, where there > initially is no user code and which should happen as fast as possible. I don't think a 50ms startup time is a problem for the interactive interpreter. Of course, it will be more noticeable on very slow machines. > I also doubt IDLE uses collections to bring up its shell window. The collections module appeared in 2.4; antiquated code might indeed not know about it ;) -- ___ Python tracker <http://bugs.python.org/issue11085> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13130] test_gdb: attempt to dereference a generic pointer
Antoine Pitrou added the comment: Following patch seems to fix it: diff --git a/Tools/gdb/libpython.py b/Tools/gdb/libpython.py --- a/Tools/gdb/libpython.py +++ b/Tools/gdb/libpython.py @@ -1152,7 +1152,7 @@ class PyUnicodeObjectPtr(PyObjectPtr): field_str = field_str.cast(_type_unsigned_char_ptr) elif repr_kind == 2: field_str = field_str.cast(_type_unsigned_short_ptr) -elif repr_kind == 3: +elif repr_kind == 4: field_str = field_str.cast(_type_unsigned_int_ptr) else: # Python 3.2 and earlier -- nosy: +pitrou ___ Python tracker <http://bugs.python.org/issue13130> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13130] test_gdb: attempt to dereference a generic pointer
Antoine Pitrou added the comment: Let's wait for the buildbots. -- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> pending ___ Python tracker <http://bugs.python.org/issue13130> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13130] test_gdb: attempt to dereference a generic pointer
Antoine Pitrou added the comment: Seems to have cleared the buildbot failures. -- status: pending -> closed ___ Python tracker <http://bugs.python.org/issue13130> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13125] test_all_project_files() expected failure
Antoine Pitrou added the comment:
Could you arrange to silence stdout/stderr in non-verbose mode?
$ ./python -m test -uall test_lib2to3
[1/1] test_lib2to3
ParseError on file /home/antoine/cpython/default/Lib/lib2to3/main.py bad input:
type=22, value='=', context=('', (81, 38))
ParseError on file
/home/antoine/cpython/default/Lib/lib2to3/tests/pytree_idempotency.py bad
input: type=22, value='=', context=('', (47, 33))
--- /home/antoine/cpython/default/Lib/lib2to3/tests/data/bom.py 2011-08-01
15:24:54.045209157 +0200
+++ @ 2011-10-08 20:31:41.981242859 +0200
@@ -1,2 +1,2 @@
-# coding: utf-8
+# coding: utf-8
print "BOM BOOM!"
1 test OK.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue13125>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13131] FD leak in urllib2
Changes by Antoine Pitrou : -- nosy: +orsenthil ___ Python tracker <http://bugs.python.org/issue13131> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13134] speed up finding of one-character strings
New submission from Antoine Pitrou :
In stringlib/fastsearch, instead of using our own loops, we can use memchr()
(and, if available, memrchr()) when looking for one-character strings. memchr()
is generally quite optimized; on this Linux/glibc machine, I get speedups of
5x-10x:
./python -m timeit -s "large='a'*1+'b'" "large.find('b')"
-> before: 10.5 usec per loop
-> after: 0.889 usec per loop
./python -m timeit -s "large='b'+'a'*1" "large.rfind('b')"
-> before: 7.06 usec per loop
-> after: 1.94 usec per loop
--
components: Interpreter Core
messages: 145186
nosy: haypo, loewis, pitrou
priority: normal
severity: normal
status: open
title: speed up finding of one-character strings
type: performance
versions: Python 3.3
___
Python tracker
<http://bugs.python.org/issue13134>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13134] speed up finding of one-character strings
Changes by Antoine Pitrou : -- keywords: +patch Added file: http://bugs.python.org/file23349/memchr.patch ___ Python tracker <http://bugs.python.org/issue13134> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13134] speed up finding of one-character strings
Antoine Pitrou added the comment: With MSVC there seems to be no difference, meaning Windows probably has a naïve memchr() implementation. -- ___ Python tracker <http://bugs.python.org/issue13134> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13134] speed up finding of one-character strings
Antoine Pitrou added the comment: New patch with a couple of tests. -- Added file: http://bugs.python.org/file23350/memchr2.patch ___ Python tracker <http://bugs.python.org/issue13134> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13136] speed-up conversion between unicode widths
New submission from Antoine Pitrou : This patch speeds up _PyUnicode_CONVERT_BYTES by unrolling its loop. Example micro-benchmark: ./python -m timeit -s "a='x'*1;b='\u0102'*1000;c='\U0010'" "a+b+c" -> before: 10 loops, best of 3: 14.9 usec per loop -> after: 10 loops, best of 3: 9.19 usec per loop -- components: Interpreter Core files: unroll_convert_bytes.patch keywords: patch messages: 145192 nosy: pitrou priority: normal severity: normal stage: patch review status: open title: speed-up conversion between unicode widths type: performance versions: Python 3.3 Added file: http://bugs.python.org/file23351/unroll_convert_bytes.patch ___ Python tracker <http://bugs.python.org/issue13136> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13136] speed-up conversion between unicode widths
Antoine Pitrou added the comment: > Before going further with this, I'd suggest you have a look at your > compiler settings. They are set by the configure script: gcc -pthread -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. -I./Include-DPy_BUILD_CORE -o Objects/unicodeobject.o Objects/unicodeobject.c > Such optimizations are normally performed by the > compiler and don't need to be implemented in C, making maintenance > harder. The fact that the glibc includes such optimization (in much more sophisticated form) suggests to me that many compilers don't perform these optimizations automically. > I tested using memchr() when writing those "naive" loops. memchr() is mentioned in another issue, #13134. > memchr() > is inlined by the compiler just like the direct loop I don't think so. If you look at the glibc's memchr() implementation, it's a sophisticated routine, not a trivial loop. Perhaps you're thinking about memcpy(). > and the generated > code for the direct version is often easier to optimize for the compiler > than the memchr() one, since it receives more knowledge about the used > data types. ?? Data types are fixed in the memchr() definition, there's no knowledge to be gained by inlining. -- ___ Python tracker <http://bugs.python.org/issue13136> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13134] speed up finding of one-character strings
Antoine Pitrou added the comment: > >> Before going further with this, I'd suggest you have a look at your > >> compiler settings. > > > > They are set by the configure script: > > > > gcc -pthread -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall > > -Wstrict-prototypes-I. -I./Include-DPy_BUILD_CORE -o > > Objects/unicodeobject.o Objects/unicodeobject.c > > Which gcc version are you using ? $ gcc -v Utilisation des specs internes. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-mageia-linux-gnu/4.5.2/lto-wrapper Target: x86_64-mageia-linux-gnu Configuré avec: ../configure --prefix=/usr --libexecdir=/usr/lib --with-slibdir=/lib64 --with-bugurl=http://bugs.mageia.org/ --mandir=/usr/share/man --infodir=/usr/share/info --enable-checking=release --enable-languages=c,c ++,ada,fortran,objc,obj-c++,java --build=x86_64-mageia-linux-gnu --host=x86_64-mageia-linux-gnu --with-cpu=generic --with-system-zlib --enable-threads=posix --enable-shared --enable-objc-gc --enable-long-long --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-gtk-cairo --disable-libjava-multilib --enable-ssp --disable-libssp --disable-werror --with-ppl --with-cloog --with-python-dir=/lib/python2.7/site-packages --enable-lto Modèle de thread: posix gcc version 4.5.2 (GCC) > Is it possible that you have -fno-builtin enabled ? Why would it be enabled? It is not on the command line. > >> Such optimizations are normally performed by the > >> compiler and don't need to be implemented in C, making maintenance > >> harder. > > > > The fact that the glibc includes such optimization (in much more > > sophisticated form) suggests to me that many compilers don't perform > > these optimizations automically. > > When using gcc, the glibc functions are usually not used at all, > since gcc comes with a (rather large) set of builtins which are > inlined directly, if you have optimizations enabled and inlining > is found to be more efficient than calling the glibc function: What would that change? Whether the optimized memchr() comes from gcc or the glibc is not relevant here. > There is: the compiler will have alignement information available and > can also benefit from using registers instead of the stack, knowledge > about processor cache lines, etc. Such information is lost when calling > a function. The function call itself will also create some overhead. > > BTW: You should not only test the optimization with long strings, but also > with short ones (e.g. 2-15 chars) - which is a much more common case > in practice. With very short strings, the runtimes tend to be identical, which is understandable. -- ___ Python tracker <http://bugs.python.org/issue13134> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13146] Writing a pyc file is not atomic
New submission from Antoine Pitrou : One of the buildbots recently showed the following failure: == ERROR: test_rapid_restart (test.test_multiprocessing.WithProcessesTestManagerRestart) -- Traceback (most recent call last): File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_multiprocessing.py", line 1442, in test_rapid_restart queue = manager.get_queue() File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/multiprocessing/managers.py", line 670, in temp token, exp = self._create(typeid, *args, **kwds) File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/multiprocessing/managers.py", line 568, in _create conn = self._Client(self._address, authkey=self._authkey) File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/multiprocessing/connection.py", line 778, in XmlClient import xmlrpc.client as xmlrpclib File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/xmlrpc/client.py", line 137, in import http.client File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/http/client.py", line 69, in import email.parser File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/email/parser.py", line 12, in from email.feedparser import FeedParser File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/email/feedparser.py", line 28, in from email import policy EOFError: EOF read where not expected (http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%203.x/builds/942/steps/test/logs/stdio) "EOF read where not expected" comes from reading a pyc file in marshal.c. It is raised when the pyc file is somehow truncated or incomplete. Writing and reading the same pyc file is protected by the import lock when in a single interpreter, but not when running several Python processes at the same time (which test_multiprocessing obviously does). Under POSIX, import.c could do the traditional write-then-rename dance which guarantees that the file contents appear atomically. And so could importlib. -- components: Interpreter Core messages: 145313 nosy: brett.cannon, ncoghlan, pitrou, r.david.murray priority: normal severity: normal status: open title: Writing a pyc file is not atomic type: behavior versions: Python 2.7, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue13146> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13148] simple bug in mmap size check
Antoine Pitrou added the comment: Well, you have to understand what this code does: it tries to prevent non-meaningful offsets. If the offset is equal to the file size, mapping from that offset would not map anything in the file (and the system call may actually fail). -- nosy: +pitrou resolution: -> invalid stage: -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue13148> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13149] optimization for append-only StringIO
New submission from Antoine Pitrou : io.StringIO is quite slower than ''.append() when used for mass concatenation (around 5x slower). This patch brings it to similar performance by deferring construction of the internal buffer until needed. The problem is that it's very easy to disable the optimization by calling a method other than write() and getvalue(). -- components: IO files: stringio.patch keywords: patch messages: 145322 nosy: haypo, pitrou priority: normal severity: normal status: open title: optimization for append-only StringIO type: performance versions: Python 3.3 Added file: http://bugs.python.org/file23373/stringio.patch ___ Python tracker <http://bugs.python.org/issue13149> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13148] simple bug in mmap size check
Antoine Pitrou added the comment: I don't think it makes sense to accept mmap'ing empty contents when at offset "n" but not at offset "n + 1". Either we remove the check entirely and let people deal with the consequences, or we keep the check as-is. -- nosy: +neologix stage: committed/rejected -> ___ Python tracker <http://bugs.python.org/issue13148> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13146] Writing a pyc file is not atomic
Antoine Pitrou added the comment: Here is a patch for import.c. -- keywords: +patch Added file: http://bugs.python.org/file23375/importrename.patch ___ Python tracker <http://bugs.python.org/issue13146> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13150] Most of Python's startup time is sysconfig
New submission from Antoine Pitrou :
sysconfig is imported and used by site.py.
$ time ./python -S -c ''
real0m0.019s
user0m0.013s
sys 0m0.005s
$ time ./python -S -c 'import sysconfig'
real0m0.047s
user0m0.046s
sys 0m0.002s
$ time ./python -S -c 'import sysconfig; sysconfig.get_path("purelib")'
real0m0.053s
user0m0.047s
sys 0m0.005s
$ time ./python -c ''
real0m0.058s
user0m0.054s
sys 0m0.003s
--
messages: 145328
nosy: eric.araujo, ncoghlan, pitrou, tarek, terry.reedy
priority: normal
severity: normal
status: open
title: Most of Python's startup time is sysconfig
type: performance
versions: Python 3.3
___
Python tracker
<http://bugs.python.org/issue13150>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Antoine Pitrou added the comment: > >> Modules/_lzmamodule.c:115: return _PyBytes_Resize(buf, size + BIGCHUNK); > > This has quadratic performance. > > Correct. I copied the algorithm from _io.FileIO, under the assumption > that there was a reason for not using a simpler O(n log n) doubling > strategy. Do you know of any reason for this? Or is it safe to ignore it? I don't know, but I'd say it's safe to ignore it. Maybe open a separate bug about that. Generally we use a less-than-doubling strategy, to conserve memory (see e.g. bytearray.c). (note: it is O(n), not O(n log n)) > >> Modules/_lzmamodule.c:364: Py_BEGIN_ALLOW_THREADS > > It seems that the Windows version at least is not thread-safe. If so, you > > would need an LZMA lock when releasing the GIL. > > Does the class need to be thread-safe, though? ISTM that there isn't any > sensible use case for having two threads feeding data through the same > compressor concurrently. We certainly want to avoid crashes so, if that's what one risks from using lzma from several threads, we should protect against it. -- ___ Python tracker <http://bugs.python.org/issue6715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13150] Most of Python's startup time is sysconfig
Antoine Pitrou added the comment: Actually, a big part of that is compiling some regexes in the tokenize module. Just relying on the re module's internal caching shaves off 20% of total startup time. Before: $ time ./python -S -c 'import tokenize' real0m0.034s user0m0.030s sys 0m0.003s $ time ./python -c '' real0m0.055s user0m0.050s sys 0m0.005s After: $ time ./python -S -c 'import tokenize' real0m0.021s user0m0.019s sys 0m0.001s $ time ./python -c '' real0m0.044s user0m0.038s sys 0m0.006s -- ___ Python tracker <http://bugs.python.org/issue13150> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10976] json.loads() throws TypeError on bytes object
Antoine Pitrou added the comment: > I'll just mention that the elimination of bytes handling is a bit > unfortunate, since this idiom which works in Python 2 no longer works: > > fp = urlopen(url) > json_data = json.load(fp) What if the returned JSON uses a charset other than utf-8 ? -- ___ Python tracker <http://bugs.python.org/issue10976> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13150] Most of Python's startup time is sysconfig
Antoine Pitrou added the comment: > I am curious: wouldn't be a way of keeping the compiled expressions in > a static cache somewhere, so we would compile them just once and have > both import time and runtime fast ? Runtime shouldn't be affected. The re module has its own LRU caching. That said, it seems regular expressions are pickleable: b'\x80\x03cre\n_compile\nq\x00X\x00\x00\x00\x00q\x01K \x86q\x02Rq\x03.' -- ___ Python tracker <http://bugs.python.org/issue13150> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13150] Most of Python's startup time is sysconfig
Antoine Pitrou added the comment:
Arg damn roundup e-mail gateway.
I wanted to paste:
>>> pickle.dumps(re.compile(''))
b'\x80\x03cre\n_compile\nq\x00X\x00\x00\x00\x00q\x01K \x86q\x02Rq\x03.'
--
___
Python tracker
<http://bugs.python.org/issue13150>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13150] Most of Python's startup time is sysconfig
Antoine Pitrou added the comment: Pre-parsing and building a cached module of built-time variables (from Makefile and pyconfig.h) under POSIX also removes more than 15% of startup time. Patch attached. -- keywords: +patch Added file: http://bugs.python.org/file23377/sysconfigdata.patch ___ Python tracker <http://bugs.python.org/issue13150> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13134] speed up finding of one-character strings
Antoine Pitrou added the comment: I went ahead and committed. -- resolution: -> fixed stage: -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue13134> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13136] speed-up conversion between unicode widths
Antoine Pitrou added the comment: Patch committed. It is of course still not as fast as memcpy, but it's a small step towards improving performance. -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue13136> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13146] Writing a pyc file is not atomic
Antoine Pitrou added the comment: This new patch also fixes importlib. -- stage: -> patch review versions: -Python 2.7 Added file: http://bugs.python.org/file23378/importrename2.patch ___ Python tracker <http://bugs.python.org/issue13146> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13154] pep-0000.txt doesn't build anymore
New submission from Antoine Pitrou : $ make make: Dépendance circulaire pep-.txt <- pep-.txt abandonnée. python genpepindex.py . Traceback (most recent call last): File "genpepindex.py", line 67, in main(sys.argv) File "genpepindex.py", line 64, in main write_pep0(peps, pep0_file) File "/home/antoine/cpython/peps/pep0/output.py", line 195, in write_pep0 authors_dict = verify_email_addresses(peps) File "/home/antoine/cpython/peps/pep0/output.py", line 104, in verify_email_addresses "listed:\n" + '\n'.join(err_output)) ValueError: some authors have more than one email address listed: Gregory Ewing: [u'g...@cosc.canterbury.ac.nz', u'greg.ew...@canterbury.ac.nz'] make: *** [pep-.txt] Erreur 1 -- assignee: docs@python components: Documentation messages: 145370 nosy: docs@python, pitrou priority: normal severity: normal status: open title: pep-.txt doesn't build anymore type: compile error ___ Python tracker <http://bugs.python.org/issue13154> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13146] Writing a pyc file is not atomic
Antoine Pitrou added the comment: > So if a process replaces the PYC file whereas another is reading the > PYC, the reader may read corrupted data? No, this is the whole point of the patch. -- ___ Python tracker <http://bugs.python.org/issue13146> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13155] Optimize finding the max character width
New submission from Antoine Pitrou : This patch optimizes scanning for the max character width in an unicode buffer. Micro-benchmarking some worst case situations: $ ./python -m timeit -s "x='é'+'x'*10" "x[1:]" -> before: 1 loops, best of 3: 74.9 usec per loop -> after: 10 loops, best of 3: 15.5 usec per loop $ ./python -m timeit -s "x='\U0001'+'x'*10" "x[1:]" -> before: 1 loops, best of 3: 138 usec per loop -> after: 1 loops, best of 3: 71.3 usec per loop -- components: Interpreter Core files: find_max_char.patch keywords: patch messages: 145372 nosy: pitrou priority: normal severity: normal status: open title: Optimize finding the max character width type: performance versions: Python 3.3 Added file: http://bugs.python.org/file23379/find_max_char.patch ___ Python tracker <http://bugs.python.org/issue13155> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13155] Optimize finding the max character width
Antoine Pitrou added the comment: I hadn't noticed the STRINGLIB_SIZEOF_CHAR constant. Reuse it instead of adding STRINGLIB_CHAR_SIZE. -- Added file: http://bugs.python.org/file23380/find_max_char2.patch ___ Python tracker <http://bugs.python.org/issue13155> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
