Giampaolo Rodola' added the comment:
Can you try to figure out where it hangs exactly? I can't reproduce the issue
on Ubuntu and FreeBSD and don't have a Red Hat to test against.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Giampaolo Rodola' added the comment:
Does it hang also if you run it directly as in ./python
Lib/test/test_asynchat.py.
Perhaps you ca try ./python -m trace -t Lib/test/test_asynchat.py?
Figuring this out should be relatively easy: you can also just put prints into
test_asynchat.py yourself
Giampaolo Rodola' added the comment:
Nosying Collin Winter as per rev 531d3023b48b.
In the meantime you can try to specify a timeout for join() as in:
diff --git a/Lib/test/test_asynchat.py b/Lib/test/test_asynchat.py
--- a/Lib/test/test_asynchat.py
+++ b/Lib/test/test_asynchat.py
@@ -223,7
Giampaolo Rodola' added the comment:
Good catch!
I think we better set a general timeout so that the tests fail instead of
hanging though.
Carlos can you try the patch in attachment and confirm you see failures instead
of hangings?
--
keywords: +patch
Added file: http
Changes by Giampaolo Rodola' g.rod...@gmail.com:
Added file: http://bugs.python.org/file30285/test_asynchat.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17992
Changes by Giampaolo Rodola' g.rod...@gmail.com:
Added file: http://bugs.python.org/file30286/test_asyncore.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17992
Giampaolo Rodola' added the comment:
Nevermind. It's an easy patch so I'm going to commit it anyway.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17992
Giampaolo Rodola' added the comment:
+1 for returning None.
I haven't looked into patches but if needed feel free to borrow some code from
psutil:
Linux:
https://code.google.com/p/psutil/source/browse/psutil/_pslinux.py?spec=svn30f3c67322f99ab30ed87205245dc8394f89f0acr
New submission from Giampaolo Rodola':
I bumped into this while exposing getifaddrs() [1] in psutil:
https://code.google.com/p/psutil/issues/detail?id=376
In that case AF_LINK would be useful to distinguish MAC addresses (see also:
http://carnivore.it/2010/07/22/python_-_getifaddrs).
[1] http
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11016
___
___
Python
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17908
___
___
Python
Giampaolo Rodola' added the comment:
recv() returning an empty string has always been an alias for connection lost
though, that is why it cannot be used and I was proposing returning a new type
in Python 3.4.
Point is we're paying a bad design decision: asyncore shouldn't have asked the
user
Giampaolo Rodola' added the comment:
But on python-ideas, G. Rodola noted the following
assert \
1 == 0, \
error
[...]
and requested that the *second* or *middle* line should be reported.
No, I was suggesting (assuming it's reasonably possible in terms of
implementation
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12458
___
___
Python
New submission from Giampaolo Rodola':
Traceback (most recent call last):
File setup.py, line 221, in module
... and much more ;)
File /home/giampaolo/svn/python/3.4/Lib/distutils/core.py, line 148, in
setup
dist.run_commands()
File /home/giampaolo/svn/python/3.4/Lib/distutils
Giampaolo Rodola' added the comment:
I'm sorry, you're right.
--
resolution: - invalid
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17869
Giampaolo Rodola' added the comment:
I confirm I can reproduce this issue also in pyftpdlib:
https://code.google.com/p/pyftpdlib/issues/detail?id=255
Current proposed patch returning '' is not ideal as for asynchat '' is an alias
for 'connection lost'.
In summary recv() in case of EAGAIN should
Giampaolo Rodola' added the comment:
Patch is in attachment.
I'm a bit worried about Python versions 3.4 because this kinds of breaks
backward compatibility as recv() is not expected to return None but I see no
other saner solution.
--
keywords: +patch
Added file: http
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
keywords: +3.2regression, 3.3regression
resolution: - fixed
status: open - closed
versions: -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17707
Giampaolo Rodola' added the comment:
I think I'll just stick with the original patch.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17707
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
versions: -Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17707
___
___
Python-bugs
Giampaolo Rodola' added the comment:
Maybe I'm misinterpreting what you wrote but the test fails before the patch
and succeeds after it so what's the point in adding multiple tests with
different timeouts?
Also, rathr than using an harcoded delta, we could maybe use a fudger
factor, like
Giampaolo Rodola' added the comment:
Patch including a unittest is in attachment.
--
keywords: +patch
Added file: http://bugs.python.org/file29855/issue17707.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17707
Changes by Giampaolo Rodola' g.rod...@gmail.com:
Removed file: http://bugs.python.org/file29855/issue17707.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17707
Changes by Giampaolo Rodola' g.rod...@gmail.com:
Added file: http://bugs.python.org/file29856/issue17707.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17707
Giampaolo Rodola' added the comment:
Yeah, right. Too strict indeed. I'll get rid of the assertLessEqual statement.
Here's why Decimal is necessary:
import time
time.time() - time.time()
-9.5367431640625e-07
from decimal import Decimal
Decimal(time.time()) - Decimal(time.time())
Decimal
Giampaolo Rodola' added the comment:
Without using Decimal and without patching connections.py (hence q.get()
returns immediately) the resulting delta is mismatched:
==
FAIL: test_timeout (__main__.WithProcessesTestQueue
Giampaolo Rodola' added the comment:
You're right, sorry. I got confused by the exponential notation in
9.107589721679688e-05. Updated patch is in attachment.
--
Added file: http://bugs.python.org/file29857/issue17707.patch
___
Python tracker rep
Giampaolo Rodola' added the comment:
My patch, my fault. I'm very sorry.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17707
___
___
Python
Giampaolo Rodola' added the comment:
Assigning to me. Will get back in 1 or 2 days.
--
assignee: - giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17707
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
assignee: - giampaolo.rodola
resolution: - fixed
stage: - committed/rejected
status: open - closed
type: - enhancement
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17675
Giampaolo Rodola' added the comment:
Note that if we pass bytes to bind(), getsockname() will return str anyway:
s = socket.socket(socket.AF_UNIX)
s.bind(b'hello')
s.getsockname()
'hello'
That said, it seems more consistent to me to return str also in case of
abstract namespace.
As per
New submission from Giampaolo Rodola':
This is useful, for example, when running tests as python3 -Wa and you bump
into:
ResourceWarning: unclosed socket object, fd=8, family=2, type=2, proto=0
With this we'd get:
socket.socket fd=8, family=2, type=2, proto=0, laddr=('192.168.1.2', 37537
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17675
___
___
Python-bugs-list
New submission from Giampaolo Rodola':
(bytes vs. string)
import socket
s = socket.socket(socket.AF_UNIX)
s.getsockname()
b''
s.bind(('/tmp/temp'))
s.getsockname()
'/tmp/temp'
--
messages: 186472
nosy: giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title
Giampaolo Rodola' added the comment:
Here's a patch.
--
keywords: +patch
Added file: http://bugs.python.org/file29760/issue17683.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17683
Changes by Giampaolo Rodola' g.rod...@gmail.com:
Added file: http://bugs.python.org/file29761/socket-repr2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17675
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
title: socket.sendfile() - create_server
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17552
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
title: create_server - socket.sendfile()
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17552
Giampaolo Rodola' added the comment:
New patch in attachment includes a new 'offset' parameter, new tests and also
update file offset on return or in case of error so that file.tell() can be
used to tell how many bytes were transmitted at any time.
This way we'll avoid using a custom exception
Changes by Giampaolo Rodola' g.rod...@gmail.com:
Added file: http://bugs.python.org/file29733/socket-sendfile2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17552
Changes by Giampaolo Rodola' g.rod...@gmail.com:
Removed file: http://bugs.python.org/file29733/socket-sendfile2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17552
Changes by Giampaolo Rodola' g.rod...@gmail.com:
Added file: http://bugs.python.org/file29734/socket-sendfile2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17552
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17642
___
___
Python
New submission from Giampaolo Rodola':
I noticed 2.X version of ssl module doc does not mention different socket
methods (sendall(), accept(), etc) whereas the 3.X version does.
Patch in attachment unifies the 2 docs.
--
assignee: docs@python
components: Documentation
keywords: easy
Giampaolo Rodola' added the comment:
Shame on me and my scatterbrained head! =)
--
keywords: +patch
Added file: http://bugs.python.org/file29684/ssl-doc.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17641
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17641
Giampaolo Rodola' added the comment:
-1 from me as well. Such kind of debatable (in terms of usefulness and
inclusion) things are usually better off being served by a custom function in
user's code.
--
___
Python tracker rep...@bugs.python.org
http
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16208
___
___
Python
Giampaolo Rodola' added the comment:
Here's a patch for Tulip:
https://codereview.appspot.com/8307045
Will ping Tulip's ml as well.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17561
Giampaolo Rodola' added the comment:
Apparently the doc has already been changed and mentions that a binary file is
necessary. The unit test is legitimate and can be committed though (Victor, you
want to do it?).
--
___
Python tracker rep
Giampaolo Rodola' added the comment:
Being Tulip asynchronous I think that what it needs is an utility function
which returns *multiple* sockets as are the addresses returned by getaddrinfo()
and also possibly even disable the IPv4/6 dual stack in order to be consistent
across all platforms
Giampaolo Rodola' added the comment:
Where should I look?
Tulip is at code.google.com/p/tulip
I meant in the code (and what needs to be done/refactored exactly).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17561
Giampaolo Rodola' added the comment:
Thanks for clarifying, I have a better understanding of the problem now.
Providing a custom class instantiating two sockets looks like a dead end to me
though. To say one, what is getsockname() supposed to return? Same for
detach(), fileno(), 'family
Giampaolo Rodola' added the comment:
Agreed. Then it probably makes sense to expose also a socket.has_dual_stack()
function so that the user can pre-emptively decide whether using a custom class.
Updated draft patch is in attachment.
--
Added file: http://bugs.python.org/file29600
Giampaolo Rodola' added the comment:
I managed to write a container class which listens on multiples addresses and
uses select/poll on accept() as suggested by Charles.
FWICT it seems to work pretty well and supports non-blocking sockets and
timeouts (tested on Linux, Windows and OSX
Giampaolo Rodola' added the comment:
Yep, no prob. It would also be a good chance to test it in a real-world app.
Where should I look?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17561
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +josiah.carlson, loewis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17561
New submission from Giampaolo Rodola':
Here's a function similar to socket.create_connection() which addresses all the
repetitive tasks needed to order to create an IPv4/IPv6 agnostic server socket.
--
components: Library (Lib)
files: socket.patch
keywords: easy, needs review, patch
Giampaolo Rodola' added the comment:
What you say is right but whether the kernel supports an hybrid IPv4/6 stack or
not there's not much we can do about it anyway.
Exactly what are you suggesting with the ServerSocket class you mentioned? What
do you expect it to do?
Note that platforms
Giampaolo Rodola' added the comment:
Side note: this is how in pyftpdlib I determine whether a platform supports the
dual stack:
def support_hybrid_ip_v4_v6():
# Note: IPPROTO_IPV6 constant is broken on Windows, see:
# http://bugs.python.org/issue6926
sock = None
try
New submission from Giampaolo Rodola':
This is based on progress made in issue 13564 and aims to provide a new
sendfile() method for the socket class taking advantage of high-performance
zero-copy os.sendfile() available on most POSIX platforms.
A wrapper on top of os.sendfile() appears
Giampaolo Rodola' added the comment:
I created issue 17552 in order to discuss about socket.sendfile() addition.
--
dependencies: +socket.sendfile()
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13564
Giampaolo Rodola' added the comment:
I don't understand the point of the second member in the tuple
The 'exception' member can be useful to know the reason why sendfile() failed
and send() was used as fallback.
the timeout logic should be fixed so that the total operation
time doesn't
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
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
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:
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
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:
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
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:
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:
--
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:
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:
--
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:
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
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:
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
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:
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
601 - 700 of 1713 matches
Mail list logo
