Dino Viehland wrote:
We had a bug reported that effectively boils down to we’re not
swallowing exceptions when list calls __len__
(http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPythonWorkItemId=20598).
We can obviously make the change to catch exceptions here in
IronPython
Greetings.
I spent the morning trying to find out why the disabled tests in test_xmlrpc.py
ran so slowly on my vista box.
After much digging, I found that it boiled down to socket.create_connection()
trying to connect to localhost, port.
You see, it does a getaddrinfo() and then tries to
Kristján Valur Jónsson kristjan at ccpgames.com writes:
On Vista, it will return an AF_INET6 entry before the
AF_INET one and try connection to that. This connect() attemt fails after
approximately one second, after which we proceed to do an immediately
successful connect() call to the
On Wed, Jan 14, 2009 at 6:12 AM, Nick Coghlan ncogh...@gmail.com wrote:
Dino Viehland wrote:
We had a bug reported that effectively boils down to we're not
swallowing exceptions when list calls __len__
(
http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPythonWorkItemId=20598
).
Hi,
Le Wednesday 14 January 2009 12:23:46 Kristján Valur Jónsson, vous avez
écrit :
socket.create_connection() trying to connect to (localhost, port)
(...)
return an AF_INET6 entry before the AF_INET one and try connection
to that. This connect() attemt fails after approximately one
The fix is for the unittest only, where a server is started on a separate
thread using
Ipv4 on localhost.
Now, the problem I was describing in the mail isn't specific to xmlrpc, but for
Anyone that wants to use socket.create_connection() to create a stream socket
to a host whose name has both
Are there any current plans for 2.7/3.1 to have inet_pton() and inet_ntop()
made available via the socket module?
Not sure how feasible or difficult doing this would be across all support
Python platforms but it would certainly be useful, especially now there is
talk about adding IPv4/IPv6
Victor Stinner wrote:
Hi,
Le Wednesday 14 January 2009 12:23:46 Kristján Valur Jónsson, vous avez
écrit :
socket.create_connection() trying to connect to (localhost, port)
(...)
return an AF_INET6 entry before the AF_INET one and try connection
to that. This connect() attemt fails after
I have no idea why the connect refusal takes so long.
Maybe it's a vista thing?
from socket import *
socket(AF_INET6).connect((::1, 8080))
takes about one second to report active refusal. But so does an IPv4 connect.
Maybe it is some kind of DOS attack throttling? I couldn't find any info.
This may be way out on a limb, but could it be a reverse lookup issue?
-Original Message-
From: python-dev-bounces+billy.earney=gmail@python.org
[mailto:python-dev-bounces+billy.earney=gmail@python.org] On Behalf Of
Kristján Valur Jónsson
Sent: Wednesday, January 14, 2009 8:36
2009/1/14 DrKJam drk...@gmail.com
Are there any current plans for 2.7/3.1 to have inet_pton() and inet_ntop()
made available via the socket module?
Not sure how feasible or difficult doing this would be across all support
Python platforms but it would certainly be useful, especially now
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michael Foord wrote:
Victor Stinner wrote:
Hi,
Le Wednesday 14 January 2009 12:23:46 Kristján Valur Jónsson, vous avez
écrit :
socket.create_connection() trying to connect to (localhost, port)
(...)
return an AF_INET6 entry before the
Hardly. Successful connects complete in a jiffy, only actively refused ones
take a second to do so.
I suspect some michief in the vista tcp stack.
-Original Message-
From: python-dev-bounces+kristjan=ccpgames@python.org
[mailto:python-dev-bounces+kristjan=ccpgames@python.org]
_PyObject_LengthHint() is specified to never fail.
If any exception occurs along the way, it returns a
default value. In the context of checking for length
hints from an iterator, this seems reasonable to me.
If you want this changed, I can use a negative return
value for other than an
On Wed, Jan 14, 2009 at 10:11 AM, Raymond Hettinger pyt...@rcn.com wrote:
_PyObject_LengthHint() is specified to never fail.
If any exception occurs along the way, it returns a
default value. In the context of checking for length
hints from an iterator, this seems reasonable to me.
If you
On Vista, it will return an AF_INET6 entry before the AF_INET one and
try connection to that. This connect() attemt fails after approximately
one second, after which we proceed to do an immediately successful
connect() call to the AF_INET address.
Can you find out why it takes a second? That
Anyone that wants to use socket.create_connection() to create a
stream socket to a host whose name has both an Ipv4 and Ipv6 address.
Unless the host is listening on its Ipv6 port, an unsuccessful
connection attempt will first be made, taking approximately one
second.
Again, it is a bug in
It barfs on Macs as well: indeed, it is worse, because the connection
just fails there, rather than trying IPv6 and then falling back to IPv4.
That depends on the application. Some applications fall back (as they
should, if they added their support for IPv6 correctly), some don't.
For
I have no idea why the connect refusal takes so long.
Can you run wireshark, to find out whether it's sending out any
requests that don't get responses?
Could it be that your firewall is discarding the connection
request? (rather than sending an ICMP destination unreachable
back)
Anything
If you want this changed, I can use a negative return
value for other than an attribute error, and modify
the calling code to handle the exception.
To me this isn't worth making the code slower and
more complex. But I can also see wanting to catch
a SystemError at any possible step.
It has
Karen Tracey wrote:
There is already a bug for this, I believe:
http://bugs.python.org/issue1242657
Thanks.
Raymond, based on your other message, I kicked that issue in your direction.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
On Mon, 12 Jan 2009 19:09:28 +0100 (CET), kristjan.jonsson
python-check...@python.org wrote:
Author: kristjan.jonsson
Date: Mon Jan 12 19:09:27 2009
New Revision: 68547
Log:
Add tests for invalid format specifiers in strftime, and for handling of
invalid file descriptors in the os module.
I have no idea why the connect refusal takes so long.
Maybe it's a vista thing?
I've looked into this further. It doesn't just happen for
localhost, but also for remote hosts, and not just for IPv6,
but also for IPv4, and not just for Vista, but also for XP.
The problem is this:
1. Vista sends
Aha, thanks, since my wireshark wasn't working.
I boiled a few pints of water (thanks, Google) and came up with this:
http://support.microsoft.com/kb/175523
Here is the summary:
Note that with other implementations of TCP, such as those commonly found in
many UNIX systems, the connect() fails
And Microsoft, realizing their problem , came up with this:
http://msdn.microsoft.com/en-us/library/bb513665(VS.85).aspx
K
-Original Message-
From: python-dev-bounces+kristjan=ccpgames@python.org
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of
Kristján
Kristján Valur Jónsson wrote:
Aha, thanks, since my wireshark wasn't working.
I boiled a few pints of water (thanks, Google) and came up with this:
http://support.microsoft.com/kb/175523
Here is the summary:
Note that with other implementations of TCP, such as those commonly found in
many
Martin closed a patch http://bugs.python.org/issue4933 for adding support so
that Python runs on Haiku.
The theory is that we don't want to support minority operation systems. My view is that we should support those systems to the
extent that someone like the OP is willing to maintain the
Eric Smith wrote:
Kristján Valur Jónsson wrote:
Aha, thanks, since my wireshark wasn't working.
I boiled a few pints of water (thanks, Google) and came up with this:
http://support.microsoft.com/kb/175523
Here is the summary:
Note that with other implementations of TCP, such as those
Raymond The theory is that we don't want to support minority operation
Raymond systems. My view is that we should support those systems to
Raymond the extent that someone like the OP is willing to maintain the
Raymond handful of deltas needed to get all tests to pass (the OP's
Yet another undefined thing affecting us, Martin.
I think it's just another case of Microsoft says
it's undefined, even though the standards clearly specify
what the behavior must be, and Microsoft managed to implement
the behavior that not only violates the specification, but
also hurts users
Kristján Valur Jónsson wrote:
http://support.microsoft.com/kb/175523
Here is the summary:
Note that with other implementations of TCP, such as those commonly found in
many UNIX systems, the connect() fails immediately upon the receipt of the
first ACK/RST packet, resulting in the
And Microsoft, realizing their problem , came up with this:
http://msdn.microsoft.com/en-us/library/bb513665(VS.85).aspx
Dual-stacked sockets are a useful thing to have (so useful that
Linux made them the default, despite that the RFC says that the
default should be IPV6_V6ONLY). The Python
I'm with Martin. In these days of distributed version control systems,
I would think that the effort for the Haiku folks to maintain a branch
of Python in their own version control would be minimal. It is likely
that for each new Python version that comes out, initially it is
broken on Haiku, and
I've recently been working on generating C functions on-the-fly which inline
the C code necessary to implement the bytecode in a given Python function.
For example, this bytecode:
dis.dis(f)
2 0 LOAD_FAST0 (a)
3 LOAD_CONST 1
On Wed, Jan 14, 2009 at 4:10 PM, Guido van Rossum gu...@python.org wrote:
I'm with Martin. In these days of distributed version control systems,
I would think that the effort for the Haiku folks to maintain a branch
of Python in their own version control would be minimal. It is likely
that for
35 matches
Mail list logo
