Giampaolo Rodola' g.rod...@gmail.com added the comment:
It seems expected behavior to me, and the same issue should apply to all other
network libs as well. What would you expect ftplib to do in such case?
--
nosy: +giampaolo.rodola
___
Python
Giampaolo Rodola' g.rod...@gmail.com added the comment:
What storbinary does is just using a socket to send data.
There's no way for storbinary to ask the socket whether an unpredicted event
such as an IP change occurred and neither it should.
As a user, you just shouldn't change the IP
Giampaolo Rodola' g.rod...@gmail.com added the comment:
Since you say the connection hangs I think you can set a timeout:
ftp = ftplib.FTP(..., timeout=30)
That is applied to both control and data connection (and hence storbinary).
This way you should get a socket.timeout exception after 30
Giampaolo Rodola' g.rod...@gmail.com added the comment:
Python can't do that. It's a socket implementation detail. Python just exposes
the underlying socket implementation as-is.
I'm closing this out as rejected.
--
assignee: - giampaolo.rodola
resolution: - rejected
status: open
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13724
___
___
Python
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13761
___
___
Python
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13752
___
___
Python
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13822
___
___
Python
Giampaolo Rodola' g.rod...@gmail.com added the comment:
read environment varaiables [...] and raise an error if the size cannot be
read (so no need of default values). The os module is written as a thin
wrapper between Python and the OS. A more high level function (read
environment
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13846
___
___
Python
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13903
___
___
Python
Giampaolo Rodola' g.rod...@gmail.com added the comment:
why is a not connected connection writable?
A non connected socket must be writable in order to connect.
if we call dispatcher.connect() immediately after .connect(),
socket error 10057 may be raised,
Not sure what you mean here
Giampaolo Rodola' added the comment:
I don't think it is worth complicating the API for this. There have
been zero requests for this functionality. Even the doc field of
property() is rarely used.
+1
--
nosy: +giampaolo.rodola
___
Python
Giampaolo Rodola' added the comment:
Why did you replace socket.error with OSError?
I think we should use socket.create_connection() as a guide line:
http://hg.python.org/cpython/file/45dfb657b430/Lib/socket.py#l401
A patch is in attachment.
--
Added file: http://bugs.python.org
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
assignee: - giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16646
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
resolution: - fixed
stage: commit review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16646
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16692
___
___
Python
Giampaolo Rodola' added the comment:
Ouch! My bad. Thanks.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16646
___
___
Python-bugs-list mailing
Giampaolo Rodola' added the comment:
A couple of years ago I conducted similar tests and it turned out that 64k was
the best compromise:
http://code.google.com/p/pyftpdlib/issues/detail?id=94
Twisted uses 128k.
I'd be for using 64k and also change asynchat.async_chat.ac_*_buffer_size
Giampaolo Rodola' added the comment:
Patch looks fine to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16641
___
___
Python-bugs-list
Giampaolo Rodola' added the comment:
Patch looks fine to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16640
___
___
Python-bugs-list
Giampaolo Rodola' added the comment:
Sorry for chiming in so late.
The patch looks fine to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16165
Giampaolo Rodola' added the comment:
IMO no. asyncore.dispatcher_with_send should not exist in the first place as it
basically is a castrated version of asynchat.async_chat with less capabilities.
I'd say it's there only for an historical reason.
Moving ac_*_buffer_size to asyncore.dispatcher
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16802
___
___
Python
Giampaolo Rodola' added the comment:
But even in asynchat, there's a lot of copying going on, length
computations performed twice in a row, etc.
What/where do you mean exactly?
I see little value in focusing efforts towards things such as
initiate_with_send which are not supposed to be used
Giampaolo Rodola' added the comment:
memoryview is also great to avoid copies when sending/receiving to a socket.
That's interesting. How exactly? Would producer_fifo have to change from a
deque() to a memoryview() object? In that case we might have to take backward
compatibility
Giampaolo Rodola' added the comment:
New patch in attachment.
It always uses poll() and maintains and internal fd/Connection map.
I get one failure due to the returned list being sorted differently than when
using select() though
Giampaolo Rodola' added the comment:
Updated patch including test fixes is in attachment.
--
Added file: http://bugs.python.org/file28501/issue10527-3.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10527
Giampaolo Rodola' added the comment:
I know. I proposed something like that here:
http://mail.python.org/pipermail/python-ideas/2012-May/015223.html.
In theory all the necessary pieces are already there. What's missing is an
agreement on what the API should look like, and that's the hard part
Giampaolo Rodola' added the comment:
Well, for now I'd say let's just check in this patch as-is.
I would be keen on considering this a bug and hence address the patch for
Python 2.7, 3.2, 3.3 and 3.4.
--
___
Python tracker rep...@bugs.python.org
Giampaolo Rodola' added the comment:
Does asyncore expose its implementation details?
I was talking about asynchat. What is supposed to change is
asynchat.async_chat.producer_fifo attribute which is currently a
collections.deque object
Giampaolo Rodola' added the comment:
BTW, the patch looks ok to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16787
___
___
Python-bugs
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
assignee: - giampaolo.rodola
resolution: - fixed
stage: patch review - commit review
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10527
Giampaolo Rodola' added the comment:
My bad, sorry. It should be fixed now.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10527
Giampaolo Rodola' added the comment:
Previous issue should have been fixed by now.
Closing.
--
status: pending - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14807
Giampaolo Rodola' added the comment:
Is this currently being written from scratch? It shouldn't be IMO.
Instead I recommend using the existent Tornado or pyftpdlib IO loop as an
example:
https://github.com/facebook/tornado/tree/master/tornado/platform
https://github.com/facebook/tornado/blob
Giampaolo Rodola' added the comment:
@Guido: agreed.
there's no SELECT_ERR anymore [...] the error will be reported when the FD
will be read/written
I don't think this is a good idea, particularly during this early stage.
This assumption might be valid for select() but not for poll
Giampaolo Rodola' added the comment:
Inline comments:
http://bugs.python.org/review/16853/
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16853
Giampaolo Rodola' added the comment:
The actual error (which may be ECONNRESET, but also EBADF, ENOBUFS...) will
be raised
upon the next call to read()/write(), or can be retrieved through
getsockopt(SO_ERROR).
Mmmm... I would be tempted to think the same but the fact that both Tornado
Giampaolo Rodola' added the comment:
asyncore's __getattr__ horror was scheduled for removal a long ago (3.1 as per
issue8483).
We can safely remove it for 3.4 and fix the RuntimeError exception above for
all the earlier Python versions which are affected
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
assignee: - giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13103
Giampaolo Rodola' added the comment:
Ok for asyncore/asynchat in 3.4 branch.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16871
___
___
Python
Giampaolo Rodola' added the comment:
What do you mean? The intent was to use poll() instead of select() anywhere
available in order to avoid running out of fds.
The change didn't affect Windows because as of right now select() is the only
thing available
Giampaolo Rodola' added the comment:
Damn, you're right. I must have messed up something while porting the patch
from 3.2 all the way up to 3.4 as the merge produced some conflicts.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Giampaolo Rodola' added the comment:
3.3 and 3.4 branches should now be fixed.
2.7 and 3.2 still need to be fixed and the code from connections.py removed.
Sorry for the mess up.
--
assignee: giampaolo.rodola -
___
Python tracker rep
Giampaolo Rodola' added the comment:
asyncore simply does not support SSL.
That is tracked in issue 10084.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16976
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17006
___
___
Python
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16038
___
___
Python
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16042
___
___
Python
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16039
___
___
Python
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16040
___
___
Python
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16041
___
___
Python
Giampaolo Rodola' added the comment:
This discussion got very long and it's not clear (to me at least) what the
status of the patch is and whether it has been accepted for inclusion.
Maybe it makes sense to bring this up to python-dev mailing list instead of
keep stressing this thread
Giampaolo Rodola' added the comment:
ftplib.ftpcp? What is that? I do not understand what you're trying to test.
ftplib test suite is already pretty extended.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17055
Giampaolo Rodola' added the comment:
LineTooLong should be added to ftplib.all_errors.
4096 looks enough to me.
The longest lines I can think of occur when processing MLSD command which
produces an output of like this:
type=file;size=156;perm=r;modify=20071029155301;unique=801cd2; music.mp3
Giampaolo Rodola' added the comment:
See issue 9285 in which I wrote a decorator for profile/cProfile.
That can be modified to work both as a decorator or a context manager by using
contextlib.contextmanager.
Shall I continue in issue 9285 and rewrite that patch?
--
nosy
Giampaolo Rodola' added the comment:
Ok, will look into this soon.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9285
___
___
Python-bugs-list
Giampaolo Rodola' added the comment:
As for runcall() we haven't the ability to freely support kwargs *and* filename.
I see two possibilities.
Kill kwargs, as such:
+def runcall(func, *args, filename=None, sort=-1):
+Run func(*args) under profiler, optionally saving results in
+filename
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +georg.brandl
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9285
___
___
Python-bugs
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +georg.brandl
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17130
___
___
Python-bugs
Giampaolo Rodola' added the comment:
A preliminary patch for cProfile.py is in attachment. Will make changes to
profile.py later.
--
Added file: http://bugs.python.org/file29050/profile.patch
___
Python tracker rep...@bugs.python.org
http
New submission from Giampaolo Rodola':
profile and cProfile modules define the same utility functions (run() and
runctx()) which use the same code except the profiler class.
Considering that we're going to add 2 new utility functions (runcall() and
runblock(), see issue9285 and issue17130) I
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
components: +Library (Lib)
keywords: +easy -patch
versions: +Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17197
Giampaolo Rodola' added the comment:
No, it's the other way around. It's from cProfile which I import profile.
diff --git a/Lib/cProfile.py b/Lib/cProfile.py
--- a/Lib/cProfile.py
+++ b/Lib/cProfile.py
...
+import profile as _pyprofile
--
___
Python
Giampaolo Rodola' added the comment:
Patch looks ok. Just add the new exception class to all_errors list.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16038
Giampaolo Rodola' added the comment:
Of course you're right. I didn't realize that.
How about this (in attachment)?
--
keywords: +patch
Added file: http://bugs.python.org/file29106/profile-refactoring.diff
___
Python tracker rep...@bugs.python.org
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16446
___
___
Python
Giampaolo Rodola' added the comment:
I also bumped into this problem on both 2.7 and 3.3. It is very annoying.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16446
Giampaolo Rodola' added the comment:
I already posted a patch in issue 9285.
Maybe we should close this one as a duplicate.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17130
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
assignee: - giampaolo.rodola
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17197
Giampaolo Rodola' added the comment:
Ok, here's an updated patch modeled after:
http://hg.python.org/cpython/rev/422169310b7c
It works fine with cProfile.py but not with profile.py where I get this
exception when I try to use the context manager (tests can be run in order to
reproduce
Giampaolo Rodola' added the comment:
Note that is changed Giampaolo's patch to call sendfile
on the whole file, not by block.
That's not compatible across POSIX platforms.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Giampaolo Rodola' added the comment:
Ah ok, I misinterpreted what you wrote then.
Generally speaking though, you don't need to know the file size: you just
decide a blocksize (= 65536 is usually ok) and use sendfile() as you use
send
Giampaolo Rodola' added the comment:
Specifying a big blocksize doesn't mean the transfer will be faster.
send/sendfile won't send more than a certain amount of bytes anyways.
If I'm not mistaken I recall from previous benchmarks that after a certain
point (131072 or something) increasing
Giampaolo Rodola' added the comment:
The transfer won't be faster mainly because it's really I/O bound.
But it will use less CPU, only because you're making less syscalls.
Have you actually measured this?
--
___
Python tracker rep
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17338
___
___
Python
Giampaolo Rodola' added the comment:
It seems you're right, sorry. We need to take that into account then.
In the meantime I rewrote the original patch and got rid of the use_sendfile
explicit argument in order to attempt to use sendfile() by default and fall
back on using send() if bytes
Giampaolo Rodola' added the comment:
It's necessary because sendfile() can fail with EAGAIN.
As for your blocksize = filesize argument I changed my opinion: despite being
less CPU consuming we might incur into problems if that number is too big.
'count' parameter on Linux, for example
Giampaolo Rodola' added the comment:
'count' is size_t, like for mmap() and any other function accepting a
length, so nothing wrong can happen.
Then why 'offset' and 'count' parameters have a different data type?
Linux:
sendfile(..., off_t *offset, size_t count);
Solaris:
sendfile
Giampaolo Rodola' added the comment:
Because offsets can be negative
On Linux (and presumably on all POSIX platforms) passing a negative offset
results in EINVAL.
In that case, there's a problem with the patch, since select can block
arbitrarily long because it doesn't take the socket
Giampaolo Rodola' added the comment:
A much larger patch which should address all issues is in attachment.
Updates:
- use poll() instead of select() whenever possible
- take socket timeout into account
- take SSL/FTPS into account
- when using select() look for EMFILE in case num fds
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
versions: +Python 3.4 -Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13564
Giampaolo Rodola' added the comment:
I'm not sure what the OP and Gavin are complaining about in their last
messages. Could you guys be more clear and/or provide a code sample which
reproduces the problem?
--
___
Python tracker rep
Giampaolo Rodola' added the comment:
I'm not sure how many users asyncore has out there nowadays, but if it has to
stay in the stdlib then I see some value in adding a scheduler to it because it
is an essential component.
If this is still desirable I can restart working on a patch, although
Giampaolo Rodola' added the comment:
I don't understand why you must put the socket in
non-blocking mode for sendfile().
I did that mainly because I'm using select() / poll() and it seems kind of
natural to set the socket in non-blocking mode (proftpd does the same).
I'm not sure whether
Giampaolo Rodola' added the comment:
Because otherwise sendfile() fails with EAGAIN many times before sending any
actual data.
select() / poll() make sure the while loop awakens only when the socket is
ready to be written (as opposed to continuously catching EAGAIN and wait for
sendfile
Giampaolo Rodola' added the comment:
I see. Well, what I'm experiencing right now if I remove the select() / poll()
call is a sequence of EAGAIN errors alternated by successful sendfile() calls.
Either the man page is wrong or I'm missing something
Giampaolo Rodola' added the comment:
I wasn't aware of this issue (sorry) and I have already fixed this back in cset
422169310b7c for the 3.4 branch.
2.7, 3.2 and 3.3 branches can still be fixed though.
--
versions: +Python 2.7 -Python 3.4
New submission from Giampaolo Rodola':
In Python 2 the distinction between open() and codes.open() was clear because
'encoding' and 'errors' args were provided by codecs.open only.
This is no longer the case in Python 3 since both args are provided also by
open().
I'm probably missing
Giampaolo Rodola' added the comment:
Fixed, thanks.
--
assignee: - giampaolo.rodola
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17452
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5845
___
___
Python-bugs
Giampaolo Rodola' added the comment:
After digging a bit further it seems EAGAIN occurs in case a timeout was
previously set against the socket as in ftplib.FTP(..., timeout=2) (at least on
Linux, FWICT).
As such, we can debate whether avoid using select/poll if timeout was not set.
I'll
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12197
___
___
Python
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12187
___
___
Python
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8407
___
___
Python-bugs
Giampaolo Rodola' g.rod...@gmail.com added the comment:
This whole thread is becoming quite confusing.
It would be better to open a separate issue for any bug or feature request
which is not related to exposing signalfd(2) and pthread_sigmask
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12303
___
___
Python
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
assignee: giampaolo.rodola
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: inspect.getabsfile() is not documented
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9246
___
___
Python-bugs
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12139
801 - 900 of 1713 matches
Mail list logo
