On Wed, Jan 14, 2009 at 4:10 PM, Guido van Rossum 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 each new Pyt
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
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 t
> 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 li
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 awa
> 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 user
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
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
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 hand
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 UNIX
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 Valu
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 im
> 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 send
On Mon, 12 Jan 2009 19:09:28 +0100 (CET), "kristjan.jonsson"
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.
Modified:
python/trunk/Li
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
-
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 the
> 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 adde
> 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 inst
> 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
> 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? T
On Wed, Jan 14, 2009 at 10:11 AM, Raymond Hettinger 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 want this
_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 attribute
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] On
-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_INET
2009/1/14 DrKJam
> 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
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 AM
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.
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
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 address
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 an
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 s
On Wed, Jan 14, 2009 at 6:12 AM, Nick Coghlan 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=IronPython&WorkItemId=20598
> ).
> >
> >
Kristján Valur Jónsson 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 AF_INET ad
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 conne
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=IronPython&WorkItemId=20598).
>
>
> We can obviously make the change to catch exceptions here in
> IronPy
35 matches
Mail list logo