Changes by Antoine Pitrou :
--
nosy: +amaury.forgeotdarc
___
Python tracker
<http://bugs.python.org/issue7862>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
nosy: +lemburg
___
Python tracker
<http://bugs.python.org/issue7863>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> I'm not sure what such a test would prove, e.g. on 64-bit Mac OS X,
> platform.machine() return 'i386'. That could be mapped to 'x86'...
You're right. There doesn't seem to be much consistency accross
platfo
Antoine Pitrou added the comment:
Fixed!
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
type: -> behavior
versions: +Python 3.2
___
Python tracker
<http://bugs.pytho
New submission from Antoine Pitrou :
An interesting bug failure on one of the buildbots. It seems importlib has been
enabled as the default import mechanism (when? where?).
test_multiprocessing
Process Process-24:
Traceback (most recent call last):
File
"/home/buildbot/slave/py-buil
Antoine Pitrou added the comment:
There are still random failures:
test test_logging failed -- Traceback (most recent call last):
File "/home2/buildbot/slave/trunk.loewis-sun/build/Lib/test/test_logging.py",
line 1612, in test_listen_config_10_ok
], stream=output)
Fi
Antoine Pitrou added the comment:
> That would be test_support.import_module, which at your recommendation
> I changed to use importlib.import_module at the last pycon sprint :)
I don't think it's the culprit. According to the traceback, importlib is
triggered by
Antoine Pitrou added the comment:
Option 3 is ok with me.
There could also be option 4: add a special flag (or environment var) to
regrtest so as to run all tests with __import__ pulled from importlib. Then we
can setup a buildbot with that flag / env var
Changes by Antoine Pitrou :
--
nosy: +brett.cannon, lemburg
priority: normal -> release blocker
___
Python tracker
<http://bugs.python.org/issue6608>
___
___
Py
Antoine Pitrou added the comment:
It's not only getrandbits():
** x86 **
>>> random.seed(b'foo')
>>> random.random()
0.95824312997798622
** x86_64 **
>>> random.seed(b'foo')
>>> random.random()
0.88694660946819537
--
Antoine Pitrou added the comment:
It works when seeding from a single integer, though:
>>> import random
>>> random.seed(123)
>>> random.random()
0.052363598850944326
So I guess it's the seeding-from-an-array which is buggy.
--
__
Antoine Pitrou added the comment:
Ok, it's simple really. When seeding from something else than an integer,
seed() takes the hash of the object (instead of considering all its bytes,
which might be considered a weakness since you lose entropy -- also, Python
hash() is not supposed
Antoine Pitrou added the comment:
Well, ideally we should drop the automatic hash() and only accept:
1) ints/longs
2) buffer-like objects
(and tell people to hash() explicitly if they want to)
If that's too disruptive, we should document it.
And, for 3.x, provide the following recipe to
Antoine Pitrou added the comment:
Why would sys.executable be a directory?
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue7880>
___
___
Pytho
Antoine Pitrou added the comment:
The `time` module is written in C, in Modules/timemodule.c.
If this is too bothersome to write in C, the function could perhaps be added to
the datetime module instead.
In any case, we need a proper patch, including unit tests if possible.
(and I agree that
Antoine Pitrou added the comment:
Committed in r78123 (py3k) and r78124 (3.1). I've also removed _escape_cdata()
since it wasn't used anymore. Thanks Jerry for the patch.
--
resolution: -> fixed
stage: -> committed/rejected
status
Antoine Pitrou added the comment:
As already mentioned, the backport patch isn't up to date.
--
___
Python tracker
<http://bugs.python.org/issue5223>
___
___
Antoine Pitrou added the comment:
I've committed the patch in r78125 (trunk) and r78126 (py3k). I'm not sure I
want to backport it to 2.6/3.1, since it might bite people who relied on the
old behaviour.
--
resolution: -> accepted
stage: patch review -> committed
Antoine Pitrou added the comment:
Given the size of the patch, it's very difficult to review properly.
In any case, could you upload it to http://codereview.appspot.com/ ?
--
___
Python tracker
<http://bugs.python.org/i
Changes by Antoine Pitrou :
--
nosy: +gps
___
Python tracker
<http://bugs.python.org/issue7418>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
On the one hand, it makes sense for the common case of completing using the Tab
key.
On the other hand, it will appear quite bizarre to people who have another,
dedicated key for auto-completion.
By the way, rather than inserting a tab character, it should
Antoine Pitrou added the comment:
It works in 64-bit mode under Mandriva Linux (gcc 4.4.1), with Python 2.6, 2.7
and 3.2.
$ python issue7505.py
b = (nil)
a = 7, c = 7, d = 7, e = 7, f = 7, g = 7, h = 7, i = 7, j = 7, k = 7, l = 7
I also works with a hand-compiled Python (2.6, 2.7, 3.2
Changes by Antoine Pitrou :
--
title: Inconsistent use of "iterator" in ElementTree doc & diff between Py and
C modules -> Update ElementTree with upstream changes
___
Python tracker
<http://bugs.
Antoine Pitrou added the comment:
If these 8 million records are loaded into memory, it can be normal to get a
MemoryError. It depends on the complexity of the records (number of fields) and
the way they are kept in memory (tuples? dicts?); and of course of the amount
of available RAM in
Antoine Pitrou added the comment:
I'm not sure what this brings. It is easy to write a loop iterating over test
data.
What parametric testing could bring is precise progress and error display
(displaying the parameters for each run), but this doesn't seem to be the case
here, sin
Antoine Pitrou added the comment:
> > With paramterized tests *all* the tests are run and *all* failures
> > reported. With testing in a loop the tests stop at the first failure.
>
> +1 to this justification. Parameterized tests are a big win over a
> simple for loop
Antoine Pitrou added the comment:
Retrograding to critical after popular python-dev demand.
--
nosy: +pitrou
priority: release blocker -> critical
___
Python tracker
<http://bugs.python.org/iss
Antoine Pitrou added the comment:
Indeed, I forgot to mention that the Debian Lenny install I reproduce the bug
on is a single core (virtual) machine.
--
___
Python tracker
<http://bugs.python.org/issue7
Antoine Pitrou added the comment:
I think restore_sigpipe=True would be a reasonable default.
As RDM says, adding an unit test would be better, but it may be difficult to do
so (we probably can't spawn Python itself since it will change the default
SIGPIPE handler at startup).
Looking a
Antoine Pitrou added the comment:
> I tried several times to debug it myself, but I don't understand the
> exception cleanup macros in ceval.c (UNWIND_EXCEPTION_HANDLER and
> friends, new in Py3). If someone can get me set up to debug them, I
> can give it another shot. I a
Antoine Pitrou added the comment:
> Is it normal that even after the call to next(), the generator frame
> contains a reference to the RuntimeError?
As long as it's executing the generator it's quite normal. The generator must
be able to restore the caller's RuntimeErro
Antoine Pitrou added the comment:
Just a quick test under Linux (on a dual quad core machine):
- with iotest.py and echo_client.py both running Python 2.7: 25.562 seconds
(410212.450 bytes/sec)
- with iotest.py and echo_client.py both running Python 3.2: 28.160 seconds
(372362.459 bytes/sec
Antoine Pitrou added the comment:
We could try not to release the GIL when socket methods are called on a
non-blocking socket.
Regardless, I've re-run the tests under the Linux machine, with two spinning
threads:
* python 2.7:
25.580 seconds (409914.612 bytes/sec)
* python 3.2:
3
Antoine Pitrou added the comment:
You should disassemble the output (or produce assembler from gcc) and check
that the various indirect jumps at the end of each case block don't get merged
into a single shared indirect jump.
Or perhaps it's simply that regular expression matc
Antoine Pitrou added the comment:
I agree this deserves documentation. I'm not convinced it's a common need,
though. Usually you either use stdin/stdout in binary mode or in text mode, but
you don't interleave both quite frequently.
--
assignee: -> georg
Antoine Pitrou added the comment:
I think the patch should just be rejected. Workloads where min() / max()
performance is a bottleneck have to be very rare.
--
___
Python tracker
<http://bugs.python.org/issue4
Antoine Pitrou added the comment:
And here is an experimental patch which enables the "priority requests"
mechanism which was in the original new GIL patch. "Experimental" because it
only enables them on a couple of socket methods (enough to affect the
benchmarks
Antoine Pitrou added the comment:
Here is another patch based on a slightly different approach. Instead of being
explicitly triggered in I/O methods, priority requests are decided based on the
computed "interactiveness" of a thread. Interactiveness itself is a simple
saturat
New submission from Antoine Pitrou :
While testing GIL changes I ran against an interesting bug in regrtest when run
with -j. It turns out that we can't consume a generator from two
threads simultaneously.
Exception in thread Thread-8:
Traceback (most recent call last):
File "/ho
Antoine Pitrou added the comment:
Obviously it also involves changing the code where the macro is invoked. It
would be quite non-controversial though.
I've a got a more interesting question: how does the memory allocator end up
being invoked from two threads at once? Usually m
Antoine Pitrou added the comment:
"lazy" sounds like a bad name for that parameter. It makes me think of lazy
evaluation, not error checking.
There's also the problem that check_py3k_warnings() will check all
DeprecationWarnings, not only py3k-specific ones. We need a
Py3kDep
Antoine Pitrou added the comment:
You are just having wrong expectations. Releasing a lock doesn't guarantee that
any other thread waiting on it will be scheduled preemptively. So, if you
re-acquire the lock immediately, the other thread will not necessarily have had
the opportuni
Antoine Pitrou added the comment:
Le Fri, 05 Mar 2010 02:21:30 +,
Alexander Belopolsky a écrit :
>
> Code duplication is unavoidable because the goal is to give access to
> machine arithmetics which means (# types) x (# operations) of very
> similar looking functions.
Antoine Pitrou added the comment:
I don't know what compatibility you are talking about. Py3k deliberately breaks
compatibility with many 2.x behaviours that were considered defective or
suboptimal.
--
nosy: +pitrou
___
Python tracker
Changes by Antoine Pitrou :
--
components: +Extension Modules -Tests
nosy: +gps
type: -> crash
___
Python tracker
<http://bugs.python.org/issue8073>
___
___
Py
Antoine Pitrou added the comment:
As Florent said, it is a rule of py3k to avoid implicit encoding/decoding. The
fact that it could have made sense for 2.x as well is not relevant, since the
change was only done in py3k (and for good reason: we normally try not to break
compatibility without
Antoine Pitrou added the comment:
Le Mon, 08 Mar 2010 09:01:19 +,
Stefan Behnel a écrit :
>
> Antoine, in the same comment, you say that it was not backported to
> Py2 in order to prevent breaking existing code, and then you ask if
> it's difficult to support in l
Changes by Antoine Pitrou :
--
assignee: -> georg.brandl
components: +Documentation
nosy: +georg.brandl
___
Python tracker
<http://bugs.python.org/iss
Antoine Pitrou added the comment:
It sounds like it would be cleaner to apply Brett's idea in msg75122, rather
than have the user override (and alternate implementations implement) another
obscure hook. We have enough hooks that nobody knows about, IMHO.
--
nosy: +p
Changes by Antoine Pitrou :
--
nosy: +lemburg, loewis
priority: -> normal
stage: -> patch review
type: -> behavior
versions: +Python 3.2
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
Probably a duplicate of issue5099.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue8091>
___
___
Python-bug
Antoine Pitrou added the comment:
By the way, stderr will contain "[XXX refs]" as the last line with Python
compiled in debug mode. The remove_stderr_debug_decorations() function will
help you ignore this line.
--
___
Python trac
Antoine Pitrou added the comment:
> The "no header" thing is very much done on purpose, and it's
> documented in the upstream ElementTree documentation.
I'm sorry, where is that?
I can't find it either at
http://effbot.org/zone/python
Antoine Pitrou added the comment:
> > Ha. There has been a very long temporal window
>
> You should have had plenty of time to fix it, then, right?
Under the condition that someone would have actually reported it, yes.
We don't magically fix bugs if nobody (including us) de
Antoine Pitrou added the comment:
Le Thu, 11 Mar 2010 22:03:37 +,
Fredrik Lundh a écrit :
>
> >>> import array
> >>> array.array("i", [1, 2, 3]).tostring()
> b'\x01\x00\x00\x00\x02\x00\x00\x00\x03\x00\x00\x00'
The fact that array is old
Changes by Antoine Pitrou :
--
nosy: +janssen
___
Python tracker
<http://bugs.python.org/issue8108>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Can you try to recompile Python in debug mode?
("make distclean && ./configure --with-pydebug").
--
nosy: +pitrou
___
Python tracker
<http://bugs
Antoine Pitrou added the comment:
Not wanting to waste my time anymore on this.
--
___
Python tracker
<http://bugs.python.org/issue8047>
___
___
Python-bug
Changes by Antoine Pitrou :
--
nosy: -pitrou
___
Python tracker
<http://bugs.python.org/issue8047>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
I suppose recvfrom_into() should also be converted.
--
___
Python tracker
<http://bugs.python.org/issue8104>
___
___
Python-bug
Antoine Pitrou added the comment:
> 1. It's inconsistent with copyfile
I think it's ok. When using copyfile you can easily check that the destination
file doesn't exist, while with copytree it's harder to do the same for *all*
destination files. Therefore it makes sens
Antoine Pitrou added the comment:
Here is a patch.
--
keywords: +patch
priority: -> normal
stage: -> patch review
type: -> feature request
Added file: http://bugs.python.org/file16529/recvinto.patch
___
Python tracker
<http://bug
Antoine Pitrou added the comment:
Florent's patch makes sense to me.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue8110>
___
___
Pytho
Changes by Antoine Pitrou :
--
nosy: +janssen
priority: -> normal
stage: -> patch review
type: -> feature request
versions: +Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
Is PYTHON_API_VERSION actually useful right now? It seems to me that we need
Martin's ABI stability PEP to be implemented before extension modules can be
safely shared between several non-bugfix releases.
--
nosy: +loewis, p
Antoine Pitrou added the comment:
> I posted on openssl-users mailing list. The author of patch (change
> SSL_shutdown() behaviour for non blocking socket) replied!
> http://marc.info/?l=openssl-users&m=126838806919896&w=2
Interesting read, thank you.
AFAICT, his proposed &q
Antoine Pitrou added the comment:
Compiles fine under Debian stable.
You shouldn't commit to 2.6 until 2.6.5 is released, though. If you want to do
so, contact Barry first.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
Committed in r78939 (trunk) and r78940 (py3k).
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Antoine Pitrou added the comment:
> Depends on what we want. It just suppresses information that's now
> available. What we'd really like is for the caller to recognize that
> close() can fail, and should be re-tried if it does. That requires
> that we signal the error
Antoine Pitrou added the comment:
> One thing to think about with
> this example is the proper priority of I/O handling generally. What
> if, instead of a file, this example code was writing on a pipe to
> another process? For that, you would probably want that I/O thread
>
Antoine Pitrou added the comment:
> Oh the situation definitely matters. Although, in the big picture,
> most programmers would probably prefer to have fast I/O performance
> over slow I/O performance :-).
Yes, of course. But that's not the point. We could try to improve GI
Changes by Antoine Pitrou :
--
assignee: -> pitrou
nosy: +pitrou
resolution: -> accepted
stage: -> commit review
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
For the record, this seems to break Mercurial on NFS-mounted repositories:
http://www.selenic.com/pipermail/mercurial/2010-March/030716.html
--
___
Python tracker
<http://bugs.python.org/issue7
Antoine Pitrou added the comment:
Barry, I suppose this doesn't warrant being a release blocker for 2.6.5, but in
any case you're welcome to advise.
--
nosy: +barry
___
Python tracker
<http://bugs.python.
Antoine Pitrou added the comment:
Will apply after 2.6.5.
--
assignee: -> pitrou
resolution: -> accepted
stage: patch review -> commit review
___
Python tracker
<http://bugs.python.o
Changes by Antoine Pitrou :
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue7682>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
nosy: +flox
resolution: accepted -> fixed
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue2746>
___
__
Changes by Antoine Pitrou :
--
type: behavior -> feature request
___
Python tracker
<http://bugs.python.org/issue3783>
___
___
Python-bugs-list mailing list
Un
Changes by Antoine Pitrou :
--
assignee: pitrou ->
___
Python tracker
<http://bugs.python.org/issue3580>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Antoine Pitrou :
--
assignee: pitrou ->
___
Python tracker
<http://bugs.python.org/issue3581>
___
___
Python-bugs-list mailing list
Unsubscri
Antoine Pitrou added the comment:
There probably isn't any point in such a complication, until perhaps we have a
JIT that magnifies the improvement.
(but I assume the JIT will be able to treat references to globals and builtins
as "frozen" usin
Antoine Pitrou added the comment:
Thanks Collin, recommend closing then.
--
___
Python tracker
<http://bugs.python.org/issue1518>
___
___
Python-bugs-list mailin
Changes by Antoine Pitrou :
--
nosy: +flox
___
Python tracker
<http://bugs.python.org/issue477863>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
stage: -> needs patch
title: New gc work -> Print warning at shutdown if gc.garbage not empty
versions: +Python 3.2 -Python 3.1
___
Python tracker
<http://bugs.python.org/is
Antoine Pitrou added the comment:
Committed in trunk, and additional tests ported to py3k.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
> But should PYTHON_API_VERSION be increased for the 2.7 release?
Sounds like a good idea.
--
___
Python tracker
<http://bugs.python.org/iss
Antoine Pitrou added the comment:
Crash reproduced under Mandriva Linux 2010.0 (glibc-2.10.1-6.2mnb2). Stack
trace is as follows:
(gdb) bt
#0 0x7fb59f2eba9a in strrchr () from /lib64/libc.so.6
#1 0x004010ae in ?? ()
#2 0x00400ff3 in ?? ()
#3 0x7fb59f29091d in
New submission from Antoine Pitrou :
test_subprocess has been leaking since the recent changes in py3k:
test_subprocess leaked [2, 2] references, sum=4
--
assignee: gregory.p.smith
components: Library (Lib), Tests
messages: 101286
nosy: gregory.p.smith, pitrou
priority: normal
severity
Changes by Antoine Pitrou :
--
nosy: +tarek
___
Python tracker
<http://bugs.python.org/issue8084>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Here is a new patch fixing most of your comments.
A couple of answers:
> I believe we can support arbitrary values here, subject to floating
> point rounding errors, by calling lock-with-timeout in a loop. I'm not
> sure whether that's
Changes by Antoine Pitrou :
Removed file: http://bugs.python.org/file15795/timedlock4.patch
___
Python tracker
<http://bugs.python.org/issue7316>
___
___
Python-bug
Antoine Pitrou added the comment:
Fixed in r79218 (trunk), r79220 (2.6), r79221 (py3k), r79222 (3.1). Thanks!
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Antoine Pitrou added the comment:
I committed the patch to trunk (r79226), only to discover that it caused
occasional failures in test_ftplib:
$ ./python -m test.regrtest -F test_ftplib
test_ftplib
test_ftplib
Exception in thread Thread-116:
Traceback (most recent call last):
File "
Antoine Pitrou added the comment:
(using SSL_MODE_AUTO_RETRY doesn't fix the test_ftplib issue)
--
___
Python tracker
<http://bugs.python.org/issue3890>
___
___
Antoine Pitrou added the comment:
The intuitive explanation seems to be:
- there are some bytes available for reading on the *TCP socket*, therefore
asyncore calls the read handler
- however, there are not enough bytes for OpenSSL to actually decrypt any data,
which is why we get
Antoine Pitrou added the comment:
> This last issue seems related to SSL 0.9.8m:
> http://bugs.python.org/issue8108
I don't think so:
$ rpm -qv openssl
openssl-0.9.8k-5.1mdv2010.0
--
___
Python tracker
<http://bugs.python
Antoine Pitrou added the comment:
> The patch seems ok to me. This is how it was supposed to be in the
> first place if ssl.py behaved as expected with non blocking sockets.
Ok, patch applied.
In light of the recv() and recv_into() implementation change, I also
think we should
Antoine Pitrou added the comment:
Ok, I finally agree that test_ftplib should be patched.
The patch isn't exactly correct: it should ideally retry the unwrap() call
later, rather than simply ignore the error. But since it's just used for
testing, it looks sufficient.
(we proba
Antoine Pitrou added the comment:
I committed the simple patch in r79299 (trunk), r79300 (2.6), r79301 (py3k),
r79302 (3.1). Tarek suggested a test could be added for this, assigning the
issue to him.
--
assignee: pitrou -> tarek
nosy: +tarek
stage: commit review -> com
New submission from Antoine Pitrou :
r79165 seems to be the culprit
Traceback (most recent call last):
File "/home/antoine/cpython/trunk/Lib/test/regrtest.py", line 864, in
runtest_inner
indirect_test()
File "/home/antoine/cpython/trunk/Lib/test/test_multiprocessing.py&q
4601 - 4700 of 16792 matches
Mail list logo
