"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> > I first suggested just chopping off the flowid and scopeid parts of the
> > tuple. Itojun's reply seems to indicate we could potentially get away
> > with merging the scopeid to the IP address part in a standard fashion,
> > and discarding the flow
hello,
On Sat, 24 Mar 2007, Jun-ichiro itojun Hagino wrote:
| > i understand your concern. current 4-tuple is direct mapping from
| > struct sockaddr_in6 (which has those two additional members).
|
| note however, you must rewrite DNS resolving from gethostby* to
| get*info
hello,
On Sat, 24 Mar 2007, Jun-ichiro itojun Hagino wrote:
| > i understand your concern. current 4-tuple is direct mapping from
| > struct sockaddr_in6 (which has those two additional members).
|
| note however, you must rewrite DNS resolving from gethostby* to
| get*info
hello,
On Thu, 22 Mar 2007, "Martin v. Löwis" wrote:
| >Would it be out of the question to change the IPv6 address 4-tuple to
| >a 2-tuple (as used with IPv4) in Python 2.0? This is a source of many
| >compatibility problems, and the additional flowinfo and scope elements
| >from the IPv6 tuple a
hello,
On Thu, 22 Mar 2007, Brett Cannon wrote:
| On 22 Mar 2007 19:47:50 +0200, Erno Kuusela <[EMAIL PROTECTED]> wrote:
| >Hello,
| >
| >Would it be out of the question to change the IPv6 address 4-tuple to
| >a 2-tuple (as used with IPv4) in Python 2.0? This i
Hello,
Would it be out of the question to change the IPv6 address 4-tuple to
a 2-tuple (as used with IPv4) in Python 2.0? This is a source of many
compatibility problems, and the additional flowinfo and scope elements
from the IPv6 tuple are practically never used by normal applications.
-- ern
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> Also,
> the argument about dirtying cache lines seem to be relevant to SMP
> architectures and probably doesn't apply much to Python as long as we
> have the GIL (which is not going away).
I guess the primary cost would probably be incurring the ca
Greg Ewing <[EMAIL PROTECTED]> writes:
> Edward C. Jones wrote:
>
> > Maybe some day a sufficiently portable automatic garbage collector will
> > be available for C. Until then, we'll have to live with reference counts.
>
> Even if it did become available, we might not want to
> use it. In rece
