Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +jcea, ronaldoussoren
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11279
___
___
Python-bugs
Antoine Pitrou pit...@free.fr added the comment:
Does it matter that _4G UINT_MAX?
You mean _4G UINT_MAX, right?
Yes, it matters, otherwise that defeats the point of the test :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Antoine Pitrou pit...@free.fr added the comment:
Well, it's not a patch, just a traceback :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11277
Antoine Pitrou pit...@free.fr added the comment:
File: issue11277.patch.
Hmm. Two non-register constants and equal code on 32 and 64 bit.
Does Python has a '64 bit' switch or the like - PY_SSIZE_T_MAX is not
preprocessor-clean, i would guess.
Er, how is this patch different from r88460
Antoine Pitrou pit...@free.fr added the comment:
This is on Snow Leopard 64 bit, 02b70cb59701 (r88451) - Python 3.3a0.
Is there a switch i must trigger? Just pulled 24 changesets,
recompiling and trying again with r88460.
Have you tried ./python -m test -v -uall test_zlib
Antoine Pitrou pit...@free.fr added the comment:
Can you try to identify which revision introduced the issue?
--
nosy: +haypo, ned.deily, pitrou
priority: normal - critical
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11285
Antoine Pitrou pit...@free.fr added the comment:
Just stepping ... with c8d1f99f25eb/r88476:
Right, that's what we should investigate :)
Could try to diagnose the crash?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11277
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11285
___
___
Python-bugs-list
Antoine Pitrou pit...@free.fr added the comment:
Ok, so it boils down to:
pickle.loads(b'\x80\x02}q\x00U\x00q\x01h\x01s.')
{'': ''}
pickle.loads(b'\x80\x02}q\x00U\x00q\x01h\x01s.', encoding='latin1')
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: operation
Antoine Pitrou pit...@free.fr added the comment:
This is because of the buffer pointer passed to the codecs machinery being NULL
when the empty string is being decoded.
Quick patch follows (needs a test). Also, it is not clear whether it is allowed
to store a NULL pointer in the buf member
Antoine Pitrou pit...@free.fr added the comment:
.. even with a self-compiled 1.2.3, INT_MAX/1000 ... nothing.
The problem is not crc32(), but the buffer itself:
if (pbuf.len 1024*5) {
unsigned char *buf = pbuf.buf;
Py_ssize_t len = pbuf.len;
Py_ssize_t i
Antoine Pitrou pit...@free.fr added the comment:
Out of curiosity, could you try the following patch?
Index: Lib/test/test_zlib.py
===
--- Lib/test/test_zlib.py (révision 88500)
+++ Lib/test/test_zlib.py (copie de
Antoine Pitrou pit...@free.fr added the comment:
Here is a patch with tests.
--
keywords: +patch
stage: needs patch - patch review
Added file: http://bugs.python.org/file20842/null_ptr_buffer.patch
___
Python tracker rep...@bugs.python.org
http
Antoine Pitrou pit...@free.fr added the comment:
Antoine, your msg129093 patch of test_zlib.py does it (with and
without fprintf(3)s). CRC ok etc., it just works.
Indeed, and it also seems to work on the buildbot. I will commit the
patch soon. Thanks for your help!
(Seems mmap(2) has
Antoine Pitrou pit...@free.fr added the comment:
Committed in r88511 (3.3) and r88514 (3.2).
--
resolution: - fixed
stage: needs patch - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Antoine Pitrou pit...@free.fr added the comment:
Jesus, perhaps you can address Amaury's comments by uploading a new patch?
--
assignee: amaury.forgeotdarc -
stage: commit review - needs patch
___
Python tracker rep...@bugs.python.org
http
Antoine Pitrou pit...@free.fr added the comment:
This is nice, but IMO there is some information lacking, e.g.:
- when an underlying mapping is mutated, does the ChainMap get updated too?
- does it work with arbitrary mappings or only with dicts or dicts subclasses?
I think new_child() isn't
Antoine Pitrou pit...@free.fr added the comment:
(too specialized, sorry)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11297
___
___
Python
Antoine Pitrou pit...@free.fr added the comment:
I am not sure PyUnicode_Decode() should treat NULL as an empty string.
Definitely not. That would hide programming errors.
Well, this could break some third-party code.
--
title: Some trivial python 2.x pickles fails to load
Antoine Pitrou pit...@free.fr added the comment:
Antoine Pitrou wrote:
Antoine Pitrou pit...@free.fr added the comment:
I am not sure PyUnicode_Decode() should treat NULL as an empty string.
Definitely not. That would hide programming errors.
Well, this could break some third
Antoine Pitrou pit...@free.fr added the comment:
PyUnicode_Decode() et al. are conversion functions and these
require valid content to work on. Passing in a NULL pointer
does not fit that specification and so allowing for this
would hide programming errors.
Valid content doesn't mean a lot
Antoine Pitrou pit...@free.fr added the comment:
For the record:
e.g. 'cd Lib/test; ../../python.exe -m test -v -uall test_iter' works
just perfect.
You don't need to cd. Just ./python -m test (etc.).
See http://docs.python.org/devguide/runtests.html for more information
Changes by Antoine Pitrou pit...@free.fr:
--
resolution: - works for me
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11285
___
___
Python-bugs
Antoine Pitrou pit...@free.fr added the comment:
So, IMO, practicality beats purity here. Especially since it is bound to
land in a bugfix release (3.2.1), which users don't expect to produce
regressions in their own code.
Nope. Your suggestion would be a new feature and those
Antoine Pitrou pit...@free.fr added the comment:
Nope. Your suggestion would be a new feature and those are not
allowed in patch level releases.
What new feature are you talking about? I think you misunderstood the
actual issue: NULL as an empty string *worked* in 3.1
And, with a very
Antoine Pitrou pit...@free.fr added the comment:
This new failure is perhaps related:
http://www.python.org/dev/buildbot/all/builders/AMD64%20Windows%20Server%202008%203.x/builds/572/steps/test/logs/stdio
==
FAIL: test_module
Antoine Pitrou pit...@free.fr added the comment:
Please go with Alexander's solution of fixing the higher level code
rather than silently trying to introduce a new feature in
PyUnicode_Decode() that hides programming errors.
I'm sorry, I'm perfectly fine with my own patch, so someone else
Antoine Pitrou pit...@free.fr added the comment:
Oops, I hadn't seen Alexander's patch. Sorry.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11286
Antoine Pitrou pit...@free.fr added the comment:
So, about Alexander's patch:
- it lacks a test
- it doesn't solve the issue with PyUnicode_Decode's confusing error message
when a NULL is passed (ValueError: operation forbidden on released memoryview
object); if we want to disallow NULL, we
Antoine Pitrou pit...@free.fr added the comment:
It may be better to modify _Unpickler_Read() so that it returns
self-input_buffer (or even self-input_buffer + self-next_read_idx)
for zero n.
I agree this would be better for readability and maintainability.
On the other hand, my patch also
Antoine Pitrou pit...@free.fr added the comment:
It would probably be ok to fallback on read() when read1() isn't implemented.
read1() is supposed to be implemented by all BufferedIO-compliant classes, but
in all honesty I don't think it's very useful in practice. It's supposed
Antoine Pitrou pit...@free.fr added the comment:
I've committed the part of the patch which disallows a NULL data pointer with
PyMemoryView_FromBuffer in r88550 and r88551.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Antoine Pitrou pit...@free.fr added the comment:
I've committed the part of the patch which disallows a NULL data pointer
with PyMemoryView_FromBuffer in r88550 and r88551.
Is it possible to create such buffer in Python (other than by
exploiting a bug or writing a rogue extension module
Antoine Pitrou pit...@free.fr added the comment:
It seems appropriate to consult python-dev on this. I thought
ValueError was for values that are valid Python objects but out of
acceptable range of the function. Errors that can only be triggered
in C code normally handled with either
Antoine Pitrou pit...@free.fr added the comment:
Thanks for the new patch. Looking again, I wonder if there's a reason the
original regexp was so complicated. ldconfig output here has lines such as:
libBrokenLocale.so.1 (libc6,x86-64, OS ABI: Linux 2.6.9) =
/lib64/libBrokenLocale.so.1
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +gregory.p.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11314
___
___
Python-bugs-list
Antoine Pitrou pit...@free.fr added the comment:
I think your analysis is wrong. These mmap() calls are for anonymous memory,
most likely they are emitted by the libc's malloc() to get some memory from the
kernel. In other words they will be blazingly fast.
I would suggest you try to dig
Antoine Pitrou pit...@free.fr added the comment:
Le vendredi 25 février 2011 à 13:58 +, Palm Kevin a écrit :
Palm Kevin kevin.p...@labsolution.lu added the comment:
Please find here a small C app embedding python that shows how to
reproduce the problem (It turned out that the problem
Antoine Pitrou pit...@free.fr added the comment:
But in the two scenarios I mentioned (monitoring and Web services such
as CGI, neither of which is particularly rare), this is going to make
quite a lot of difference
That's why I asked for absolute numbers for the overhead difference
Antoine Pitrou pit...@free.fr added the comment:
Okay, thanks to Charles-François' measurements, we can deduce that each
subprocess launch is at most 0.3ms of user CPU time and 1.2ms of system CPU
time. IMO that's not a real problem.
--
___
Python
Antoine Pitrou pit...@free.fr added the comment:
Can you explain why this is a problem in Python?
Can't lib/python3.2/config-3.2m/Makefile simply be provided by virtualenv (by
copying it, I guess)?
--
nosy: +pitrou
___
Python tracker rep
Antoine Pitrou pit...@free.fr added the comment:
Committed in r88607 (3.3).
--
resolution: accepted - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4
Antoine Pitrou pit...@free.fr added the comment:
This patch has tests and is also able to constant-fold tuples larger than 256
elements.
--
stage: - patch review
versions: +Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Antoine Pitrou pit...@free.fr added the comment:
Forgot to attach new patch, sorry.
--
Added file: http://bugs.python.org/file20897/constfold2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11244
Antoine Pitrou pit...@free.fr added the comment:
Committed in r88610 (3.3), r88611 (3.2) and r88612 (2.7).
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http
Antoine Pitrou pit...@free.fr added the comment:
I corrected the patches (they were breaking the property of inheriting daemon
by default) and committed them in r88618. Thank you!
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
Antoine Pitrou pit...@free.fr added the comment:
The patch needs updating for latest 3.x.
--
assignee: loewis -
nosy: +giampaolo.rodola, pitrou
versions: +Python 3.3 -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Antoine Pitrou pit...@free.fr added the comment:
What's wrong with Marc's commit? He's using the standard names.
That's a pretty useless commit and it will make applying patches and backports
more tedious, for no obvious benefit.
Of course that concern will be removed if Marc-André also
Antoine Pitrou pit...@free.fr added the comment:
Éric, the weak dicts are implemented in pure Python while built-in dicts are in
C. That can make quite a difference.
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Antoine Pitrou pit...@free.fr added the comment:
Committed in r88622 (3.3) and r88623 (3.2). The 2.7 implementation is too
different for the patch to apply, so if you want to fix it too, feel free to
upload a patch. Thank you!
--
resolution: - fixed
stage: patch review - committed
Antoine Pitrou pit...@free.fr added the comment:
I have committed the patch in r88624. Thank you!
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
New submission from Antoine Pitrou pit...@free.fr:
$ make
gcc -pthread -g -O0 -Wall -Wstrict-prototypes-I. -IInclude -I./Include
-DPy_BUILD_CORE -c ./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function ‘posix_sendfile’:
./Modules/posixmodule.c:6025
Antoine Pitrou pit...@free.fr added the comment:
Committed in r88625. Thank you!
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10755
Antoine Pitrou pit...@free.fr added the comment:
==
ERROR: test_set_get_priority (test.test_os.ProgramPriorityTests)
--
Traceback (most recent call last
Antoine Pitrou pit...@free.fr added the comment:
Perhaps (probably?) related to the crash in
http://www.python.org/dev/buildbot/all/builders/PPC64%20Ubuntu%203.x/builds/655
./Modules/posixmodule.c:5909: warning: implicit declaration of function
‘sendfile’
--
priority: normal - high
Antoine Pitrou pit...@free.fr added the comment:
Ok, one issue is that connect_ex() isn't implemented for SSL sockets, so it
defers to the normal implementation instead, which is wrong.
But your still is wrong too. connect_ex() returns an error, meaning the socket
isn't connected and you must
Antoine Pitrou pit...@free.fr added the comment:
The select call after the connect_ex waits until the connection is
done, for the first write event is fired then, so the socket is
connected afterwards.
You are right. Here is a patch for py3k implementing connect_ex() and solving
the issue
Changes by Antoine Pitrou pit...@free.fr:
Removed file: http://bugs.python.org/file20900/ssl_connect.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11326
Changes by Antoine Pitrou pit...@free.fr:
Added file: http://bugs.python.org/file20901/ssl_connect.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11326
Antoine Pitrou pit...@free.fr added the comment:
For other spellings like utf8 or latin1, I wonder if it would be
useful to emit a warning/suggestion to use the standard spelling.
No, it would be an useless annoyance.
--
___
Python tracker rep
Antoine Pitrou pit...@free.fr added the comment:
If we ever decide to get rid of codec aliases in the core
If.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11303
Antoine Pitrou pit...@free.fr added the comment:
Can you backport to 3.2?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10228
___
___
Python
Antoine Pitrou pit...@free.fr added the comment:
Fixed in r88626, and it *did* fix the buildbot crash!
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11325
Antoine Pitrou pit...@free.fr added the comment:
Fixed in r88626, and it *did* fix the buildbot crash!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11325
Antoine Pitrou pit...@free.fr added the comment:
Indeed.
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10784
Changes by Antoine Pitrou pit...@free.fr:
--
Removed message: http://bugs.python.org/msg129503
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11325
Changes by Antoine Pitrou pit...@free.fr:
--
resolution: - invalid
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11328
Antoine Pitrou pit...@free.fr added the comment:
I'm not sure why you use PyTuple_Size() and PyTuple_GetItem().
You should be able to do a first call to PyArg_ParseTuple() (using the S
specifier to mandate a bytes object), and call PyErr_Clear() and fallback to
the second PyArg_ParseTuple
Antoine Pitrou pit...@free.fr added the comment:
Now backported as part of issue 941346.
--
resolution: - duplicate
stage: - committed/rejected
status: open - closed
superseder: - AIX shared library fix
___
Python tracker rep...@bugs.python.org
Antoine Pitrou pit...@free.fr added the comment:
Not sure that silencing errors from quit() is the right thing. Is there any
reason?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9795
Antoine Pitrou pit...@free.fr added the comment:
Ok, I think you're right.
I've committed the patch to 3.3 in r88639 after having added a minimal test. Is
there a full name I should credit?
Thank you for contributing!
--
assignee: theller -
resolution: - fixed
stage: patch review
Antoine Pitrou pit...@free.fr added the comment:
Reopening and reverted the commit in r88640. The patch changes behaviour by
turning the previous unrooted filename ('libc.so.6') into a full path
('/lib64/libc.so.6'). This breaks builds where multiple versions of a library
are available
Antoine Pitrou pit...@free.fr added the comment:
Given the way the new GIL works, I'm afraid it's not really possible to support
this (it needs some thread-state to be available).
Note that there is no reason, AFAIK, why you would want to call
PyEval_InitThreads() before Py_Initialize
Changes by Antoine Pitrou pit...@free.fr:
--
assignee: docs@python - vinay.sajip
nosy: +vinay.sajip
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11330
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +belopolsky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11327
___
___
Python-bugs-list
Changes by Antoine Pitrou pit...@free.fr:
--
assignee: - vinay.sajip
nosy: +brett.cannon, vinay.sajip
stage: - patch review
type: - behavior
versions: +Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11332
Antoine Pitrou pit...@free.fr added the comment:
New patch including a check for PyObject_GetBuffer()'s return value, the
missing declaration of HAVE_SETHOSTNAME in pyconfig.h.in, and a test for giving
a bytes values to the function.
--
Added file: http://bugs.python.org/file20909
Antoine Pitrou pit...@free.fr added the comment:
It still fails under AMD64 OpenIndiana:
==
ERROR: test_offset_overflow (test.test_os.TestSendfile
Antoine Pitrou pit...@free.fr added the comment:
What about Doc/whatsnew/3.3.rst?
This is filled by Raymond (or other people) when the release nears.
No need to care about it in regular commits.
--
___
Python tracker rep...@bugs.python.org
http
Antoine Pitrou pit...@free.fr added the comment:
Ok, so the root cause is that sendfile() under Solaris can fail with EINVAL
when the offset is past the end of file (but only on 64-bit builds, strangely
:-)). Here is a patch, tested under Linux, 32-bit OpenSolaris and 64-bit
OpenSolaris
Antoine Pitrou pit...@free.fr added the comment:
It seems we have a failure on Leopard:
I think the issue is you request a 4096 transfer near the end of file, but
there aren't that many bytes remaining. Apparently OS X then doesn't transfer
anything and returns 0. Hint:
10485760. / 4096
Antoine Pitrou pit...@free.fr added the comment:
Should be fixed in r88647.
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
versions: +Python 3.3 -Python 3.2
___
Python tracker rep...@bugs.python.org
http
Antoine Pitrou pit...@free.fr added the comment:
The patch looks good.
Just to be clear, on my system running autoreconf adds the correct
stuff to pyconfig.h.in
Ah, strange. I used autoconf and it didn't...
Isn't it best to leave it up to the committer to generate configure
Changes by Antoine Pitrou pit...@free.fr:
--
assignee: ronaldoussoren -
nosy: +asksol, jnoller
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11334
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +ned.deily
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11334
___
___
Python-bugs-list mailing
Antoine Pitrou pit...@free.fr added the comment:
Committed in r88652 (3.3) and r88655 (3.2). Unfortunately, Paul's buildbot
seems a bit stuck in a previous build...
(I didn't commit to 2.7 since things look fine there)
--
nosy: +pitrou
resolution: - fixed
stage: - committed/rejected
Antoine Pitrou pit...@free.fr added the comment:
Thank you for the suggestion. We are actually starting our official transition
to hg, which makes things a bit unstable.
The final URL (http://hg.python.org/cpython/) is currently a test repo, while
the usable for work right now (http
Antoine Pitrou pit...@free.fr added the comment:
Errno 75 is EOVERFLOW here (Linux), which doesn't seem to be mentioned in
sendfile's man page.
Can you describe your system? (CPU architecture, bitness, endianness,
glibc/kernel version, etc.)
--
assignee: - giampaolo.rodola
nosy
Antoine Pitrou pit...@free.fr added the comment:
rev 88657
Arch Linux 2.6.37 x86_64 with glibc2.6
64-bit, little endian
You are not running under a VM or something?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11341
Antoine Pitrou pit...@free.fr added the comment:
I've committed the patch + some tests in r88664 (3.3), r88665 (3.2) and r88666
(2.7). Thanks for reporting this!
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
versions: -Python 3.1
Antoine Pitrou pit...@free.fr added the comment:
Here is an excerpt:
libc.so.6 (libc6,x86-64, OS ABI: Linux 2.6.9) = /lib64/libc.so.6
libc.so.6 (libc6, OS ABI: Linux 2.6.9) = /lib/libc.so.6
The OS ABI thing is not always there:
libdrm.so.2 (libc6,x86-64) = /usr/lib64
Antoine Pitrou pit...@free.fr added the comment:
Well, on the other hand, it *is* a common need.
(and I don't think mimicking the shell is a design principle for Python)
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http
Antoine Pitrou pit...@free.fr added the comment:
Ok, great !
The hg builders are temporary - or, rather, the SVN builders will get removed
once the transition is over.
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +barry, dmalcolm
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11347
___
___
Python-bugs-list
Antoine Pitrou pit...@free.fr added the comment:
Likely explanation is http://bugs.python.org/issue10882#msg129555.
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11351
Antoine Pitrou pit...@free.fr added the comment:
Your patch is not cleaned up. There are strange things like:
+ret ^= ret;
(while would you xor an off_t?)
and
+do {off_t x = (*buf)[i].len;
+(*iov)[i].iov_len = x;
+ret += x
Antoine Pitrou pit...@free.fr added the comment:
Given the deprecation of PyEval_ReleaseLock in issue10913, should this
be closed as out of date?
Indeed :)
--
resolution: - out of date
stage: test needed -
status: open - closed
___
Python
Changes by Antoine Pitrou pit...@free.fr:
--
assignee: - giampaolo.rodola
nosy: +rosslagerwall
stage: - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11351
Antoine Pitrou pit...@free.fr added the comment:
The way to build Python is to run ./configure followed by make. This is
explained in the README.
--
nosy: +barry, pitrou
resolution: - invalid
status: open - closed
___
Python tracker rep
Antoine Pitrou pit...@free.fr added the comment:
Patch committed in r88682, thank you!
--
resolution: - fixed
stage: needs patch - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11140
801 - 900 of 16564 matches
Mail list logo
