Changes by Antoine Pitrou :
--
stage: patch review -> needs patch
___
Python tracker
<http://bugs.python.org/issue8205>
___
___
Python-bugs-list mailing list
Un
Antoine Pitrou added the comment:
> It happens only when sysconfig.is_python_build() is True (i.e. build
> directory).
>
> Proposed patch fixes it.
Can't say whether the patch is ok, but I confirm it does fix the issue
here.
--
_
Antoine Pitrou added the comment:
Committed in r79317 (py3k) and r79318 (3.1). Thank you!
--
nosy: +pitrou
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
Indeed. The io module has had to circumvent this and uses the following snippet
when resurrecting an instance of a subclass of one of its types (see
iobase_dealloc() in Modules/_io/iobase.c):
/* When called from a heap type's dealloc, the type
Antoine Pitrou added the comment:
In the current state of affaires this is more of a documentation issue.
Python 3 doesn't support totally unbuffered text I/O (and standard streams are
open in text mode). What `-u` and PYTHONUNBUFFERED do is that the binary layer
of standard strea
Changes by Antoine Pitrou :
--
assignee: -> georg.brandl
components: +Documentation -IO
nosy: +georg.brandl
___
Python tracker
<http://bugs.python.org/iss
Changes by Antoine Pitrou :
--
nosy: +lemburg, loewis
___
Python tracker
<http://bugs.python.org/issue8211>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> I upload bfs.patch
Interesting patch, but:
- Please give understandable benchmark numbers, including an explicit
comparison with baseline 3.2, and patched 3.2 (e.g. gilinter.patch)
- Please also measure single-thread performance, because it looks like
Antoine Pitrou added the comment:
> I don't quite see the point in having the streams buffered in one
> level and unbuffered in another, but I guess there's a reason.
The reason is simply that it wasn't implemented. Unbuffered I/O isn't
useful very often.
>
New submission from Antoine Pitrou :
In light of the recv() and recv_into() implementation change (issue3890), I
think we should enable SSL_MODE_AUTO_RETRY for SSL sockets. It prevents
blocking read() calls from getting SSL_ERROR_WANT_READ at all.
(previously, we would loop manually in recv
Changes by Antoine Pitrou :
--
title: enabling SSL_ERROR_WANT_READ on SSL sockets -> enabling
SSL_MODE_AUTO_RETRY on SSL sockets
___
Python tracker
<http://bugs.python.org/iss
Antoine Pitrou added the comment:
Ok, I've opened a separate issue (issue8222) for the SSL_MODE_AUTO_RETRY
suggestion.
This very issue has been fixed in r79226 (trunk), r79287 (py3k), r79290 (3.1)
and r79291 (2.6).
--
resolution: accepted -> fixed
stage: commit review ->
Antoine Pitrou added the comment:
To me it looks clearly like a no-op ("Never bother the application with retries
*if the transport is blocking*").
--
___
Python tracker
<http://bugs.python.
Antoine Pitrou added the comment:
Giampaolo, I tried committing your patch but the buildbot still fails, with the
following errors:
test_auth_issued_twice (test.test_ftplib.TestTLS_FTPClass) ... ok
test_auth_ssl (test.test_ftplib.TestTLS_FTPClass) ... ok
test_control_connection
Changes by Antoine Pitrou :
--
stage: test needed -> needs patch
versions: +Python 2.6, Python 3.1
___
Python tracker
<http://bugs.python.org/issue8108>
___
_
Antoine Pitrou added the comment:
Florent, you shouldn't need to silence socket.error at this level.
I think what needs to happen is that, when unwrap() fails in
SSLConnection.close(), handle_read() and handle_write() retry the unwrap()
call. That's what I gather from the explanat
Antoine Pitrou added the comment:
As Marc-André pointed out, you shouldn't have converted old uses of PyCObject.
It breaks compatibility, and I don't think there's any point since 2.7 will
probably be the last in the 2.x line.
--
nosy: +
Antoine Pitrou added the comment:
(if you want to be perfectionist, you can have those modules provide both a
PyCObject and a PyCapsule interface...)
--
___
Python tracker
<http://bugs.python.org/issue7
Antoine Pitrou added the comment:
> I use clock_gettime() to get the thread running time to calculate slice
> depletion.
Ouch. CLOCK_THREAD_CPUTIME_ID is not a required part of the standard. Only
CLOCK_REALTIME is guaranteed to exist.
By the way, it's not obvious cpued tes
Antoine Pitrou added the comment:
> Please specify system and test details so I can try to look into it.
It's a dual-core Linux x86-64 system. But, looking at the patch again,
the reason is obvious:
#define CHECK_SLICE_DEPLETION(tstate) (bfs_check_depleted ||
(tstate->tick_cou
Antoine Pitrou added the comment:
Actually, I'm not sure it's a good idea. For example, calling
os.ftruncate(fobj) on a py3k file object will bypass the object's internal
buffering, ignoring any pending buffered data; the right thing to do is to call
fobj.truncate() inst
Antoine Pitrou added the comment:
> What distribution and version of GNU/Linux are you using?
$ cat /etc/mandriva-release
Mandriva Linux release 2010.0 (Official) for x86_64
$ rpm -qv glibc
glibc-2.10.1-6.2mnb2
$ uname -a
Linux localhost 2.6.31.5-desktop-1mnb #1 SMP Fri Oct 23 00:05:22
Changes by Antoine Pitrou :
--
nosy: +orsenthil
___
Python tracker
<http://bugs.python.org/issue1491>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
assignee: -> georg.brandl
components: +Documentation -Extension Modules
nosy: +georg.brandl
___
Python tracker
<http://bugs.python.org/iss
Antoine Pitrou added the comment:
> Would it be possible to add an option to disable SSL_MODE_AUTO_RETRY
> for a specific socket? Existing applications may rely on / prefer the
> current behaviour.
I don't think so, since recv() used to emulate that be
Changes by Antoine Pitrou :
--
nosy: +janssen
___
Python tracker
<http://bugs.python.org/issue8240>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Since this error seems to be aimed at warning about potential programming
errors, I'm not sure it should be silenced. The obvious fix should be to pass
the same argument every time (until the data finally gets written).
--
nosy: +p
Antoine Pitrou added the comment:
> pitrou: that's debatable, since the Python programmer has no control
> over memory pointers.
No, but he has control over whether he always uses the same object, or
generates a new argument everytime.
> As I said, I have a cStringIO b
Antoine Pitrou added the comment:
Fixed in r79448 (trunk), r79449 (py3k), r79451 (2.6), r79453 (3.1).
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
> I also switched to gettimeofday() so it should work now on all Posix
> with high resolution timer
But on a busy system, won't measuring wall clock time rather than CPU time give
bogus results?
--
___
Antoine Pitrou added the comment:
Hmm, the gilinter patch shouldn't be sensitive to whether computed gotos are
enabled or not. Here is an updated patch, though, the previous one didn't apply
cleanly anymore. I've also made the priority condition a bit stricter.
--
A
Changes by Antoine Pitrou :
Removed file: http://bugs.python.org/file16238/issuegil.txt
___
Python tracker
<http://bugs.python.org/issue7946>
___
___
Python-bugs-list m
Changes by Antoine Pitrou :
Removed file: http://bugs.python.org/file16317/gilprio.patch
___
Python tracker
<http://bugs.python.org/issue7946>
___
___
Python-bugs-list m
Changes by Antoine Pitrou :
Removed file: http://bugs.python.org/file16329/gilinter.patch
___
Python tracker
<http://bugs.python.org/issue7946>
___
___
Python-bugs-list m
Changes by Antoine Pitrou :
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue8242>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
You're right, the script even uses CVS. Fixed in r79470.
--
nosy: +pitrou
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python
New submission from Antoine Pitrou :
test_signal in test_subprocess doesn't mute the subprocess stderr, which gives
output such as:
test_subprocess
.
this bit of output is from a test of stdout in a different process ...
.
this bit of output is from a test of stdout in a diff
Antoine Pitrou added the comment:
Decimal tests should probably be in test_decimal, not test_bool.
Also, I'm not sure why the __index__ and format tests aren't in the py3k patch.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.
Antoine Pitrou added the comment:
Python 3.2a0 (py3k:79464, Mar 27 2010, 19:18:14)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from weakref import WeakSet
>>>
--
nosy: +pitr
Antoine Pitrou added the comment:
I think the fix to Christian's issue is just:
Index: Lib/threading.py
===
--- Lib/threading.py(révision 79470)
+++ Lib/threading.py(copie de travail)
@@ -579,7 +
Antoine Pitrou added the comment:
I get another error on a 64-bit build:
>>> x = 2677691728509L << 2147483648L
Traceback (most recent call last):
File "", line 1, in
ValueError: outrageous left shift count
(yes, Python is outraged by such a large amount of left
Antoine Pitrou added the comment:
> If socket.write() returns zero byte written, I'll have to wait until I
> get another chance to send my buffer. But in the meantime, some more
> data might get appended to the buffer, and the string returned by
> getvalue() will be differe
Antoine Pitrou added the comment:
Committed in r79502, r79504 (trunk) and r79503 (py3k). Thank you!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
New submission from Antoine Pitrou :
New-style classes are weak referenceable, but old-style classes are not.
For a proper implementation of ABC caches without any memory leaks (see
issue2521), this limitation should be raised.
--
components: Interpreter Core
messages: 101957
nosy
Changes by Antoine Pitrou :
--
dependencies: +Make old-style classes weak referenceable
___
Python tracker
<http://bugs.python.org/issue2521>
___
___
Python-bug
Antoine Pitrou added the comment:
Here is a patch.
--
keywords: +patch
nosy: +amaury.forgeotdarc
stage: needs patch -> patch review
Added file: http://bugs.python.org/file16701/weakref-classobj.patch
___
Python tracker
<http://bugs.pyth
Changes by Antoine Pitrou :
Removed file: http://bugs.python.org/file16701/weakref-classobj.patch
___
Python tracker
<http://bugs.python.org/issue8268>
___
___
Python-bug
Changes by Antoine Pitrou :
Added file: http://bugs.python.org/file16702/weakref-classobj.patch
___
Python tracker
<http://bugs.python.org/issue8268>
___
___
Python-bug
Antoine Pitrou added the comment:
Hmm, Benjamin pointed out that ABCs only support new-style classes, so
old-style classes could be detected early instead of being added to the
_abc_negative_cache.
--
___
Python tracker
<http://bugs.python.
Antoine Pitrou added the comment:
By the way, Daniel, your patch doesn't look right.
First, you shouldn't need all the sortedlist/sortedset hierarchy.
Second, len(gc.get_objects()) is a truly horrible way of checking the classes
have been destroyed. Just take a weakref to the cl
Changes by Antoine Pitrou :
--
components: +Library (Lib)
nosy: +loewis
priority: -> low
type: -> behavior
versions: +Python 3.2
___
Python tracker
<http://bugs.python.org/
Changes by Antoine Pitrou :
--
nosy: +lemburg
___
Python tracker
<http://bugs.python.org/issue8269>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Shouldn't it be
zlib.ZLIB_VERSION < '1.2.4'
rather than
zlib.ZLIB_VERSION <= '1.2.4'
?
--
nosy: +pitrou
___
Python tracker
&l
Antoine Pitrou added the comment:
Ok, actually Python is only echoing the error return from zlib here, so I don't
seen the point of the conditional. Just always test against -1 and we're done.
--
___
Python tracker
<http://bu
Antoine Pitrou added the comment:
Fixed in r79535.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
> Make old-style classes weak-referenceable
Now done (r79535).
--
___
Python tracker
<http://bugs.python.org/iss
Antoine Pitrou added the comment:
Well, #defines are not exported in shared libraries. I suppose
PyEval_CallObject() was part of an old definition of the Python C-API and it
was kept for compatibility.
--
nosy: +pitrou
___
Python tracker
<h
Antoine Pitrou added the comment:
The #define dates back from 2007, this changeset:
branch: trunk
user:guido
date:Sat Aug 30 17:02:50 1997 +0200
files: Include/ceval.h Python/ceval.c
description:
[svn r8683] Inline PyObject_CallObject (Marc-Andre Lemburg
Antoine Pitrou added the comment:
Right, we can certainly suppress the function definition now and just keep the
macro.
(especially given it's 1997, not 2007, there was a typo in my message)
--
assignee: -> pitrou
priority: -> normal
stage: -> needs patch
type: ->
New submission from Antoine Pitrou :
This doesn't happen in verbose mode, because stdout isn't checked:
$ ./python -m test.regrtest test_gdb_sample
test_gdb_sample
test test_gdb_sample produced unexpected output:
***
Antoine Pitrou added the comment:
Fixed in r79555 (trunk), r79556 (py3k).
--
___
Python tracker
<http://bugs.python.org/issue8276>
___
___
Python-bugs-list mailin
Changes by Antoine Pitrou :
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
> I would probably be simplest to rename it so it doesn't have a "test_" prefix.
Indeed. Otherwise it gets caught and executed by regrtest as part of the
standard test suite.
> How about "sample_for_test_gdb.py", or somesuch?
Antoine Pitrou added the comment:
> (Note that due to issue 8279 the file isn't actually used at the moment
> by test_gdb.py so it should be safe to rename. I have a patch attached
> to that latter bug; I'll fix up the patch after that file is renamed).
Thank you, thi
Changes by Antoine Pitrou :
--
nosy: +orsenthil
priority: -> normal
___
Python tracker
<http://bugs.python.org/issue8293>
___
___
Python-bugs-list mai
Antoine Pitrou added the comment:
Additionally, since issue7471 was fixed, you should be able to wrap a GzipFile
in a Buffered{Reader,Writer} object for faster buffering.
--
resolution: -> out of date
status: open -> closed
___
Python t
Antoine Pitrou added the comment:
Kristjan, I agree with Martin, it's probably too late to make such
changes for 2.7.
Additionally, your "round-robin" scheme only seems round-robin when
there are two threads competing. Otherwise, you could have three threads
A, B and C, and t
Antoine Pitrou added the comment:
I don't think this should be a release blocker for the beta, although I agree
it should be one for the final release (and RCs).
By the way, it doesn't affect maintenance branches.
--
versions: -Python 2.6,
Antoine Pitrou added the comment:
Giampaolo, which call exactly triggers the "error: [Errno 0] Error"?
It doesn't seem it can be _sslobj.shutdown itself.
--
___
Python tracker
<http://bugs.py
Antoine Pitrou added the comment:
> This is quite obscure because there's no definition of the "buffer
> protocol".
You can find it at http://www.python.org/dev/peps/pep-3118/#id5 (assuming it is
not outdated)
> the memoryview.suboffsets attribute is not
Antoine Pitrou added the comment:
> memoryview() function is not documented in library/functions.rst
You should look more carefully...
See http://docs.python.org/dev/library/functions.html#max
(I don't know why it doesn't have its own a
Antoine Pitrou added the comment:
What kind of signals can be received in real-life?
(I'm assuming that most signals are of the kind that you only receive if
someone else deliberately sends it to you, in which case you are supposed to be
prepared to handle it)
Also, does your patch
Antoine Pitrou added the comment:
> Since it's not clear to me where exactly this comes from, whether it's
> from the Python C binding or OpenSSL itself, I tried to put some
> debugging printf() calls in Modules/_ssl.c, but it seems that after
> installing OpenSSL 0.9.8m
Antoine Pitrou added the comment:
> No I haven't, but I tried just now and I get the same error.
I think "inflate" is a function exported by the zlib. Perhaps you can
add "-lz" to the linking flags.
(Googling hints that OpenSSL can depend on the zl
New submission from Antoine Pitrou :
This patch gives access to the OpenSSL version the _ssl module is linked
against, through three attributes: one gives the raw integer, another the
decoded 5-tuple of ints, the last one the version string as returned by OpenSSL.
--
components
Antoine Pitrou added the comment:
(note: tested with OpenSSL 0.9.8k and 1.0.0)
--
___
Python tracker
<http://bugs.python.org/issue8321>
___
___
Python-bugs-list m
New submission from Antoine Pitrou :
When I compile and link against a local build of OpenSSL 1.0.0 (vanilla), I get
the following errors in test_ssl:
==
ERROR: testProtocolSSL2 (test.test_ssl.ThreadedTests
Antoine Pitrou added the comment:
I've tried to build against OpenSSL 1.0.0, and I get further failures in
test_ssl. Since I don't know whether they are related, I've created a separate
issue for them: issue8322
--
___
Python
Changes by Antoine Pitrou :
Removed file: http://bugs.python.org/file16767/sslversion.patch
___
Python tracker
<http://bugs.python.org/issue8321>
___
___
Python-bug
Antoine Pitrou added the comment:
New patch with doc.
--
Added file: http://bugs.python.org/file16768/sslversion.patch
___
Python tracker
<http://bugs.python.org/issue8
Changes by Antoine Pitrou :
Removed file: http://bugs.python.org/file16768/sslversion.patch
___
Python tracker
<http://bugs.python.org/issue8321>
___
___
Python-bug
Changes by Antoine Pitrou :
Added file: http://bugs.python.org/file16769/sslversion.patch
___
Python tracker
<http://bugs.python.org/issue8321>
___
___
Python-bugs-list m
Antoine Pitrou added the comment:
Committed, with Benjamin's permission, in r79812 (trunk) and r79813 (py3k).
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http:
Antoine Pitrou added the comment:
> >>> import ssl
> Traceback (most recent call last):
> File "", line 1, in
> File "/usr/local/lib/python2.7/ssl.py", line 62, in
> from _ssl import OPENSSL_VERSION_NUMBER, OPENSSL_VERSION_INFO,
> OP
Antoine Pitrou added the comment:
> So I'm gonna ask: when I modify *.c files, do I have to do something
> else other than "./configure; make; make install" in order to see the
> changes applied?
No.
If you run the Python binary from the SVN checkout direct
Antoine Pitrou added the comment:
> So I'm gonna ask: when I modify *.c files, do I have to do something
> else other than "./configure; make; make install" in order to see the
> changes applied?
Oh, sorry, I had overlooked the "make install" bit.
Well then
Antoine Pitrou added the comment:
It begs the question of why the tests succeed with previous OpenSSL versions.
The only possibly relevant entry I could find in the OpenSSL changelog (but I'm
not an expert) is the following:
*) If no SSLv2 ciphers are used don't use an SSLv2
Antoine Pitrou added the comment:
Ok, here is a patch fixing all test_ftplib failures (tested with openssl 0.9.8k
and 1.0.0).
There are a couple of fixes here:
- a workaround for the strange SSL_shutdown() error return, also witnessed by
LightHTTPd users (see URL in comments)
- an auto-retry
Changes by Antoine Pitrou :
Added file: http://bugs.python.org/file16778/newssl.patch
___
Python tracker
<http://bugs.python.org/issue8108>
___
___
Python-bugs-list mailin
Antoine Pitrou added the comment:
> What happens if you move the SSL shutdown() call in handle_close()
> method and leave handle_error() unchanged?
I get occasional crashes such as the following:
Exception in thread Thread-60:
Traceback (most recent call last):
File "/home/anto
Antoine Pitrou added the comment:
By the way, this "broken pipe" error could be due to the fact that the
FTP_TLS client never tries to call unwrap() on its SSL socket. Perhaps
the close() method should be overriden?
--
___
Python trac
Antoine Pitrou added the comment:
Here is a new patch. It doesn't change handle_error() but instead ignores
abruptly closed sockets when doing the SSL shutdown.
The underlying problem seems to be an asyncore limitation: close() can be
called after an error such as EPIPE or ECONNABORTED
Antoine Pitrou added the comment:
> As for our test server we are currently shutting down the SSL layer for
> both connections (control and data) so this might be the cause of EPIPE.
I don't understand your reasoning. These are separate connections, closing one
shouldn't
Antoine Pitrou added the comment:
> - ftplib.FTP_TLS.quit: I wouldn't call unwrap() here as RFC-4217 does
> that only when dealing with CCC command which is not implemented by
> ftplib.py.
Ok.
> - I'd be for calling _do_ssl_shutdown() from handle_close() instead of
&
Antoine Pitrou added the comment:
New patch without the quit() method change.
--
Added file: http://bugs.python.org/file16781/newssl3.patch
___
Python tracker
<http://bugs.python.org/issue8
Antoine Pitrou added the comment:
This shouldn't really care about VMS here. As for the rest, feel free to
propose a patch :)
Please note that most non-trivial system calls, such as ftruncate(), mremap(),
even mmap() itself, deserve to be enclosed in
Py_BEGIN_ALLOW_TH
Antoine Pitrou added the comment:
> This shouldn't really care about VMS here.
Correction: /we/ shouldn't really care about VMS here.
And the reason being, of course, that we have neither developers nor
known testers under VMS.
(we don't even know if the current trunk b
Changes by Antoine Pitrou :
--
priority: normal -> critical
___
Python tracker
<http://bugs.python.org/issue6090>
___
___
Python-bugs-list mailing list
Un
Antoine Pitrou added the comment:
By the way, even better if you find a way of having unit tests for bluetooth
sockets. Is there some kind of "dummy" device which gives predictable results
(à la /dev/zero, for example)?
--
___
Pyth
Antoine Pitrou added the comment:
Committed in r79848 (trunk), r79849 (py3k), r79850 (2.6), r79851 (3.1). Thank
you!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python track
4701 - 4800 of 16792 matches
Mail list logo
