I'd like to work on this issue:
Specifically, in my case, while IE can download a 150Mb file from a
local server in about 3 seconds, httplib takes over 20 minutes!
However, I'm kinda stumped on where to start with debugging the
difference. I've tried upping the buffer size as suggested in the issue,
but it's had no effect...
Simplistix - Content Management, Batch Processing & Python Consulting
Please can we have the following RFCs added to the references section that
cover many of the aspects covered by this PEP?
RFC 791 - Internet Protocol
RFC 1918 - Address Allocation for Private Internets
RFC 3330 - Special-Use IPv4 Addresses
RFC 4291 - IPv6 Addressing Architecture
RFC 4632 - Classless Inter-domain Routing (CIDR): The Internet Address
> Antoine Pitrou wrote:
> > Peter Moody <peter <at> hda3.com> writes:
> >> the address with all of the hosts bits masked to zero is most commonly
> >> referred to as the network address. same as the address with all of
> >> the host bits set to one is called the broadcast address. calling it
> >> something like base_address or min_address will cause quite a bit more
> >> confusion.
> > Quite a bit less IMO. I'm not a network specialist, but the "network
> Nah, network address is perfectly explicit - it's what you get when you
> bitwise and any host within that network with the netmask.
> Where it becomes confusing is that we have a property called "network"
> that returns an IPAddress object rather than an IPNetwork object.
> People that are network specialists would grasp that fairly easily, but
> we try to design standard library APIs so that they're novice friendly
> as well. And the above situation isn't novice friendly.
> To be honest, given the indexing behaviour, I'm -1 on the idea of giving
> the network address or broadcast address attribute names *at all*.
> network_address = my_net
> broadcast_address = my_net[-1]
> The only way the network address could match the number of characters in
> the indexing method is if you just called it the network id (i.e.
> my_net.id). For the broadcast address, there is no name that even comes
> close to matching the indexing approach for brevity.
> And since IPNetwork is a container for IPAddress instances, the indexing
> approach means there is zero ambiguity regarding the return type.
> -1 from me. I'm happy to see indexing made available alongside specific
properties/methods that expose the network (without mask) and broadcast
addresses for a given network object, but not to remove them from the
interface entirely in favour of indexing alone.
While it seems like a good idea, in practice it just won't work or will at
least be sub-optimal and violates the rule of least surprise (for IP
libraries anyway). I struggled along with this approach in several early
versions of netaddr but had to cave in to pressure from users after repeated
questions about where to find the broadcast and network (without mask)
Granted, there are decisions to be made about exactly what the
properties/methods should be named to avoid ambiguity, but they are
important enough to be given access to in their own right. Details in
docstrings help too ;-) 'network' and 'broadcast' are very much the
convention used pretty much everywhere (including libraries found in other
languages such as Ruby and Perl).
IPv6 doesn't support the notion of a broadcast address as part of a CIDR
network block at all. AFAIK, it is a perfect legitimate for the last address
in an IPv6 block to be used to configure a network interface. The IPv6
network object interface should possibly leave out the broadcast
property/method altogether although there are reasons to keep it in for the
sake of completeness and API consistency. The pros and cons of this need to
BTW, has anyone considered use of the term *CIDR to refer to an address +
mask object? It would certainly be less controversial than *Network which
already has too many overlapping meanings elsewhere in the interface?
Obviously we'd still have the issue of what to do with the host bits to the
right of the supplied mask (keep or discard). This is not a clear cut choice
of one or the other as it is entirely based on context. For configuring
routes, you would likely always want to discard these bits (or at least
Cisco does when adding routes). For configuring a network interface you
would most certainly want to keep them!
> Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
> Python-Dev mailing list
I've been working on code that works a lot like string.Template and in
the process, I stumbled on re.Scanner. I have two questions.
1) Is re.Scanner ever going to be official? Can I count on it being
in future versions of python? It's been there for a really long time,
so I assume so, but something that's undocumented seems that it could
be dropped easily.
2) Is there a reason that string.Template doesn't use re.Scanner? My
understanding of re.Scanner is that it is exactly what you want for
something like string.Template.
"Greg Ewing" <greg.ewing(a)canterbury.ac.nz> wrote:
>Nick Coghlan wrote:
>> Or, to put it another way, given an arbitrary host in a network (e.g.
>> your own machine or the default gateway) and the netmask for that
>> network, calculate the network address.
>Some people have claimed that the gateway address of a
>network isn't necessarily the zero address in that network.
>If that's true, then you *can't* calculate the network
>address from a host address and a netmask -- there isn't
>enough information. Furthermore, an IPNetwork object
>needs to be able to represent a network address whose
>address part contains bits that aren't in the mask.
I don't see why that would be considered a network address, then. It sounds to me like that's a host address plus a netmask.