Changes by Giampaolo Rodola' billiej...@users.sourceforge.net:
--
nosy: +janssen
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4788
___
___
Python
Changes by Giampaolo Rodola' billiej...@users.sourceforge.net:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4791
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment:
I'm unable to reproduce the issue.
Could you please repeat the test by using the timeout parameter as
such?
ftp = ftplib.FTP('ftp.edgecastcdn.net', user='theusername',
passwd='thepassword')
ftp = ftplib.FTP
New submission from Giampaolo Rodola' billiej...@users.sourceforge.net:
When using the optional ftplib.FTP()'s timeout parameter which
specifies a timeout in seconds for blocking operations like the
connection attempt, it is applied on both FTP control and passive data
channel (if any
Changes by Giampaolo Rodola' billiej...@users.sourceforge.net:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3823
New submission from Giampaolo Rodola' billiej...@users.sourceforge.net:
As came out here:
http://groups.google.it/group/comp.lang.python/browse_thread/thread/7d5b96f9bacb03d3?hl=it#
...the ssl module does not provide any facility to disable SSL version
2. This is very important when writing
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment:
Actually, that's not quite true.
Specifying TLSv1 or SSLv3 on the
server side will disable SSLv2.
There are use cases like FTPS where it is desirable that servers support
SSLv3 *and* TLSv1.
To do that by using OpenSSL
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment:
I'm sorry, I realized right now that settimeout() should be used also
*before* invoking accept(), to avoid the client to stall in case the
server does not establish any connection.
The second patch in attachment does
New submission from Giampaolo Rodola' billiej...@users.sourceforge.net:
Today I was trying to compile a module using an extension in C and
noticed there are differences between compiling it on Python 2.5 and 2.6.
I was trying to compile psutil (svn checkout
http://psutil.googlecode.com/svn/trunk
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment:
Currently I haven't any C compiler installed on my system so I expect
distutils to report that every time I try to compile a C module extension.
Python 2.5 did that while Python 2.6 does
Changes by Giampaolo Rodola' billiej...@users.sourceforge.net:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4929
Changes by Giampaolo Rodola' billiej...@users.sourceforge.net:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4967
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment:
As for ftplib patch you should make sure that close() gets called in any
case but never more than once.
You can use finally to satisfy the first requirement and self.sock is
not None to check the second condition:
+def
New submission from Giampaolo Rodola' billiej...@users.sourceforge.net:
While trying to port pyftpdlib to Python 3.x I noticed that Python 3.0
has a serious issue since unable to print certain unicode characters on
stdout:
Python 3.0 (r30:67507, Dec 3 2008, 20:14:27) [MSC v.1500 32 bit
(Intel
Changes by Giampaolo Rodola' billiej...@users.sourceforge.net:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5110
Changes by Giampaolo Rodola' billiej...@users.sourceforge.net:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4673
Changes by Giampaolo Rodola' billiej...@users.sourceforge.net:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5107
Changes by Giampaolo Rodola' billiej...@users.sourceforge.net:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5103
Changes by Giampaolo Rodola' billiej...@users.sourceforge.net:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5097
Changes by Giampaolo Rodola' billiej...@users.sourceforge.net:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5115
Changes by Giampaolo Rodola' billiej...@users.sourceforge.net:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3871
Changes by Giampaolo Rodola' billiej...@users.sourceforge.net:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2578
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment:
I'm not sure this should be handled in ssl.py.
ssl.py correctly raises ERROR_WANT_READ/WRITE if the shutdown operation didn't
complete and that's ok.
It should be up to the upper application (in our case asyncore) to deal
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment:
I'd really love to understand what the state of the TCP connection
is here. I'm presuming that it's still open, because otherwise you'd
get a different error from OpenSSL. So what's the error that's
triggering
Changes by Giampaolo Rodola' billiej...@users.sourceforge.net:
--
nosy: +giampaolo.rodola, josiah.carlson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8003
Changes by Giampaolo Rodola' billiej...@users.sourceforge.net:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6768
Changes by Giampaolo Rodola' billiej...@users.sourceforge.net:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6589
Giampaolo Rodola' billiej...@users.sourceforge.net 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
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment:
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.
Actually unwrap() should already be called
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment:
By reading the doc it is not clear if we should activate this option only when
dealing with blocking sockets.
What's the behavior with non blocking ones?
Does it result in a no-op or does it hang the applcation
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment:
Mmm you're right. Sorry.
I'm clearly too tired. =)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8222
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment:
@Antoine Pitrou: ok, I think I'll have to be able to replicate the error in
order to try to fix this. I'm gonna try on FreeBSD and another Linux box later
today.
--
___
Python
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment:
Florent can you give me a clue on how to make python use OpenSSL 0.9.8k on
Ubuntu?
Despite I compiled and installed 0.9.8k from sources the system version keeps
being 0.9.8g and I guess that Python is using that one.
Do I
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment:
Ok, I've finally been able to reproduce the issue by installing OpenSSL 0.9.8m
on my Ubuntu box.
By doing some debugging I'm starting to think that maybe there's something
wrong with the shutdown() method implementation
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment:
Yes, it's the _sslobj.shutdow() call:
File test_ftplib.py, line 332, in handle_close
self.socket = self.socket.unwrap()
File /usr/local/lib/python2.7/ssl.py, line 258, in unwrap
s = self._sslobj.shutdown()
error
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment:
No I haven't, but I tried just now and I get the same error.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8108
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment:
As suggested in this thread:
http://mirt.net/pipermail/stunnel-users/2005-July/000661.html
...I made the following change to the Makefile:
- LIBS= -lpthread -ldl -lutil
+ LIBS= -lpthread -ldl -lutil -lz
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment:
I was about to open a request for this.
Thanks.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8321
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment:
import ssl
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/local/lib/python2.7/ssl.py, line 62, in module
from _ssl import OPENSSL_VERSION_NUMBER, OPENSSL_VERSION_INFO,
OPENSSL_VERSION
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment:
The ./configure - make - make install process went fine, or at least, I think
so, as it completed without reporting errors or exiting.
...But maybe I'm doing something wrong as just a little while ago I was
modifying _ssl.c
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment:
You were right: make output had an error involving ssl I didn't notice. My bad.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8321
Changes by Giampaolo Rodola' billiej...@users.sourceforge.net:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8324
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment:
def handle_error(self):
-raise
+# Ignore errors while closing, because the remote end could have
+# abruptly shut down the TCP connection while we are still
+# waiting for SSL
Giampaolo Rodola' billiej...@users.sourceforge.net 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?
ftplib.FTP_TLS class already calls unwrap
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment:
I don't understand your reasoning. These are separate connections,
closing one shouldn't affect the other.
I meant another thing. I was talking about the fact that the test server
attempts to shutdown() both control
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment:
Thinking back about this, I wonder whether FTPS could be a better name to use
instead of FTP_TLS.
It's shorter, easier to remember, and also makes more sense since also SSL can
be used, not only TLS
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment:
I'm the one who recently added FTPS support to ftplib.py and wrote tests for
both FTP and FTPS. I'm not the maintaner of the module but I'd like to be
notified in case of issues about it, so would it make sense for me
Giampaolo Rodola' billiej...@users.sourceforge.net added the comment:
Any update about this issue?
This should be marked as high priority, imho.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3823
Changes by Giampaolo Rodola' billiej...@users.sourceforge.net:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6916
Giampaolo Rodola' g.rod...@gmail.com added the comment:
If everyone agrees on error: [Errno 0] Error being a legitimate alias for a
connection closed event condition then I'd say the test server looks good,
even if I think that expecting a ssl.SSLError derived exception would have made
more
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
assignee: - giampaolo.rodola
nosy: +r.david.murray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4814
Giampaolo Rodola' g.rod...@gmail.com added the comment:
Closed as a duplicate of 6822 which provides a patch.
--
nosy: +giampaolo.rodola
resolution: - duplicate
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Giampaolo Rodola' g.rod...@gmail.com added the comment:
Fixed as r80172 (python 2.7) and r80176 (python 3.2).
--
assignee: - giampaolo.rodola
priority: - normal
resolution: - fixed
stage: - committed/rejected
status: open - closed
type: - behavior
versions: +Python 2.6, Python 2.7
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
resolution: - out of date
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1726451
Giampaolo Rodola' g.rod...@gmail.com added the comment:
Closing this out as invalid as an exception being raised after an invalid PASV
response makes perfect sense.
--
resolution: - rejected
stage: - committed/rejected
status: open - closed
type: - behavior
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6095
___
___
Python-bugs
Giampaolo Rodola' g.rod...@gmail.com added the comment:
The patch in attachment implements support for epoll() and kqueue() by adding a
new poller argument to asyncore.loop().
However, I had a chat with Jean Paul Calderone today which pointed out how
useless this is. =)
The problem
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +exarkun
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6692
___
___
Python-bugs-list
Giampaolo Rodola' g.rod...@gmail.com added the comment:
Forgot to add the patch.
--
keywords: +patch
Added file: http://bugs.python.org/file16994/asyncore.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6692
Giampaolo Rodola' g.rod...@gmail.com added the comment:
Fixed as r80226 (2.7) and r80228 (3.2).
--
components: +Library (Lib)
priority: - normal
resolution: - fixed
stage: - committed/rejected
status: open - closed
type: - behavior
___
Python
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4142
___
___
Python-bugs
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
status: pending - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3596
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
status: open - pending
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3596
___
___
Python-bugs
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8483
___
___
Python-bugs
Giampaolo Rodola' g.rod...@gmail.com added the comment:
I think the problem relies in here:
# cheap inheritance, used to pass all other attribute
# references to the underlying socket object.
def __getattr__(self, attr):
return getattr(self.socket, attr)
I wonder why
Giampaolo Rodola' g.rod...@gmail.com added the comment:
Unfortunately, even if forwarding everything to the socket is
questionable, it would probably be a really bad idea to change it,
since there is likely code in the field depending on this behavior.
I agree, even if it would break
Giampaolo Rodola' g.rod...@gmail.com added the comment:
You're absolutely right.
Patch in attachment.
--
keywords: +patch
Added file: http://bugs.python.org/file17026/asyncore.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
New submission from Giampaolo Rodola' g.rod...@gmail.com:
The patch in attachment provides actual tests for asyncore.dispatcher class
API, including all handle_* callback methods.
--
assignee: josiahcarlson
files: asyncore.patch
keywords: patch, patch
messages: 103896
nosy
Giampaolo Rodola' g.rod...@gmail.com added the comment:
should be 'listens'
[...]
should be 'bound'
done
I'd prefer to see a 'BaseTestAPI' that has no base class, and two
TestCase subclasses that use BaseTestAPI as a mixin, one for
use_poll=True and one for use_poll=False.
done
- you
Giampaolo Rodola' g.rod...@gmail.com added the comment:
Idea: wouldn't it be better to provide a more powerful accept_mail method
instead of accept_domain?
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Giampaolo Rodola' g.rod...@gmail.com added the comment:
I'm not sure how to reproduce this issue but I doubt calling close() from
__del__ would solve the problem, neither would be a good idea as close() might
end up being called more than once, which is not desirable.
Try to paste the code
Giampaolo Rodola' g.rod...@gmail.com added the comment:
Closing this out as rejected.
--
resolution: - rejected
status: open - closed
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue751758
Giampaolo Rodola' g.rod...@gmail.com added the comment:
Builbots are all ok except Solaris which makes me think that maybe asyncore is
broken on such platform:
http://python.org/dev/buildbot/builders/sparc%20solaris10%20gcc%20trunk/builds/728/steps/test/logs/stdio
I've tried to adjust the tests
Giampaolo Rodola' g.rod...@gmail.com added the comment:
Do you intend to provide a patch?
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8536
Giampaolo Rodola' g.rod...@gmail.com added the comment:
I seem to remember that those classes were initially removed and then re-added
by Josiah for backward compatibility (see discussions in issue 1641 and issue
1736190).
Despite practically useless after the changes applied to asynchat
New submission from Giampaolo Rodola' g.rod...@gmail.com:
I recently took a look at asynchat doc and found out it has some issues which
should be addressed.
In my opinion the following methods and functions should NOT be mentioned:
- async_chat.refill_buffer()
this has been removed in Python
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5565
___
___
Python-bugs
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8106
___
___
Python-bugs
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6560
___
___
Python-bugs
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7865
___
___
Python-bugs
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5178
___
___
Python-bugs
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8570
___
___
Python-bugs
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8569
___
___
Python-bugs
Giampaolo Rodola' g.rod...@gmail.com added the comment:
As per discussion with Josiah I'm leaving fifo class alone as it can still be
used also with the newer producer_fifo implementation (changed in Python 2.6).
The other changes described in my comments above still hold.
Committed in r80631
Giampaolo Rodola' g.rod...@gmail.com added the comment:
Good catch. I modified your patch a little bit including a catch for
OverflowError exception and a last attempt to look up into errno.errorcode:
def _strerror(err):
try:
return strerror(err)
except (ValueError
Giampaolo Rodola' g.rod...@gmail.com added the comment:
Assuming this is still desirable I'd really like to move forward with this
issue.
The current situation is that we have two patches.
My patch
pros:
* affects asyncore.py only
* (imho) cleaner, as it just adds one class
Giampaolo Rodola' g.rod...@gmail.com added the comment:
Attached is a patch which fixes FTP_TLS class as well and changes the test
server a little bit.
Shouldn't retrlines() suffer the same issue?
--
assignee: - giampaolo.rodola
nosy: +giampaolo.rodola
versions: +Python 3.1, Python
New submission from Giampaolo Rodola' g.rod...@gmail.com:
Similarly to issue 3972 the patch in attachment adds a new source_address
option to FTP class to bind to a specific address when connecting to a remote
FTP server.
It must be noted that this gets done for both control and passive data
Giampaolo Rodola' g.rod...@gmail.com added the comment:
Issue 8594 is related with this one.
--
superseder: - Add a source_address option to ftplib
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1661754
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8598
___
___
Python-bugs
Giampaolo Rodola' g.rod...@gmail.com added the comment:
find_unused_port is the wrong approach altogether. Uses of it should
be replaced by bind_port and then find_unused_port should be removed
I agree find_unused_port() is the wrong approach in general, but there are
certain cases where
Giampaolo Rodola' g.rod...@gmail.com added the comment:
Any time you have any API that you want to test that requires a
pre-allocated port number, you're going to have intermittent failures.
Such APIs are broken and should be fixed where possible and avoided
otherwise.
You mean
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8576
___
___
Python-bugs-list mailing list
Giampaolo Rodola' g.rod...@gmail.com added the comment:
Any time you have any API that you want to test that requires a
pre-allocated port number, you're going to have intermittent failures.
Such APIs are broken and should be fixed where possible and avoided
otherwise.
You mean
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8604
___
___
Python-bugs
Giampaolo Rodola' g.rod...@gmail.com added the comment:
Adding this:
def handle_error(self):
raise
...to SimSMTPChannel class would help to provide a clearer error message to
understand where exactly EBADF comes from, altough I think this was an old
asyncore bug which have
Giampaolo Rodola' g.rod...@gmail.com added the comment:
As per discussion on #python-dev we think it's better to proceed as follows:
for python 2.7 and 3.2:
- fix __getattr__ error message
- raise a DeprecationWarning if cheap inheritance is used and definitively
remove its support
Giampaolo Rodola' g.rod...@gmail.com added the comment:
Yes, I think it's better to remain consistent with the rest of the module which
uses %s all around the place, also for backward compatibility in case someone
wants to copy asyncore.py shipped with recent python versions and use
Giampaolo Rodola' g.rod...@gmail.com added the comment:
Done in r80882 for ftplib and smtplib modules.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3620
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7735
___
___
Python-bugs
501 - 600 of 1713 matches
Mail list logo
