Antoine Pitrou added the comment:
Fixed!
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue9902>
___
___
Pyth
Antoine Pitrou added the comment:
The fix succeeded on the "sparc Debian 3.x" buildbot while test_subprocess had
been failing consistently before.
--
___
Python tracker
<http://bugs.python.
New submission from Antoine Pitrou :
test_concurrent_futures writes the following on stderr:
exception calling callback for
Traceback (most recent call last):
File
"/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/concurrent/futures/_base.py",
line 267, in _invoke
Antoine Pitrou added the comment:
test_subprocess now succeeds on all 3.x buildbots. Will backport and then close.
--
resolution: -> fixed
status: open -> pending
___
Python tracker
<http://bugs.python.org/
Antoine Pitrou added the comment:
The new test case fails on (FreeBSD, OS X) buildbots:
==
ERROR: test_font_eq (tkinter.test.test_tkinter.test_font.FontTest
Antoine Pitrou added the comment:
> Antoine also suggested it might be the particular version of sqlite in
> use on the buildbot, but I don't currently know what version that is.
> Bill, can you clue me in?
You could simply print out sqlite3.sqlite_version at the beginning o
Changes by Antoine Pitrou :
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue8432>
___
___
Python-bugs-list mailing list
Unsubscri
Antoine Pitrou added the comment:
It is similar, but the issue is slightly different. Fixing issue1856 with the
proposed resolution (the "stay_forever" flag) won't solve this, because the GIL
mutex will still refuse to be destroyed if other threads reference it at
Antoine Pitrou added the comment:
Moving the _PyEval_FiniThreads() call to Py_Initialize() solves the issue:
diff -r 9e49082da463 Python/pythonrun.c
--- a/Python/pythonrun.cMon Sep 20 12:46:56 2010 +0200
+++ b/Python/pythonrun.cMon Sep 20 13:41:47 2010 +0200
@@ -217,8 +217,15
Antoine Pitrou added the comment:
See #9901 for a variation on the same global issue (running threads can access
interpreter structures - the GIL - while the main thread is trying to destroy
them).
--
___
Python tracker
<http://bugs.python.
Antoine Pitrou added the comment:
> >On the other hand, this begs the question of why you want to access
> >the Python makefile at all. Is there any information in there that
> >isn't currently exposed? I think it would be nice if people could
> >completely forge
Antoine Pitrou added the comment:
Patch works here (Mandriva Linux).
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue9899>
___
___
Python-bug
Antoine Pitrou added the comment:
> Quote msg83564 "This is still a good idea.", in which case shouldn't
> someone push this forward, failing that close as out of date?
Just because someone doesn't "push this forward
Antoine Pitrou added the comment:
> Gah. I reviewed patch4, didn't noticed today's update :(
Oops, I'm sorry for that. It turns out most of your comments are useful anyway.
> Why is it a good thing to make file a keyword only parameter?
I was thinking that if we want
Antoine Pitrou added the comment:
Here is an update of the patch against current py3k. I've added a copyright
mention at the top of Modules/bz2module.c which I hope manages to capture the
essence of msg93721. Martin, what do you think?
--
nosy: +loewis
stage: -> patc
Antoine Pitrou added the comment:
Committed in r84927.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> pending
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
> This is the patch I'm thinking of. I confirmed this works
> on VS8.0. (After replaced "..\\.." with "..\\..\\..")
Works here too (VS 2008)!
--
___
Python tracker
&l
Antoine Pitrou added the comment:
> If there is a problem with multiple libraries, I'd like to reiterate
> my support for migrating to NSS.
Will your support go so far as to investigate feasibility and provide a
patch?
--
___
Python tra
Changes by Antoine Pitrou :
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue9901>
___
___
Python-bugs-list mailing list
Unsubscri
New submission from Antoine Pitrou :
Under Windows 7, there is another path in posixmodule.c for stat() (because of
the link dereferencing feature, it seems). This path fails for the bytes
version. It turns out that GetFinalPathNameByHandleA returns a value which is
one byte too small (while
Antoine Pitrou added the comment:
> Has the patch been tested on WinXP to be sure it does not introduce a
> bug for this?
No. Can you?
--
___
Python tracker
<http://bugs.python.org/
Antoine Pitrou added the comment:
You must also update Modules/getpath.c.
You should also add documentation.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue9
Antoine Pitrou added the comment:
> On this issue, I would much rather see email package to start using
> datetime objects to represent time rather than named or unnamed tuples.
I agree on the principle, but I don't know if it's acceptable with regards to
compatibility. It&#
Antoine Pitrou added the comment:
> Well, I noticed py3k_openssl.patch can suppress rebuild
> of OpenSSL nicely, but from IDE, _ssl and _hashlib
> are always rebuilt. It doesn't take so much time though.
>
> With py3k_openssl_v2.patch, we can supress OpenSSL and
> python
Antoine Pitrou added the comment:
Ok, committed in r84946 (3.2), r84947 (3.1) and r84948 (2.7). Thank you!
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
versions: -Python 2.6
___
Python track
Antoine Pitrou added the comment:
It's a pity that flush() is defined like this. Ideally, if mmap claims to
mimick ordinary file objects, flush() should be a no-op() and there should be a
separate sync() method.
On the other hand, your (Charles-François's) patch is already much b
Antoine Pitrou added the comment:
Interestingly, the matter was discussed on another issue, #2643. I also agree
that ideally flush() should become a no-op (only in 3.2, since it would break
compatibility). But then we should also expose a separate sync() method with
the current behaviour
Antoine Pitrou added the comment:
I notice that there's support in #678250 for making flush() a no-op.
We should still fix tp_dealloc anyway.
--
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
> I agree that calling msync on close/dealloc is not really necessary.
> The Windows version doesn't sync, either.
Ok, thank you. I committed the patch in r84950.
--
___
Python tracker
<http://b
Changes by Antoine Pitrou :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue2643>
___
___
Python-bugs-list
Antoine Pitrou added the comment:
Patch committed in r84952. Thanks!
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> pending
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
Ok, I committed the patch in r84956. Thank you for testing.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Changes by Antoine Pitrou :
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue9899>
___
___
Python-bugs-list mailing list
Unsubscri
Antoine Pitrou added the comment:
Looks rather nice. I don't think there's any point in micro-optimizations such
as stack_keys.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.
Antoine Pitrou added the comment:
A couple of comments:
- what is `str(self.get_param('charset', 'ascii'))` supposed to achieve? does
get_param() return a bytes object?
- instead of ascii+surrogateescape, you could simply use latin1
Antoine Pitrou added the comment:
See issue7606 and issue7605: both fixed in SVN. All is needed is a new 3.1.x
release :)
--
nosy: +pitrou
resolution: -> out of date
status: open -> closed
versions: +Python 3.2
___
Python tracker
Changes by Antoine Pitrou :
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue9922>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Thank you very much! I have kept the second approach (use PaddedFile at all
times), since it is more regular and minimizes the probability for borderline
cases.
As for the supposed performance slowdown, it doesn't seem significant. On large
blocks of da
Antoine Pitrou added the comment:
Yes, unescaped utf-8 is explicitly allowed in headers by RFC 3977:
The content of a header SHOULD be in UTF-8. However, if an
implementation receives an article from elsewhere that uses octets in
the range 128 to 255 in some other manner, it MAY pass
New submission from Antoine Pitrou :
I haven't investigated but this is weird (especially the fact that it doesn't
*always* happen). There might be a problem with SETUP_WITH or perhaps the
method cache:
>>> import bz2
>>> f = bz2.BZ2File('foo.bz2', '
Antoine Pitrou added the comment:
Actually, it is because bz2 doesn't call PyType_Ready() but instead sets some
field manually. Perhaps we could have a guard somewhere that raises a fatal
error when a C extension type hasn't been properly readied?
In the meantime, this patch seem
Antoine Pitrou added the comment:
Patch committed in r84980 (3.2), r84981 (3.1) and r84982 (2.7).
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Antoine Pitrou added the comment:
Adding Michael for review of py3k_fix__AssertRaisesContext.patch.
--
nosy: +michael.foord
___
Python tracker
<http://bugs.python.org/issue9
Antoine Pitrou added the comment:
Here is a fixed version of Victor's bench (didn't work on 2.x).
--
Added file: http://bugs.python.org/file18983/bench_pickle.py
___
Python tracker
<http://bugs.python.
Antoine Pitrou added the comment:
And here is new performance patch (Victor's patch was outdated because of heavy
changes incorporated from Unladen Swallow). Results of bench_pickle.py are as
follows:
* Python 2.7 (cPickle):
Protocol 0
- dump: 189.8 ms
- load (seekable=False): 318
Antoine Pitrou added the comment:
The pid_t issue was fixed but not uid_t/gid_t.
--
___
Python tracker
<http://bugs.python.org/issue2005>
___
___
Python-bug
New submission from Antoine Pitrou :
This is a bunch of assorted optimizations which make pickling of user-defined
classes quite a bit faster.
Example on a minimal instance:
$ python -m timeit -s "import pickle; import collections, __main__;
__main__.X=type('X', (), {}); x=X()
Antoine Pitrou added the comment:
>It is not possible to set Py_FilesystemDefaultEncoding before loading
>the first module. initfsencoding() loads codecs and encodings modules to
>check the codec name.
Not sure it's related, but there seems to be a bug:
$ ./python -c &quo
Antoine Pitrou added the comment:
Some things about your patch:
- as Amaury said, functions should be named "redecode*" rather than "reencode*"
- please use -1 for error return, not 1
- have you tried to measure if it made P
Changes by Antoine Pitrou :
--
resolution: -> duplicate
status: open -> closed
superseder: -> AIX shared library fix
___
Python tracker
<http://bugs.python.org/
Changes by Antoine Pitrou :
--
nosy: +brett.cannon, loewis
___
Python tracker
<http://bugs.python.org/issue9630>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
I'm not really able to review this kind of things. Please commit if you think
it is ok.
--
___
Python tracker
<http://bugs.python.org/i
Changes by Antoine Pitrou :
--
nosy: +brian.curtin, haypo, tim.golden
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6
___
Python tracker
<http://bugs.python.org/issue9
Antoine Pitrou added the comment:
You are right that it doesn't work anymore (under Linux too).
Your patch is almost ok. It should raise a ValueError if bufsize=0 and
universal_newlines is true (the two can't be satisfied together, since
universal newlines implies buffering).
It
Antoine Pitrou added the comment:
As another sidenote, `bufsize` should only be relevant for stdin. For stdout
and stderr, disabling buffering will only reduce performance, not add
functionality. So I would suggest only setting buffering on stding
Changes by Antoine Pitrou :
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue9935>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Patch looks ok, and it would hopefully fix build errors on the XP buildbots :)
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue9
New submission from Antoine Pitrou :
While writing tests for nntplib, it came to me that a PipeIO or BytesPipeIO
would be useful (I actually wrote a minimal one). It would be a non-seekable
in-memory bytes buffer with distinct read and write pointers, so as to act like
a system FIFO or a
Antoine Pitrou added the comment:
Note that the original issue (test_tarfile failures on the Windows buildbots)
now seems fixed thanks to the various tarfile and test_tarfile improvements.
I have no opinion on whether assertRaises should take care of cleaning the
tracebacks or not. As the
Antoine Pitrou added the comment:
> > It would be a non-seekable in-memory bytes buffer with distinct
> > read and write pointers, so as to act like a system FIFO or a
> > socket.makefile() object.
>
> What would it do when the equivalent system FIFO object wou
New submission from Antoine Pitrou :
Under 3.2 and 3.1:
>>> with open("foo", "wb") as x: pass
...
>>> with open("foo", "wb") as (x, y): pass
...
Traceback (most recent call last):
File "", line 1, in
io.UnsupportedOperati
Antoine Pitrou added the comment:
> > Simply buffer everything.
>
> That works for when a write operation would block. What would it do
> when a read operation would block?
Good question. It could either return an empty bytes object, or perhaps
raise EOFError (it could b
Antoine Pitrou added the comment:
> The _multiprocessing module already have similar objects.
> _multiprocessing.Connection is based on file descriptors (and initialized
> with the result of os.pipe())
> _multiprocessing.PipeConnection uses Windows named pipes.
_multiprocessin
Antoine Pitrou added the comment:
> Another option would be to have the read-end act like a non-blocking
> socket (i.e., raise EAGAIN).
>
> Since it would mostly be for testing, would it make more sense to add
> it to test.support or someplace similar instead of io?
I thou
Antoine Pitrou added the comment:
Ah, thank you. I hadn't tested in debug mode and there was a wrong assert from
the previous code.
Here is a patch with the assert removed.
--
versions: +Python 3.2 -Python 3.1
Added file: http://bugs.python.org/file19000/unpickleprefetch2.
Antoine Pitrou added the comment:
Here is a patch adding tests for article(), head() and body(), as well as for
the "file" parameter.
As far as code is concerned, this should now be complete. Documentation remains
to be updated :)
--
Added file: http://bugs.python.org
Antoine Pitrou added the comment:
> Answering the question as best I can: I don't know how the reference
> counter is implemented in CPython, but if it's just a field in a
> struct, then madvise could be sent the memory location starting with
> the byte immediately f
Antoine Pitrou added the comment:
> EAGAIN can be raised too. I never experienced this error condition
> myself in pyftpdlib
>From the accept() man page:
EAGAIN or EWOULDBLOCK
The socket is marked nonblocking and no connections are
present to be
Changes by Antoine Pitrou :
--
nosy: +pmoore
type: -> crash
___
Python tracker
<http://bugs.python.org/issue9931>
___
___
Python-bugs-list mailing list
Un
Changes by Antoine Pitrou :
--
nosy: +db3l
___
Python tracker
<http://bugs.python.org/issue8445>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
nosy: +db3l
___
Python tracker
<http://bugs.python.org/issue8423>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> The point of frameworks such as asyncore and twisted is to hide all
> system-specific errors as much as possible and provide a portable
> interface across all platforms.
As long as these errors are reasonably explainable.
If a strange error only oc
Antoine Pitrou added the comment:
> One other thought. If there is a perceived need, I would rather an
> alternate approach that unifies a language a bit by letting range()
> expose its arguments as a slice and modify its input to accept a slice.
This sounds like an obscure complicat
Antoine Pitrou added the comment:
> > Well, first, this would only work for large objects. [...]
> > Why do you think you might have such duplication in your workload?
>
> Some of the projects with which I work involve multiple manipulations
> of large datasets. Often,
Antoine Pitrou added the comment:
And here is a patch integrating doc fixes and updates.
--
Added file: http://bugs.python.org/file19011/nntplib_cleanup7.patch
___
Python tracker
<http://bugs.python.org/issue9
Changes by Antoine Pitrou :
--
nosy: +gpolo
___
Python tracker
<http://bugs.python.org/issue8445>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Antoine Pitrou :
This was introduced by r74426 which addressed issue1628205. socket.sendall()
calls PyErr_CheckSignals() (and potentially returns to the caller) without
having the GIL.
>>> import socket
>>> c, s = socket.socketpair()
>>> s.senda
Antoine Pitrou added the comment:
The fix is very simple, but perhaps a test should be added.
diff -r af0d7b32d6ce Modules/socketmodule.c
--- a/Modules/socketmodule.cFri Sep 24 20:03:12 2010 +0200
+++ b/Modules/socketmodule.cSat Sep 25 21:09:58 2010 +0200
@@ -2581,8 +2581,8
Antoine Pitrou added the comment:
Actually, the patch is enough to suppress the crash, but sendall() behaviour is
buggy in another way: EINTR may be received as part of the select() call (on
sockets with a timeout), in which case the loop will be exited early instead of
retrying, losing
Antoine Pitrou added the comment:
Oh, and an additional bug is that send() can return a successful partial write
when it was actually interrupted by a signal.
--
___
Python tracker
<http://bugs.python.org/issue9
Antoine Pitrou added the comment:
Here is a patch fixing the aforementioned issues, and with tests.
--
keywords: +patch
nosy: +exarkun
Added file: http://bugs.python.org/file19015/sendallinterrupt.patch
___
Python tracker
<http://bugs.python.
Antoine Pitrou added the comment:
The patch compiles fine under Linux, but please don't use tabs for indentation
of C files.
--
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
Actually, most buildbots were fixed but a couple of them still show a problem:
test_font_eq (tkinter.test.test_tkinter.test_font.FontTest) ... ERROR
testLoadTk (tkinter.test.test_tkinter.test_loadtk.TkLoadTest) ... skipped 'No
$DISPLAY set.'
testLoa
Antoine Pitrou added the comment:
Here is Guilherme's patch converted for py3k.
--
nosy: +pitrou
Added file: http://bugs.python.org/file19024/ttk3k.patch
___
Python tracker
<http://bugs.python.org/i
Changes by Antoine Pitrou :
--
nosy: +gpolo
___
Python tracker
<http://bugs.python.org/issue9673>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
nosy: +gpolo
___
Python tracker
<http://bugs.python.org/issue8716>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
nosy: +ghaering
versions: +Python 3.2 -Python 2.7
___
Python tracker
<http://bugs.python.org/issue9954>
___
___
Python-bugs-list m
Changes by Antoine Pitrou :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue9951>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Committed in r85018, will watch the buildbots.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> pending
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
There's an issue remaining on the buildbots:
==
FAIL: test_heading_callback (tkinter.test.test_ttk.test_widgets.Treevie
Antoine Pitrou added the comment:
Patch committed in r85032. I'm gonna watch the buildbots a bit, in case the
test fails on some platforms.
--
assignee: -> pitrou
resolution: -> fixed
stage: -> committed/rejected
___
Python
Antoine Pitrou added the comment:
The patch passes at least on Linux, OS X and Solaris buildbots. Backported to
3.1 (r85034) and 2.7 (r85035).
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/iss
Antoine Pitrou added the comment:
> But if line buffering doesn't work, disabling buffering on
> stdout/stderr does have a functional consequence: it allows process
> output to appear as generated instead of coming in chunks when the
> buffer is full
Yes, sorry, I had i
Antoine Pitrou added the comment:
One problem with the seek() approach is that some file-like objects have
expensive seeks. One example is GzipFile, where seek(n) is O(n) (it first
rewinds to the start of file, then reads n decompressed bytes). In the end,
unpickling from a GzipFile becomes
New submission from Antoine Pitrou :
GzipFile claims to implement BufferedIOBase but doesn't have peek().
--
components: Library (Lib)
messages: 117476
nosy: nirai, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: GzipFile doesn't have peek()
typ
Antoine Pitrou added the comment:
> Didn't Victor say that only one seek at the end is necessary per
> pickle? If this is the case, I don't think expensive seeks will be an
> issue.
If you are unpickling from a multi-megabyte gzip file and the seek at
the end makes you unco
Antoine Pitrou added the comment:
Here is an update bench_pickle which also makes the file unpeekable.
--
Added file: http://bugs.python.org/file19033/bench_pickle.py
___
Python tracker
<http://bugs.python.org/issue3
Changes by Antoine Pitrou :
Removed file: http://bugs.python.org/file18241/bench_pickle.py
___
Python tracker
<http://bugs.python.org/issue3873>
___
___
Python-bugs-list m
Changes by Antoine Pitrou :
Removed file: http://bugs.python.org/file18983/bench_pickle.py
___
Python tracker
<http://bugs.python.org/issue3873>
___
___
Python-bugs-list m
Antoine Pitrou added the comment:
Here is a patch using peek() rather than seek(). There are some inefficiencies
around (such as using read() to skip the consumed prefetched bytes), but the
benchmark results are still as good as with seek():
Protocol 0
- dump: 142.5 ms
- load (seekable=False
1701 - 1800 of 16792 matches
Mail list logo
