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 wit
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
Change by Antoine Pitrou :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Antoine Pitrou added the comment:
How about:
#ifdef __cplusplus
char array[1];
#else
char array[];
#endif
?
--
___
Python tracker
<https://bugs.python.org/issue40
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 track
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:
&g
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
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/issue13
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 su
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_
Changes by Antoine Pitrou :
--
nosy: +mark.dickinson, skrah
___
Python tracker
<http://bugs.python.org/issue13072>
___
___
Python-bugs-list mailing list
Unsub
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:
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
&l
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 offl
Antoine Pitrou added the comment:
This should be fixed now.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
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
___
Pyt
Changes by Antoine Pitrou :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue13090>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue13092>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
_
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
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.py
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 st
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
Changes by Antoine Pitrou :
Added file: http://bugs.python.org/file23307/554524a74bbe.diff
___
Python tracker
<http://bugs.python.org/issue12555>
___
___
Python-bug
Antoine Pitrou added the comment:
Patch update against latest default. There shouldn't be anything interesting to
see.
--
___
Python tracker
<http://bugs.python.org/is
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.
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.
Antoine Pitrou added the comment:
No need, I'll do it myself.
--
___
Python tracker
<http://bugs.python.org/issue7689>
___
___
Python-bugs-list mailing list
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.o
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.
--
___
P
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
Antoine Pitrou added the comment:
Committed, thanks!
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
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 {by
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-
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
Changes by Antoine Pitrou :
--
components: +Tests
nosy: +amaury.forgeotdarc
stage: -> patch review
type: -> behavior
versions: +Python 3.2
___
Python tracker
<http://bugs.python.org/i
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.or
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&#x
Changes by Antoine Pitrou :
--
resolution: -> duplicate
status: open -> closed
superseder: -> module struct support for ssize_t and size_t
___
Python tracker
<http://bugs.python.or
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/
Antoine Pitrou added the comment:
Ooops, I meant #13098.
--
___
Python tracker
<http://bugs.python.org/issue3163>
___
___
Python-bugs-list mailing list
Unsub
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/issue3
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/issue3
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/issue3
Antoine Pitrou added the comment:
Yes, it will.
--
___
Python tracker
<http://bugs.python.org/issue7689>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
Antoine Pitrou added the comment:
Agreed with Charles-François.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue10348>
___
___
Python-bugs-list m
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-sp
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
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
> >
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 contrib
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/issue3
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 so
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
> # ifcon
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.o
Antoine Pitrou added the comment:
This broke the Windows buildbots in Python 2.7.
--
assignee: -> haypo
___
Python tracker
<http://bugs.python.org/iss
Antoine Pitrou added the comment:
Thanks for the reviews!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Changes by Antoine Pitrou :
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue13111>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
nosy: +amaury.forgeotdarc, loewis
type: -> behavior
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issu
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
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
_
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.or
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.
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
&l
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/issue12
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
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
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 trac
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 cod
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
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.pyth
Antoine Pitrou added the comment:
Seems to have cleared the buildbot failures.
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issu
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
Changes by Antoine Pitrou :
--
nosy: +orsenthil
___
Python tracker
<http://bugs.python.org/issue13131>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
Changes by Antoine Pitrou :
--
keywords: +patch
Added file: http://bugs.python.org/file23349/memchr.patch
___
Python tracker
<http://bugs.python.org/issue13
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/issue13
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/issue13
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
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_BU
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 -
New submission from Antoine Pitrou :
One of the buildbots recently showed the following failure:
==
ERROR: test_rapid_restart
(test.test_multiprocessing.WithProcessesTestManagerRestart
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
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
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.
--
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/issue13
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
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 sim
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
user
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 char
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
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
<h
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
Antoine Pitrou added the comment:
I went ahead and committed.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
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: ope
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/issu
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 m
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/i
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
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.py
1 - 100 of 16792 matches
Mail list logo
