Re: [Python-Dev] PEP 3144 review.

[Andrew McNamara]

> > As the module stands, we have a pair of address-without-mask classes
> > called *Address, and a pair of address-with-mask classes called
> > *Network. So, sometimes when you want to record an *address* you use
> > a class called Network, and that class comes with a behaviours that
> > make no sense in the context of a singleton network end-point (it can't
> > "contain" other addresses, although it's .network can).
>
>I'm going to consistently use "address" to mean a singleton and
>"network" to mean a container in the following.

Ta. I think it's useful to have a common terminology.

>I still don't see why an address-with-mask is useful, except that the
>network is deducible as {'network': address & mask, 'mask': mask}.  Is
>there *any* other way you would *ever* use that?
>
>It seems to me that for some purposes (implementing dig(1), for
>example), an IPv4Address can contain only the address (ie, a 32-bit
>integer) as a data attribute, and (with methods for using that
>attribute) that is the minimal implementation of IPv4Address.
>
>However, there are other cases (eg, routing) where it's useful to
>associate an address with its network, and I don't see much harm in
>doing so by adding a 'network' attribute to the base class
>IPv4Address, since addresses are hardly useful except in the context
>of networks.  Of course that attribute is often going to be None (eg,
>in implementing dig(1) the remote nameserver is unlikely to tell you
>the netmask).  However, when iterating over an IPv4Network, the
>iterator can automatically fill in the 'network' attribute, and that's
>fairly cheap.

Conceptually, you sometimes need a bare address, and other times,
you need an address with an associated network (host interface
configs, router configs, etc). By AddressWithMask, I really mean
AddressWithEnoughInformationToDeriveNetworkWhenNeeded. Conveniently,
IPv4 and IPv6 addressing allows us to derive the network from the host
address combined with the netmask - in other words, we don't have to attach
a real Network object to Address objects until the user tries to access
it, and then we derive it from the address and mask.

>While to me neither the 'network' attribute nor the iterator behavior
>just described seems amazing useful in the base classes, it seems to
>me that precisely those behaviors will be reinvented over and over
>again for derived classes.  Furthermore they are natural enough that
>they won't bother people who don't need them.  (That's despite at
>least one person (IIRC it was Antoine) firmly saying "an IPv4Address
>should contain exactly one 32-bit int, no more, no less", so I could
>be wrong.)  

If you have a .network attribute on an address object, checking if an
address is in the same network as another address becomes:

addr_a in addr_b.network

As the module stands, you write that as:

addr_a in addr_b

I don't think the intent is as clear with the later.

>It seems to me that the only good reason for not having a
>'network' attribute that contains an IPv4Network instance or None is
>efficiency: the space for the attribute and the overhead of filling it
>in the iterator.  I personally can't think of an application that
>would care (from what I hear, Cisco has no interest in writing its
>routers' IP stacks in Python, amazingly enough), but in theory ...

The implementation already lazily creates most things like this.

>Finally, I agree that using IPv4Network as address-with-mask is a
>confusing, undiscoverable abuse.  In particular, I think that every
>time I went a week without using that idiom, I'd get nervous when I
>saw it again: "Are you *sure* that won't raise an error or silently
>get the lower bits masked off?!  If not now, in the next version?"

Yes.

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Paul Moore]

2009/9/17 Peter Moody :
> On Wed, Sep 16, 2009 at 8:21 PM, Andrew McNamara
>  wrote:
 I think we're in a painful middle ground now - we should either go back
 to the idea of a single class (per protocol), or make the distinctions
 clear (networks are containers and addresses are singletons).

 Personally, I think I would be happy with a single class (but I suspect
 that's just my laziness speaking). However, I think the structure and
 discipline of three classes (per protocol) may actually make the concepts
 easier to understand for non-experts.
>>>
>>>I think this is where we disagree. I don't think the added complexity
>>>does make it any easier to understand.
>>
>> I argue that we're not actually adding any complexity: yes, we add
>> a class (per protocol), but we then merely relocate functionality to
>> clarify the intended use of the classes.
>
> And I argue the moving this functionality to new classes (and adding
> new restrictions to existing classes) doesn't buy anything in the way
> of overall functionality of the module or a developer's ability to
> comprehend intended uses.

For what it's worth, Andrew's making the distinction clatified things
for *me*. Whether I am the target audience for the module (I'm not a
network expert, but on the odd occasion I need to manipulate IP
addresses in a program, and if the standard library had a module for
doing so, I'd reach for it) is up to someone else to decide, but if I
am, then my vote is for 3 classes based on the explanations I've seen
so far.

I don't see what having fewer classes buys me as the end user.

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Roundup dependency tree changes

[anatoly techtonik]

Hello,

How about allowing all authenticated users update dependency field in
Python tracker?

http://bugs.python.org/iss...@sort0=dependencies&@sortdir0=on&@sort1=&@group0=priority&@group1=&@columns=title,id,activity,dependencies,status&@pagesize=150&@startwith=0

Looks like developers with access don't have enough time to track
issue dependencies.

--anatoly t.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Antoine Pitrou]

Peter Moody  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 address" of
a network sounds quite vague to me, while things like "lower_bound", "first",
"first_address", "firstip" are immediately understandable and non-ambiguous.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] conceptual clarity

[Antoine Pitrou]

Le Thu, 17 Sep 2009 14:30:28 +1200, Greg Ewing a écrit :
> 
> 3) an Address with an attached Network
> 
> An Address could be constructed in three ways:
> 
>Address(ip_number)
> 
>Address(ip_number, network = )
> 
>Address(ip_number, mask = )
>  # constructs and attaches a suitably-masked Network instance
> 
> We could also have some_network[n] return an Address referring back to
> the network object it was obtained from.

It seems you are uselessly conflating two perfectly distinct concepts: 
Address and Network. You also haven't addresses the issue of comparing 
together (and hashing) two addresses with the same IP but pointing to a 
different network. No answer to this issue seems satisfactory and 
obviously right.

As it is, -1 from me. Either we only keep two concepts (Address and 
Network), or if we introduce a third one (AddressWithMask, whatever) for 
added practicality; but we shouldn't blur the line between the two former 
canonical concepts under the pretext that a platypus-like Address might 
be helpful in some particular situations.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] conceptual clarity

[Eric Smith]

Antoine Pitrou wrote:

Le Thu, 17 Sep 2009 14:30:28 +1200, Greg Ewing a écrit :

3) an Address with an attached Network

An Address could be constructed in three ways:

   Address(ip_number)

   Address(ip_number, network = )

   Address(ip_number, mask = )
 # constructs and attaches a suitably-masked Network instance

We could also have some_network[n] return an Address referring back to
the network object it was obtained from.


It seems you are uselessly conflating two perfectly distinct concepts: 
Address and Network. You also haven't addresses the issue of comparing 
together (and hashing) two addresses with the same IP but pointing to a 
different network. No answer to this issue seems satisfactory and 
obviously right.


As it is, -1 from me. Either we only keep two concepts (Address and 
Network), or if we introduce a third one (AddressWithMask, whatever) for 
added practicality; but we shouldn't blur the line between the two former 
canonical concepts under the pretext that a platypus-like Address might 
be helpful in some particular situations.


I completely agree with this. By keeping the concepts distinct we can 
catch mis-uses earlier. If needed, convenience functions (or classes, or 
whatever) could be layered on top. But the underlying concepts need to 
be clear.


Eric.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] conceptual clarity

[Nick Coghlan]

Eric Smith wrote:
> Antoine Pitrou wrote:
>> As it is, -1 from me. Either we only keep two concepts (Address and
>>  Network), or if we introduce a third one (AddressWithMask,
>> whatever) for added practicality; but we shouldn't blur the line
>> between the two former canonical concepts under the pretext that a
>> platypus-like Address might be helpful in some particular
>> situations.
> 
> I completely agree with this. By keeping the concepts distinct we can
>  catch mis-uses earlier. If needed, convenience functions (or
> classes, or whatever) could be layered on top. But the underlying
> concepts need to be clear.

That would be my view as well (this includes getting rid of the current
duality of IPNetwork by dropping the ip property, only accepting the
network address in the normal constructor and having a separate
constructor that allows a network object to be created from an arbitrary
  host address and a netmask)

Is-a-2.x-str-a-sequence-of-ASCII-characters-or-a-chunk-of-binary-data?'ly,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] conceptual clarity

[Eric Smith]

Nick Coghlan wrote:

Eric Smith wrote:

Antoine Pitrou wrote:

As it is, -1 from me. Either we only keep two concepts (Address and
 Network), or if we introduce a third one (AddressWithMask,
whatever) for added practicality; but we shouldn't blur the line
between the two former canonical concepts under the pretext that a
platypus-like Address might be helpful in some particular
situations.

I completely agree with this. By keeping the concepts distinct we can
 catch mis-uses earlier. If needed, convenience functions (or
classes, or whatever) could be layered on top. But the underlying
concepts need to be clear.


That would be my view as well (this includes getting rid of the current
duality of IPNetwork by dropping the ip property, only accepting the
network address in the normal constructor and having a separate
constructor that allows a network object to be created from an arbitrary
  host address and a netmask)


Yes, I think that's the best plan. I could live without AddressWithMask 
(or whatever name), but it would be a nice convenience.



Is-a-2.x-str-a-sequence-of-ASCII-characters-or-a-chunk-of-binary-data?'ly,


LOL! Perfect.

Eric.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Nick Coghlan]

Antoine Pitrou wrote:
> Peter Moody  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 address"

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*. Consider:

  network_address = my_net[0]
  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.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] conceptual clarity

[R. David Murray]

On Thu, 17 Sep 2009 at 22:32, Nick Coghlan wrote:

Eric Smith wrote:

Antoine Pitrou wrote:

As it is, -1 from me. Either we only keep two concepts (Address and
 Network), or if we introduce a third one (AddressWithMask,
whatever) for added practicality; but we shouldn't blur the line
between the two former canonical concepts under the pretext that a
platypus-like Address might be helpful in some particular
situations.


I completely agree with this. By keeping the concepts distinct we can
 catch mis-uses earlier. If needed, convenience functions (or
classes, or whatever) could be layered on top. But the underlying
concepts need to be clear.


That would be my view as well (this includes getting rid of the current
duality of IPNetwork by dropping the ip property, only accepting the
network address in the normal constructor and having a separate
constructor that allows a network object to be created from an arbitrary
 host address and a netmask)


I agree as well.  If we cannot get consensus on adding a third (or
rather fifth and sixth including IPv6) classes for AddressWithMask
(and I am no longer an advocate of doing so), then we leave it out and,
as suggested by Scott, wait and see what develops and add it later if
there is demand for it.

--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[R. David Murray]

On Wed, 16 Sep 2009 at 20:26, Peter Moody wrote:

On Wed, Sep 16, 2009 at 7:48 PM, Greg Ewing  wrote:

I'm not sure what usefulness the zero address on its own
has, but if it's considered useful enough to have an
attribute for it, calling it something like 'base_address'
would be less confusing.


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.


If 'network address' is the most common designation for this number
(and it may well be), then 'network.address' and 'network.broadcast'
would seem to be the best choices for names.  But there is definitely
an attraction to the idea (I think it was Nick's?) of dropping these
attributes entirely and just using indexing to get the addresses.
That will make perfect sense to network professionals, and by putting
appropriate words in the documentation will educate people new to IP
addressing concepts.  The advantage is that it is completely unambiguous:
the network address really is the first address in the network range,
and the broadcast really is the last, in common usage.  Exceptional cases
can then be handled by custom subclasses, without having someone who
has to handle weird broadcast addresses (for example) submitting a bug
request to make '.broadcast' settable.

--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Eric Smith]

Nick Coghlan wrote:

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*. Consider:

  network_address = my_net[0]
  broadcast_address = my_net[-1]


My only concern with this is a possible performance issue with v6 
networks. Would this be implemented such that [-1] doesn't need to 
iterate through the (possibly large) address space of a v6 network?


I think it could (and would) be implemented efficiently, so I'm +1 on 
not giving these names, but adding this "recipe" to the documentation 
instead.


Eric.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[DrKJam]

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

Dave M.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Antoine Pitrou]

Le Mon, 14 Sep 2009 09:44:12 -0700, Peter Moody a écrit :
> Folks, Guido,
> 
> I believe PEP 3144 is ready for your review.  When you get a chance, can
> you take a look/make a pronouncement?

I might add that, according to the whole discussion, it seems not all of 
the API is exposed in the PEP. Would it be possible to cover more of the 
API in the PEP, to be sure we don't overlook anything?

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Daniel Stutzbach]

On Thu, Sep 17, 2009 at 9:26 AM, DrKJam  wrote:

> 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
>

+1

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Peter Moody]

On Thu, Sep 17, 2009 at 7:26 AM, DrKJam  wrote:
> 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

Sure, can you give me an idea of what specifically you're looking to
the rfc's to clarify? simply adding 5 rfc's to the the PEP wouldn't
seem to enhance its readability.

> Dave M.
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/python-dev%40hda3.com
>
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Fwd: PEP 3144 review.

[DrKJam]

>
> Antoine Pitrou wrote:
> > Peter Moody  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
> address"
>
> 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*.
> Consider:
>
>  network_address = my_net[0]
>  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)
addresses!

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
be considered.

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!


> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ---
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/drkjam%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Peter Moody]

On Thu, Sep 17, 2009 at 7:32 AM, Antoine Pitrou  wrote:
> Le Mon, 14 Sep 2009 09:44:12 -0700, Peter Moody a écrit :
>> Folks, Guido,
>>
>> I believe PEP 3144 is ready for your review.  When you get a chance, can
>> you take a look/make a pronouncement?
>
> I might add that, according to the whole discussion, it seems not all of
> the API is exposed in the PEP. Would it be possible to cover more of the
> API in the PEP, to be sure we don't overlook anything?

sounds good.

todo += more api in the pep

Cheers,
/peter

> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/python-dev%40hda3.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Peter Moody]

On Thu, Sep 17, 2009 at 6:25 AM, Eric Smith  wrote:
> Nick Coghlan wrote:
>>
>> 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*.
>> Consider:
>>
>>  network_address = my_net[0]
>>  broadcast_address = my_net[-1]
>
> My only concern with this is a possible performance issue with v6 networks.
> Would this be implemented such that [-1] doesn't need to iterate through the
> (possibly large) address space of a v6 network?
>
> I think it could (and would) be implemented efficiently, so I'm +1 on not
> giving these names, but adding this "recipe" to the documentation instead.

indexing is plenty efficient, but the problem is that these names for
these attributes are common to the point of causing confusion if
they're omitted.

Cheers,
/peter

> Eric.
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/python-dev%40hda3.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Eric Smith]

Peter Moody wrote:


indexing is plenty efficient, but the problem is that these names for
these attributes are common to the point of causing confusion if
they're omitted.


After thinking about it some more, I'm okay with names for [-1] and [0]. 
I like .broadcast, and I can live with .network (although it's 
confusing, since in my view it should return an address, not a network).


Eric.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fwd: PEP 3144 review.

[Antoine Pitrou]

DrKJam  gmail.com> writes:
> 
> BTW, has anyone considered use of the term *CIDR to refer to an address + mask
object?

This sounds too obscure for a non-specialist.

> 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!

When configuring a network interface you are not specifying a network, you are
specifying two things:
- a host address to which the interface is bound (all bits significant)
- a network to which the interface is connected (lower bits non-significant)

As someone pointed out, the fact that you are specifying a single string like
"10.0.1.7/8" is just a notational convenience.

Therefore, it seems clear to me that Network objects should ignore (and perhaps
zero out) the host bits at the right of the netmask. When you configure an
interface from the aforementioned notational convenience, you should retrieve
two objects, a Network, and an Address.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fwd: PEP 3144 review.

[R. David Murray]

On Thu, 17 Sep 2009 at 15:44, DrKJam wrote:

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).


Interesting.  Out of curiosity I searched for 'perl ip address' and
found Net::IP (http://search.cpan.org/dist/Net-IP/IP.pm).  This package
appears to use the same object class for both addresses and networks.
It has neither a 'network' nor a 'broadcast' attribute; instead it has
'ip' (it isn't clear from the docs if that returns the network address
or the IP that was passed in to the constructor) and 'last_ip'.

--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] re.Scanner and string.Template

[nathan binkert]

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.

Thanks,

  Nate Binkert
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] re.Scanner and string.Template

[Benjamin Peterson]

2009/9/17 nathan binkert :
> 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.

See http://bugs.python.org/issue5337.

> 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.

Perhaps because it wasn't documented. :)



-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] conceptual clarity

[Peter Moody]

On Thu, Sep 17, 2009 at 5:32 AM, Nick Coghlan  wrote:
> Eric Smith wrote:
>> Antoine Pitrou wrote:
>>> As it is, -1 from me. Either we only keep two concepts (Address and
>>>  Network), or if we introduce a third one (AddressWithMask,
>>> whatever) for added practicality; but we shouldn't blur the line
>>> between the two former canonical concepts under the pretext that a
>>> platypus-like Address might be helpful in some particular
>>> situations.
>>
>> I completely agree with this. By keeping the concepts distinct we can
>>  catch mis-uses earlier. If needed, convenience functions (or
>> classes, or whatever) could be layered on top. But the underlying
>> concepts need to be clear.
>
> That would be my view as well (this includes getting rid of the current
> duality of IPNetwork by dropping the ip property, only accepting the
> network address in the normal constructor and having a separate
> constructor that allows a network object to be created from an arbitrary
>  host address and a netmask)

Again, the same error-catching functionality can be obtained through
an option to the constructor. network and broadcast attributes can be
renamed to .\1_address to alleviate confusion as well.

I mentioned before that IPy's insistence on receiving masked out
networks was one of the main reasons I wrote ipaddr to begin with.
Having ipaddr mimic this behavior would make it significantly less
useful. Removing functionality in the name of avoiding confusion
doesn't make sense when the same confusion can be alleviated w/o the
loss.

off to patch the pep and implement some of the non controversial changes.
/peter

> Is-a-2.x-str-a-sequence-of-ASCII-characters-or-a-chunk-of-binary-data?'ly,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ---
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/python-dev%40hda3.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] conceptual clarity

[Antoine Pitrou]

Peter Moody  hda3.com> writes:
> 
> Again, the same error-catching functionality can be obtained through
> an option to the constructor. network and broadcast attributes can be
> renamed to .\1_address to alleviate confusion as well.

My remark was not targetting error-catching of non-zero low bits, it was about
the suggestion to have a "network" or "mask" attribute on Address objects.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] conceptual clarity

[Peter Moody]

On Thu, Sep 17, 2009 at 9:26 AM, Antoine Pitrou  wrote:
> Peter Moody  hda3.com> writes:
>>
>> Again, the same error-catching functionality can be obtained through
>> an option to the constructor. network and broadcast attributes can be
>> renamed to .\1_address to alleviate confusion as well.
>
> My remark was not targetting error-catching of non-zero low bits, it was about
> the suggestion to have a "network" or "mask" attribute on Address objects.

If I'm reading your reply correctly, then I agree that having a
network attribute on an address object doesn't make sense.

My remark was targeting Eric's reply of, "By keeping the concepts
distinct we can catch mis-uses earlier."

Cheers,
/peter

> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/python-dev%40hda3.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Misc/maintainers.rst

[R. David Murray]

I floated a proposal on stdlib-sig to create a file named
Misc/maintainers.rst.  The purpose of this file is to collect knowledge
about who knows which modules well enough to make decision about issues
in the tracker when the participants in the issue aren't sure, and to
write down the community knowledge about who has special interest and
expertise in specific topic areas.

This proposal was met with approval and, after a couple of small
modifications of the proposal, no dissent; so I've created the skeleton
of the file.  I've filled in some of the blanks where I had personal
knowledge, was told info on IRC, from the two referenced PEPs, and
from PEP 11.

Feel free to respond with comments about the header text, but more
importantly let me know what you know about who (especially if it is you)
should be listed for each module, platform, and topic, and feel free to
suggest additional topics.  My goal is to record the community knowledge.

Another topic of discussion that is orthogonal to filling in the table is
whether or not to publish it outside the repository.  Jesse would like to
see it included in the Python Documentation, and Georg has suggested the
possibility of creating a separate, sphinx-based, automatically-uploaded
document collection in the repository to contain this and related
information (Misc/devdocs?).

The module list was built from the py3k documentation module index, with
the addition of 'pybench' from PEP 291.  If there are other modules/tools
that are missing, or submodules that should be broken out into
separate lines, please let me know.

After the initial flurry of updates and comments dies down I will check
this in.

--David

--
Maintainers Index
=

This document cross references Python Modules (first table) and platforms
(second table) with the Tracker user names of people who are experts
and/or resources for that module or platform.  This list is intended
to be used by issue submitters, issue triage people, and other issue
participants to find people to add to the nosy list or to contact
directly by email for help and decisions on feature requests and bug
fixes.  People on this list may be asked to render final judgement on a
feature or bug.  If no active maintainer is listed for a given module,
then questionable changes should go to python-dev, while any other issues
can and should be decided by any committer.

The last part of this document is a third table, listing broader topic
areas in which various people have expertise.  These people can also
be contacted for help, opinions, and decisions when issues involve
their areas.

If a listed maintainer does not respond to requests for comment for an
extended period (three weeks or more), they should be marked as inactive
in this list by placing the word 'inactive' in parenthesis behind their
tracker id.  They are of course free to remove that inactive mark at
any time.

Committers should update this table as their areas of expertise widen.
New topics may be added to the third table at will.

The existence of this list is not meant to indicate that these people
*must* be contacted for decisions; it is, rather, a resource to be used
by non-committers to find responsible parties, and by committers who do
not feel qualified to make a decision in a particular context.

See also `PEP 291`_ and `PEP 360`_ for information about certain modules
with special rules.

.. _`PEP 291`: http://www.python.org/dev/peps/pep-0291/
.. _`PEP 360`: http://www.python.org/dev/peps/pep-0360/


==  ===
Module  Maintainers
==  ===
__future__
__main__gvanrossum
_dummy_thread   brett.cannon
_thread
abc
aifcr.david.murray
array
ast
asynchatjosiahcarlson
asyncorejosiahcarlson
atexit
audioop
base64
bdb
binascii
binhex
bisect
builtins
bz2
calendar
cgi
cgitb
chunk
cmath
cmd
code
codecs
codeop
collections
colorsys
compileall
configparser
contextlib
copy
copyreg
cProfile
crypt
csv
ctypes  theller
curses
datetime
dbm
decimal
difflib
dis
distutils   tarek
doctest
dummy_threading brett.cannon
email   barry
encodings
errno
exceptions
fcntl
filecmp
fileinput
fnmatch
formatter
fpectl
fractions
ftplib
functools
gc
getopt
getpass
gettext
glob
grp
gzip
hashlib
heapq
hmac
html
http
imaplib
imghdr
imp
importlib   brett.cannon
inspect
io  pitrou, benjamin.peterson
itertools
json
keyword
lib2to3 benjamin.peterson
linecache
locale
logging vsajip
macpath
mailbox
mailcap
marshal
math
mimetypes
mmap
modulefindertheller, jvr
msilib
msvcrt
multiprocessing jnoller
netrc
nis
nntplib
numbers
operator
optparsearonacher
os
ossaudiodev
parser
pdb
pickle
pickletools
pipes
pkgutil
platformlemburg
plistlib
poplib
posix
pprint
pstats
pty
pwd
py_compile
pybench lembur

Re: [Python-Dev] Fwd: PEP 3144 review.

[Steven D'Aprano]

On Fri, 18 Sep 2009 12:44:04 am DrKJam wrote:

> 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 be considered.

This seems to me to be rather weird: that for the sake of completeness 
and consistency you're considering to give an object which (allegedly) 
has no notion of "broadcast address" a broadcast address method.

If so, I can see three options. Given an appropriate IPv6 object:

obj.broadcast() always returns None.

obj.broadcast() always raises an exception.

obj.broadcast() always returns something which is not a broadcast 
address.

I would hope the third option isn't being seriously considered! Are 
there any reasons to consider the first two?



-- 
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] conceptual clarity

[R. David Murray]

On Thu, 17 Sep 2009 at 09:16, Peter Moody wrote:

I mentioned before that IPy's insistence on receiving masked out
networks was one of the main reasons I wrote ipaddr to begin with.
Having ipaddr mimic this behavior would make it significantly less
useful. Removing functionality in the name of avoiding confusion
doesn't make sense when the same confusion can be alleviated w/o the
loss.


We're suggesting moving that functionality (accepting a non-masked IP
plus netmask and returning the corresponding Network object) into
a different constructor, not eliminating the functionality.

--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] conceptual clarity

[Peter Moody]

On Thu, Sep 17, 2009 at 10:32 AM, R. David Murray  wrote:
> On Thu, 17 Sep 2009 at 09:16, Peter Moody wrote:
>>
>> I mentioned before that IPy's insistence on receiving masked out
>> networks was one of the main reasons I wrote ipaddr to begin with.
>> Having ipaddr mimic this behavior would make it significantly less
>> useful. Removing functionality in the name of avoiding confusion
>> doesn't make sense when the same confusion can be alleviated w/o the
>> loss.
>
> We're suggesting moving that functionality (accepting a non-masked IP
> plus netmask and returning the corresponding Network object) into
> a different constructor, not eliminating the functionality.

Do you mean a new constructor function, ala IPAddress and IPNetwork
(so the current classes remain largely the same and the various
constructors enforce certain restrictions) or something else?

At this point, I'm getting confused with the intermingling of class
and constructor names.

Cheers,
/peter

> --David
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Misc/maintainers.rst

[Georg Brandl]

R. David Murray schrieb:
> I floated a proposal on stdlib-sig to create a file named
> Misc/maintainers.rst.  The purpose of this file is to collect knowledge
> about who knows which modules well enough to make decision about issues
> in the tracker when the participants in the issue aren't sure, and to
> write down the community knowledge about who has special interest and
> expertise in specific topic areas.
> 
> This proposal was met with approval and, after a couple of small
> modifications of the proposal, no dissent; so I've created the skeleton
> of the file.  I've filled in some of the blanks where I had personal
> knowledge, was told info on IRC, from the two referenced PEPs, and
> from PEP 11.
> 
> Feel free to respond with comments about the header text, but more
> importantly let me know what you know about who (especially if it is you)
> should be listed for each module, platform, and topic, and feel free to
> suggest additional topics.  My goal is to record the community knowledge.

One thing I'd like to see in the list are real names of committers,
not tracker names.  Of course, people looking for people to assign a bug
to should not have to search for the tracker name, so I'd like to make
another request (that Brett already made when we switched trackers):

  Could we *please* have tracker names that match the committer names?

(This doesn't even need to be done by the individual users, I would
volunteer to rename all committer accounts and notify them by email that
their name changed.  This will also be coordinated with the new names
used for Mercurial commits, if a change will be made.)

> Another topic of discussion that is orthogonal to filling in the table is
> whether or not to publish it outside the repository.  Jesse would like to
> see it included in the Python Documentation, and Georg has suggested the
> possibility of creating a separate, sphinx-based, automatically-uploaded
> document collection in the repository to contain this and related
> information (Misc/devdocs?).

For those who aren't on stdlib-sig, I'd like to elaborate a bit on that:
There are quite a few resources for and about Python core development,
but they aren't very accessible.  For example, there's Misc/developers.txt
and the upcoming maintainers.txt.  Then there's the dev FAQ, but it's not
maintained where developers usually look, but on the website.  Etc.
So the plan would be to consolidate these into another set of rst docs,
having them in the repo, editable by every committer, as well as published
somewhere on python.org (devdocs.python.org or somesuch).

cheers,
Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Steven D'Aprano]

On Thu, 17 Sep 2009 10:40:47 pm Nick Coghlan wrote:
> Antoine Pitrou wrote:
> > Peter Moody  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 address"
>
> Nah, network address is perfectly explicit - it's what you get when
> you bitwise and any host within that network with the netmask.

[soapbox]
I really wish people would stop misusing the word "explicit" to mean 
(apparently) "I know how this is commonly defined".

To a non-specialist, "the network address" is ambiguous. There are many 
addresses in a network, and none of them are the entire network. It's 
like saying, given a list [2, 4, 8, 12], what's "the list item"?

If network specialists have a convention of calling hostadd&netmask "the 
network address", that's fine. It's jargon which seems illogical to me, 
but if it's useful and in common use, specialists will expect us to 
support it. But it's not explicit, it's a definition.


> 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.

+1000 on this!


> 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*. Consider:
>
>   network_address = my_net[0]
>   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.

Is brevity so much more important than clarity and discoverability?




-- 
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[David Moss]

On 17 Sep 2009, at 15:40, Peter Moody  wrote:


On Thu, Sep 17, 2009 at 7:26 AM, DrKJam  wrote:
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


Sure, can you give me an idea of what specifically you're looking to
the rfc's to clarify? simply adding 5 rfc's to the the PEP wouldn't
seem to enhance its readability.


I would hope that these RFCs form the technical basis upon which much  
of this library depends.





Dave M.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/python-dev%40hda3.com



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Misc/maintainers.rst

[Brett Cannon]

On Thu, Sep 17, 2009 at 10:38, Georg Brandl  wrote:
> R. David Murray schrieb:
>> I floated a proposal on stdlib-sig to create a file named
>> Misc/maintainers.rst.  The purpose of this file is to collect knowledge
>> about who knows which modules well enough to make decision about issues
>> in the tracker when the participants in the issue aren't sure, and to
>> write down the community knowledge about who has special interest and
>> expertise in specific topic areas.
>>
>> This proposal was met with approval and, after a couple of small
>> modifications of the proposal, no dissent; so I've created the skeleton
>> of the file.  I've filled in some of the blanks where I had personal
>> knowledge, was told info on IRC, from the two referenced PEPs, and
>> from PEP 11.
>>
>> Feel free to respond with comments about the header text, but more
>> importantly let me know what you know about who (especially if it is you)
>> should be listed for each module, platform, and topic, and feel free to
>> suggest additional topics.  My goal is to record the community knowledge.
>
> One thing I'd like to see in the list are real names of committers,
> not tracker names.  Of course, people looking for people to assign a bug
> to should not have to search for the tracker name, so I'd like to make
> another request (that Brett already made when we switched trackers):
>
>  Could we *please* have tracker names that match the committer names?
>
> (This doesn't even need to be done by the individual users, I would
> volunteer to rename all committer accounts and notify them by email that
> their name changed.  This will also be coordinated with the new names
> used for Mercurial commits, if a change will be made.)
>
>> Another topic of discussion that is orthogonal to filling in the table is
>> whether or not to publish it outside the repository.  Jesse would like to
>> see it included in the Python Documentation, and Georg has suggested the
>> possibility of creating a separate, sphinx-based, automatically-uploaded
>> document collection in the repository to contain this and related
>> information (Misc/devdocs?).
>
> For those who aren't on stdlib-sig, I'd like to elaborate a bit on that:
> There are quite a few resources for and about Python core development,
> but they aren't very accessible.  For example, there's Misc/developers.txt
> and the upcoming maintainers.txt.  Then there's the dev FAQ, but it's not
> maintained where developers usually look, but on the website.  Etc.
> So the plan would be to consolidate these into another set of rst docs,
> having them in the repo, editable by every committer, as well as published
> somewhere on python.org (devdocs.python.org or somesuch).

dev.python.org would be nice to have, from which we can simply
redirect www.python.org/dev/ to dev.python.org. www.python.org/dev/
can then get cleaned up be made simpler to navigate and more obvious
for how people can get started.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Misc/maintainers.rst

[Brett Cannon]

Looks great to me! Only thing missing that I can think of is sticking
Eric down as the guy who does str.format(). =)

On Thu, Sep 17, 2009 at 10:14, R. David Murray  wrote:
> I floated a proposal on stdlib-sig to create a file named
> Misc/maintainers.rst.  The purpose of this file is to collect knowledge
> about who knows which modules well enough to make decision about issues
> in the tracker when the participants in the issue aren't sure, and to
> write down the community knowledge about who has special interest and
> expertise in specific topic areas.
>
> This proposal was met with approval and, after a couple of small
> modifications of the proposal, no dissent; so I've created the skeleton
> of the file.  I've filled in some of the blanks where I had personal
> knowledge, was told info on IRC, from the two referenced PEPs, and
> from PEP 11.
>
> Feel free to respond with comments about the header text, but more
> importantly let me know what you know about who (especially if it is you)
> should be listed for each module, platform, and topic, and feel free to
> suggest additional topics.  My goal is to record the community knowledge.
>
> Another topic of discussion that is orthogonal to filling in the table is
> whether or not to publish it outside the repository.  Jesse would like to
> see it included in the Python Documentation, and Georg has suggested the
> possibility of creating a separate, sphinx-based, automatically-uploaded
> document collection in the repository to contain this and related
> information (Misc/devdocs?).
>
> The module list was built from the py3k documentation module index, with
> the addition of 'pybench' from PEP 291.  If there are other modules/tools
> that are missing, or submodules that should be broken out into
> separate lines, please let me know.
>
> After the initial flurry of updates and comments dies down I will check
> this in.
>
> --David
>
> --
> Maintainers Index
> =
>
> This document cross references Python Modules (first table) and platforms
> (second table) with the Tracker user names of people who are experts
> and/or resources for that module or platform.  This list is intended
> to be used by issue submitters, issue triage people, and other issue
> participants to find people to add to the nosy list or to contact
> directly by email for help and decisions on feature requests and bug
> fixes.  People on this list may be asked to render final judgement on a
> feature or bug.  If no active maintainer is listed for a given module,
> then questionable changes should go to python-dev, while any other issues
> can and should be decided by any committer.
>
> The last part of this document is a third table, listing broader topic
> areas in which various people have expertise.  These people can also
> be contacted for help, opinions, and decisions when issues involve
> their areas.
>
> If a listed maintainer does not respond to requests for comment for an
> extended period (three weeks or more), they should be marked as inactive
> in this list by placing the word 'inactive' in parenthesis behind their
> tracker id.  They are of course free to remove that inactive mark at
> any time.
>
> Committers should update this table as their areas of expertise widen.
> New topics may be added to the third table at will.
>
> The existence of this list is not meant to indicate that these people
> *must* be contacted for decisions; it is, rather, a resource to be used
> by non-committers to find responsible parties, and by committers who do
> not feel qualified to make a decision in a particular context.
>
> See also `PEP 291`_ and `PEP 360`_ for information about certain modules
> with special rules.
>
> .. _`PEP 291`: http://www.python.org/dev/peps/pep-0291/
> .. _`PEP 360`: http://www.python.org/dev/peps/pep-0360/
>
>
> ==  ===
> Module              Maintainers
> ==  ===
> __future__
> __main__            gvanrossum
> _dummy_thread       brett.cannon
> _thread
> abc
> aifc                r.david.murray
> array
> ast
> asynchat            josiahcarlson
> asyncore            josiahcarlson
> atexit
> audioop
> base64
> bdb
> binascii
> binhex
> bisect
> builtins
> bz2
> calendar
> cgi
> cgitb
> chunk
> cmath
> cmd
> code
> codecs
> codeop
> collections
> colorsys
> compileall
> configparser
> contextlib
> copy
> copyreg
> cProfile
> crypt
> csv
> ctypes              theller
> curses
> datetime
> dbm
> decimal
> difflib
> dis
> distutils           tarek
> doctest
> dummy_threading     brett.cannon
> email               barry
> encodings
> errno
> exceptions
> fcntl
> filecmp
> fileinput
> fnmatch
> formatter
> fpectl
> fractions
> ftplib
> functools
> gc
> getopt
> getpass
> gettext
> glob
> grp
> gzip
> hashlib
> heapq
> hmac
> html
> http
> imaplib
> imghdr
> imp
> importlib           brett.cannon
> inspect
> io                  pitrou, benjamin.pe

Re: [Python-Dev] PEP 3144 review.

[Peter Moody]

On Thu, Sep 17, 2009 at 10:50 AM, David Moss  wrote:
> On 17 Sep 2009, at 15:40, Peter Moody  wrote:
>
>> On Thu, Sep 17, 2009 at 7:26 AM, DrKJam  wrote:
>>>
>>> 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
>>
>> Sure, can you give me an idea of what specifically you're looking to
>> the rfc's to clarify? simply adding 5 rfc's to the the PEP wouldn't
>> seem to enhance its readability.
>
> I would hope that these RFCs form the technical basis upon which much of
> this library depends.

yes, and my question was is there something(s) in particular you wish
to see highlighted which will help clarify some confusion you
currently have, or do you feel that simply adding 5 rfc's to the
references section adds to the overall readability of the PEP?

see http://www.python.org/dev/peps/pep-0333/ for an example of what I mean.

>>
>>> Dave M.
>>>
>>> ___
>>> Python-Dev mailing list
>>> Python-Dev@python.org
>>> http://mail.python.org/mailman/listinfo/python-dev
>>> Unsubscribe:
>>> http://mail.python.org/mailman/options/python-dev/python-dev%40hda3.com
>>>
>>>
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] conceptual clarity

[R. David Murray]

On Thu, 17 Sep 2009 at 10:38, Peter Moody wrote:

On Thu, Sep 17, 2009 at 10:32 AM, R. David Murray  wrote:

On Thu, 17 Sep 2009 at 09:16, Peter Moody wrote:


I mentioned before that IPy's insistence on receiving masked out
networks was one of the main reasons I wrote ipaddr to begin with.
Having ipaddr mimic this behavior would make it significantly less
useful. Removing functionality in the name of avoiding confusion
doesn't make sense when the same confusion can be alleviated w/o the
loss.


We're suggesting moving that functionality (accepting a non-masked IP
plus netmask and returning the corresponding Network object) into
a different constructor, not eliminating the functionality.


Do you mean a new constructor function, ala IPAddress and IPNetwork
(so the current classes remain largely the same and the various
constructors enforce certain restrictions) or something else?

At this point, I'm getting confused with the intermingling of class
and constructor names.


I mean, eg, IPv4Network.fromHostIP('192.168.1.1/24').

Or some such name.

Having another constructor that took an IPv4Address object and a mask
would probably be a good idea as well.  These could be exposed as
appropriately named module level functions instead/as well, of course.

I would have IPv4Address itself be strict, and thus the new constructors
would compute the network address and call the regular IPv4Address
constructor.(*)

--David

(*) If that's the part you object to (not recording the input IP
in the Network object), then clearly you see a need to have an
AddressWithMask object of _some_ sort
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Misc/maintainers.rst

[R. David Murray]

On Thu, 17 Sep 2009 at 10:59, Brett Cannon wrote:

On Thu, Sep 17, 2009 at 10:38, Georg Brandl  wrote:

??Could we *please* have tracker names that match the committer names?

(This doesn't even need to be done by the individual users, I would
volunteer to rename all committer accounts and notify them by email that
their name changed. ??This will also be coordinated with the new names
used for Mercurial commits, if a change will be made.)


+1 from me. It would be nice to not have to look up what tracker name
someone uses since I know everyone's committer name.


+1 from me as well.  And speaking of names, people should feel free to
email me maintainer info for the table as real names.  Whether or
not Georg's proposal goes through I'll make the table reflect the
correct tracker ids.

--David___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Steven D'Aprano]

On Thu, 17 Sep 2009 05:15:16 pm Andrew McNamara wrote:

> Conceptually, you sometimes need a bare address, and other times,
> you need an address with an associated network (host interface
> configs, router configs, etc). By AddressWithMask, I really mean 
> AddressWithEnoughInformationToDeriveNetworkWhenNeeded. Conveniently,
> IPv4 and IPv6 addressing allows us to derive the network from the
> host address combined with the netmask - in other words, we don't
> have to attach a real Network object to Address objects until the
> user tries to access it, and then we derive it from the address and
> mask.

To clarify: when you say "derive the network" are you talking about the 
network (which is a container) or the network address = host_address & 
netmask (which is not a container)? I think you're referring to the 
later.

If there's need for address+netmask, does it need to be a separate 
class? Perhaps Address objects could simply have a netmask property, 
defaulting to None. If you need an "address with mask" object, you 
create an Address and set the mask:

addr = Address(...)
addr.netmask = "255.255.255.0"

The caller is responsible for ensuring the netmask has been set before 
trying to use it:

network_address = addr & addr.netmask



> If you have a .network attribute on an address object, checking if an
> address is in the same network as another address becomes:
>
> addr_a in addr_b.network
>
> As the module stands, you write that as:
>
> addr_a in addr_b
>
> I don't think the intent is as clear with the later.

I would find the later completely unclear and disturbing -- how can one 
address contain another address?



-- 
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[A.M. Kuchling]

On Thu, Sep 17, 2009 at 10:59:22AM -0700, Peter Moody wrote:
> currently have, or do you feel that simply adding 5 rfc's to the
> references section adds to the overall readability of the PEP?

I would list them simply because it's not obvious which RFC specifies
the format of IP addresses or how they're allocated.  e.g. if I search
for "rfc ip address format", most of the hits are for RFC 3587,
"IPv6 Global Unicast Address Format", which doesn't actually explain
IPv6 address syntax.

--amk
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Misc/maintainers.rst

[Brett Cannon]

On Thu, Sep 17, 2009 at 10:38, Georg Brandl  wrote:
> R. David Murray schrieb:
>> I floated a proposal on stdlib-sig to create a file named
>> Misc/maintainers.rst.  The purpose of this file is to collect knowledge
>> about who knows which modules well enough to make decision about issues
>> in the tracker when the participants in the issue aren't sure, and to
>> write down the community knowledge about who has special interest and
>> expertise in specific topic areas.
>>
>> This proposal was met with approval and, after a couple of small
>> modifications of the proposal, no dissent; so I've created the skeleton
>> of the file.  I've filled in some of the blanks where I had personal
>> knowledge, was told info on IRC, from the two referenced PEPs, and
>> from PEP 11.
>>
>> Feel free to respond with comments about the header text, but more
>> importantly let me know what you know about who (especially if it is you)
>> should be listed for each module, platform, and topic, and feel free to
>> suggest additional topics.  My goal is to record the community knowledge.
>
> One thing I'd like to see in the list are real names of committers,
> not tracker names.  Of course, people looking for people to assign a bug
> to should not have to search for the tracker name, so I'd like to make
> another request (that Brett already made when we switched trackers):
>
>  Could we *please* have tracker names that match the committer names?
>
> (This doesn't even need to be done by the individual users, I would
> volunteer to rename all committer accounts and notify them by email that
> their name changed.  This will also be coordinated with the new names
> used for Mercurial commits, if a change will be made.)

+1 from me. It would be nice to not have to look up what tracker name
someone uses since I know everyone's committer name.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Misc/maintainers.rst

[R. David Murray]

On Thu, 17 Sep 2009 at 10:57, Brett Cannon wrote:

Looks great to me! Only thing missing that I can think of is sticking
Eric down as the guy who does str.format(). =)


OK, I've added that one to the last table ;)

--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Daniel Fetchinson]

> 188 (check that, 190) people have downloaded the 2.0 release in the
> last week (numbers publicly available from the code.google.com). I
> can't tell you how many (if any) have downloaded it via svn.

 Downloading and using are not the same thing.
>>>
>>> Correct, but there is a strong positive correlation between the two.
>>> If you have a better method for determining what you would consider an
>>> appropriate level of usage, I'm all ears.
>>
>> A good way of determining the level of usage would be pointing to open
>> source projects that are popular in the python community and which
>> incorporate your module.
>
> well, the 2.0 release is still new. codesearch.google.com shows some
> projects using the 1.x release; hopefully some of those 200
> downloaders will put up some publicly indexable python code at some
> point.

I think one first needs to wait until this happens, I meana large user
base is formed, before a meaningful discussion can be done on whether
to include it in the stdlib or not. The long and largely academic
thread here I think illustrates this point. Without a large user base
it's up to anybody's gut feelings what is 'right' and what 'feels
wrong'.

Cheers,
Daniel


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Misc/maintainers.rst

[R. David Murray]

On Thu, 17 Sep 2009 at 14:08, R. David Murray wrote:

On Thu, 17 Sep 2009 at 10:59, Brett Cannon wrote:

 On Thu, Sep 17, 2009 at 10:38, Georg Brandl  wrote:
>  ??Could we *please* have tracker names that match the committer names?
> 
>  (This doesn't even need to be done by the individual users, I would

>  volunteer to rename all committer accounts and notify them by email that
>  their name changed. ??This will also be coordinated with the new names
>  used for Mercurial commits, if a change will be made.)

 +1 from me. It would be nice to not have to look up what tracker name
 someone uses since I know everyone's committer name.


+1 from me as well.  And speaking of names, people should feel free to
email me maintainer info for the table as real names.  Whether or
not Georg's proposal goes through I'll make the table reflect the
correct tracker ids.


By the way, in case anyone isn't aware of it (Mark Dickinson and I weren't
initially), it is _really easy_ to change your tracker id if you want to
do it yourself.  Just go in 'your details' and change your login name.
It'll change everywhere in the tracker, since roundup tracks accounts
by an internal number, not the login name.

--David___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Misc/maintainers.rst

[Eric Smith]

R. David Murray wrote:

On Thu, 17 Sep 2009 at 10:57, Brett Cannon wrote:

Looks great to me! Only thing missing that I can think of is sticking
Eric down as the guy who does str.format(). =)


OK, I've added that one to the last table ;)


Awesome! I get to spend even more time on formatting strings!

I kid. I'm happy to be the string formatting maintainer.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Misc/maintainers.rst

[A.M. Kuchling]

On Thu, Sep 17, 2009 at 07:38:50PM +0200, Georg Brandl wrote:
> So the plan would be to consolidate these into another set of rst docs,
> having them in the repo, editable by every committer, as well as published
> somewhere on python.org (devdocs.python.org or somesuch).

+1.

Should we do something similar with the FAQs at
http://www.python.org/doc/faq/ ?

--amk
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Steven D'Aprano]

On Thu, 17 Sep 2009 10:41:37 am Andrew McNamara wrote:
> In the olden days, the mask was spelled out in octets (eg
> 255.255.255.0). But we've moved to a more compact and logical
> notation where the number of leading significant bits is specified
> (eg /24).

I hope you're not suggesting the older notation be unsupported? I would 
expect to be able to use a mask like 255.255.255.192 without having to 
count bits myself.


-- 
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Misc/maintainers.rst

[Paul Moore]

2009/9/17 R. David Murray :
> Feel free to respond with comments about the header text, but more
> importantly let me know what you know about who (especially if it is you)
> should be listed for each module, platform, and topic, and feel free to
> suggest additional topics.  My goal is to record the community knowledge.

A couple more:

runpy - Nick Coghlan
itertools, collections - Raymond Hettinger

(obviously, if I've misrepresented their interest, they should speak up!)

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Misc/maintainers.rst

[Fred Drake]

On Thu, Sep 17, 2009 at 10:38, Georg Brandl  wrote:
So the plan would be to consolidate these into another set of rst  
docs,
having them in the repo, editable by every committer, as well as  
published

somewhere on python.org (devdocs.python.org or somesuch).


On Sep 17, 2009, at 1:56 PM, Brett Cannon wrote:

dev.python.org would be nice to have, from which we can simply
redirect www.python.org/dev/ to dev.python.org. www.python.org/dev/
can then get cleaned up be made simpler to navigate and more obvious
for how people can get started.


Many years ago, we decided to add docs.python.org with the "current"  
version of the documentation, so people would be able to find the docs  
more easily.  Since then, we've had problems with keeping  
docs.python.org and www.python.org/doc/ in sync, and with different  
styles being applied to the sites.


One of the reasons www.python.org/doc/ was considered less  
discoverable was the about of only-sometimes-interesting information  
there; docs.python.org contains only "current" docs (for some vague  
notion of current and only, given that dev builds and both Python 2  
and Python 3 versions).  Some claimed that having "docs" at the front  
of the URL helped, though I don't recall why.


I don't know whether users consider the docs more discoverable than  
they used to; if anyone can provide information about that (now sure  
what indicator would make even sense), that might be informative.


The overload problem is one we *don't* have for developer  
documentation; the difficulty is in discovering what exists at all.


+1 on moving the developer docs to subversion

+0 on exposing them online

-0 on adding another domain name


  -Fred

--
Fred Drake   

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Jake McGuire]

On Thursday, September 17, 2009, Daniel Fetchinson
 wrote:
>> 188 (check that, 190) people have downloaded the 2.0 release in the
>> last week (numbers publicly available from the http://code.google.com). I
>> can't tell you how many (if any) have downloaded it via svn.
>
> Downloading and using are not the same thing.

 Correct, but there is a strong positive correlation between the two.
 If you have a better method for determining what you would consider an
 appropriate level of usage, I'm all ears.
>>>
>>> A good way of determining the level of usage would be pointing to open
>>> source projects that are popular in the python community and which
>>> incorporate your module.
>>
>> well, the 2.0 release is still new. http://codesearch.google.com shows some
>> projects using the 1.x release; hopefully some of those 200
>> downloaders will put up some publicly indexable python code at some
>> point.
>
> I think one first needs to wait until this happens, I meana large user
> base is formed, before a meaningful discussion can be done on whether
> to include it in the stdlib or not. The long and largely academic
> thread here I think illustrates this point. Without a large user base
> it's up to anybody's gut feelings what is 'right' and what 'feels
> wrong'.

+1000

-jake
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] maintainers.rst committed

[R. David Murray]

I decided to commit the draft of maintainers.rst in case people would
rather update it themselves.  I'm happy to continue collecting updates
and applying them as well.

--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Misc/maintainers.rst

[Jesse Noller]

On Thu, Sep 17, 2009 at 1:38 PM, Georg Brandl  wrote:
> R. David Murray schrieb:
>> I floated a proposal on stdlib-sig to create a file named
>> Misc/maintainers.rst.  The purpose of this file is to collect knowledge
>> about who knows which modules well enough to make decision about issues
>> in the tracker when the participants in the issue aren't sure, and to
>> write down the community knowledge about who has special interest and
>> expertise in specific topic areas.
>>
>> This proposal was met with approval and, after a couple of small
>> modifications of the proposal, no dissent; so I've created the skeleton
>> of the file.  I've filled in some of the blanks where I had personal
>> knowledge, was told info on IRC, from the two referenced PEPs, and
>> from PEP 11.
>>
>> Feel free to respond with comments about the header text, but more
>> importantly let me know what you know about who (especially if it is you)
>> should be listed for each module, platform, and topic, and feel free to
>> suggest additional topics.  My goal is to record the community knowledge.
>
> One thing I'd like to see in the list are real names of committers,
> not tracker names.  Of course, people looking for people to assign a bug
> to should not have to search for the tracker name, so I'd like to make
> another request (that Brett already made when we switched trackers):
>
>  Could we *please* have tracker names that match the committer names?
>
> (This doesn't even need to be done by the individual users, I would
> volunteer to rename all committer accounts and notify them by email that
> their name changed.  This will also be coordinated with the new names
> used for Mercurial commits, if a change will be made.)
>
>> Another topic of discussion that is orthogonal to filling in the table is
>> whether or not to publish it outside the repository.  Jesse would like to
>> see it included in the Python Documentation, and Georg has suggested the
>> possibility of creating a separate, sphinx-based, automatically-uploaded
>> document collection in the repository to contain this and related
>> information (Misc/devdocs?).
>
> For those who aren't on stdlib-sig, I'd like to elaborate a bit on that:
> There are quite a few resources for and about Python core development,
> but they aren't very accessible.  For example, there's Misc/developers.txt
> and the upcoming maintainers.txt.  Then there's the dev FAQ, but it's not
> maintained where developers usually look, but on the website.  Etc.
> So the plan would be to consolidate these into another set of rst docs,
> having them in the repo, editable by every committer, as well as published
> somewhere on python.org (devdocs.python.org or somesuch).
>
> cheers,
> Georg
>

+1 to getting them in The One True Format (ReST) and up and online,
and then porting all the dev docs into The One True Format.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Stephen J. Turnbull]

Andrew McNamara writes:

 > Conceptually, you sometimes need a bare address, and other times,
 > you need an address with an associated network (host interface
 > configs, router configs, etc). By AddressWithMask, I really mean
 > AddressWithEnoughInformationToDeriveNetworkWhenNeeded. Conveniently,
 > IPv4 and IPv6 addressing allows us to derive the network from the
 > host

That's precisely the claim I deny.  Yes, you can derive the network
*address* from a generic address and a mask.  You cannot derive the
*network* that way!  Eg, suppose in a routing application you have

class IPv4NetworkWithGateway(IPv4Network):

... oops.  You want *the* IPv4Network instance that has all the
gateway info, not just *any* IPv4Network instance that happens to have
the same network address and mask.  Address + mask is *not* sufficient
to derive the desired IPv4Network instance.

I grant that sometimes all you really care about is that the network
address and the mask match; constructing on the fly would be
sufficient.  However, many of the applications I can think of attach
additional attributes to IPv4Networks, and really do want "the real
thing" vs. a constructed imitation.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Misc/maintainers.rst

[Raymond Hettinger]

On Sep 17, 2009, at 10:59 AM, Brett Cannon wrote:


On Thu, Sep 17, 2009 at 10:38, Georg Brandl  wrote:

R. David Murray schrieb:

I floated a proposal on stdlib-sig to create a file named
Misc/maintainers.rst.  The purpose of this file is to collect  
knowledge
about who knows which modules well enough to make decision about  
issues
in the tracker when the participants in the issue aren't sure, and  
to
write down the community knowledge about who has special interest  
and

expertise in specific topic areas.

This proposal was met with approval and, after a couple of small
modifications of the proposal, no dissent; so I've created the  
skeleton

of the file.  I've filled in some of the blanks where I had personal
knowledge, was told info on IRC, from the two referenced PEPs, and
from PEP 11.

Feel free to respond with comments about the header text, but more
importantly let me know what you know about who (especially if it  
is you)
should be listed for each module, platform, and topic, and feel  
free to
suggest additional topics.  My goal is to record the community  
knowledge.


One thing I'd like to see in the list are real names of committers,
not tracker names.  Of course, people looking for people to assign  
a bug
to should not have to search for the tracker name, so I'd like to  
make

another request (that Brett already made when we switched trackers):

 Could we *please* have tracker names that match the committer names?

(This doesn't even need to be done by the individual users, I would
volunteer to rename all committer accounts and notify them by email  
that

their name changed.  This will also be coordinated with the new names
used for Mercurial commits, if a change will be made.)


+1 from me. It would be nice to not have to look up what tracker name
someone uses since I know everyone's committer name.



+1 from me also.  This has long been a source of irritation.


Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Misc/maintainers.rst

[Georg Brandl]

A.M. Kuchling schrieb:
> On Thu, Sep 17, 2009 at 07:38:50PM +0200, Georg Brandl wrote:
>> So the plan would be to consolidate these into another set of rst docs,
>> having them in the repo, editable by every committer, as well as published
>> somewhere on python.org (devdocs.python.org or somesuch).
> 
> +1.
> 
> Should we do something similar with the FAQs at
> http://www.python.org/doc/faq/ ?

They would then go into the main docs, I guess?

OK, so there seems to be some consensus on both the committer name and the
dev docs proposal.  I'll start working on both by the end of next week,
when I have more contiguous time to spare.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] conceptual clarity

[Nick Coghlan]

R. David Murray wrote:
> I would have IPv4Address itself be strict, and thus the new constructors
> would compute the network address and call the regular IPv4Address
> constructor.(*)

s/Address/Network/ in this paragraph :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Nick Coghlan]

Eric Smith wrote:
> Peter Moody wrote:
> 
>> indexing is plenty efficient, but the problem is that these names for
>> these attributes are common to the point of causing confusion if
>> they're omitted.
> 
> After thinking about it some more, I'm okay with names for [-1] and [0].
> I like .broadcast, and I can live with .network (although it's
> confusing, since in my view it should return an address, not a network).

And in fact *does* return an Address - the same address that my_net[0]
returns.

Cheers,
Nick.


-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Misc/maintainers.rst

[Nick Coghlan]

Paul Moore wrote:
> runpy - Nick Coghlan

And for the general interest table, the import system and the AST
compiler are the two main areas that I know better than most.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Greg Ewing]

Peter Moody wrote:


the address with all of the hosts bits masked to zero is most commonly
referred to as the network address.


Then call the attribute 'network_address', not just 'network'.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] how to debug httplib slowness

[Bill Janssen]

Oleg Broytmann  wrote:

> On Fri, Sep 04, 2009 at 04:02:39PM +0100, Chris Withers wrote:
> > So, httplib does this:
> >
> > GET / HTTP/1.1
> [skip]
> > While wget does this:
> >
> > GET / HTTP/1.0
> [skip]
> > - Apache responds with a chunked response only to httplib. Why is that?
> 
>Probably because wget uses HTTP/1.0?

Yep.  Not allowed to respond chunked to 1.0 requests.

Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] conceptual clarity

[R. David Murray]

On Fri, 18 Sep 2009 at 07:45, Nick Coghlan wrote:

R. David Murray wrote:

I would have IPv4Address itself be strict, and thus the new constructors
would compute the network address and call the regular IPv4Address
constructor.(*)


s/Address/Network/ in this paragraph :)


Ah, yes, sorry for the slip, and thanks for catching it.

--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Peter Moody]

On Thu, Sep 17, 2009 at 3:27 PM, Greg Ewing  wrote:
> Peter Moody wrote:
>
>> the address with all of the hosts bits masked to zero is most commonly
>> referred to as the network address.
>
> Then call the attribute 'network_address', not just 'network'.

from an earlier email:

Again, the same error-catching functionality can be obtained through
an option to the constructor. network and broadcast attributes can be
renamed to .\1_address to alleviate confusion as well.

> --
> Greg
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/python-dev%40hda3.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Misc/maintainers.rst

[A.M. Kuchling]

On Thu, Sep 17, 2009 at 11:32:25PM +0200, Georg Brandl wrote:
> > Should we do something similar with the FAQs at
> > http://www.python.org/doc/faq/ ?
> 
> They would then go into the main docs, I guess?

That would make sense.  However, we already have seven different FAQs
there, so I don't think they should all be added as peers of the
Tutorial, Library Reference, etc.  Maybe there should be a single
'FAQ' document, with the existing faqs as subsections.

Another option might be to put them on an entirely new site such as
faq.python.org, and then configure www.python.org/doc/faq/ to proxy
for it.

Should I look at implementing the python.org as an output style for
Sphinx?

--amk


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Misc/maintainers.rst

[R. David Murray]

On Thu, 17 Sep 2009 at 14:19, Fred Drake wrote:
One of the reasons www.python.org/doc/ was considered less discoverable was 
the about of only-sometimes-interesting information there; docs.python.org 
contains only "current" docs (for some vague notion of current and only, 
given that dev builds and both Python 2 and Python 3 versions).  Some claimed 
that having "docs" at the front of the URL helped, though I don't recall why.


It's anecdotal, but I can tell you that currently I often type
'http://dev.python.org', get a not found, smack my head, and retype
the url.  I don't have that problem with docs, obviously :)

--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] conceptual clarity

[Sebastian Rittau]

On Thu, Sep 17, 2009 at 02:04:11PM -0400, R. David Murray wrote:

> I mean, eg, IPv4Network.fromHostIP('192.168.1.1/24').

I'd actually suggest to use

  >>> net, host = parse_network_and_host("192.168.111.33/24")
  (IPv4Network('192.168.111.0/24'), IPv4Address('192.168.111.33'))
  >>> 

I think this helps the use case of the short network+gateway notation,
while keeping the concepts of network and host address cleanly separate.

> I would have IPv4Address itself be strict, and thus the new constructors
> would compute the network address and call the regular IPv4Address
> constructor.(*)

Then the regular IPv4Network constructor could be strict and can be used
for validation.

 - Sebastian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Andrew McNamara]

>On Thu, 17 Sep 2009 10:41:37 am Andrew McNamara wrote:
>> In the olden days, the mask was spelled out in octets (eg
>> 255.255.255.0). But we've moved to a more compact and logical
>> notation where the number of leading significant bits is specified
>> (eg /24).
>
>I hope you're not suggesting the older notation be unsupported? I would 
>expect to be able to use a mask like 255.255.255.192 without having to 
>count bits myself.

No, of course not - I was just explaining the relationship between the
two notations for people who may not have been aware.

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Andrew McNamara]

>> Conceptually, you sometimes need a bare address, and other times,
>> you need an address with an associated network (host interface
>> configs, router configs, etc). By AddressWithMask, I really mean 
>> AddressWithEnoughInformationToDeriveNetworkWhenNeeded. Conveniently,
>> IPv4 and IPv6 addressing allows us to derive the network from the
>> host address combined with the netmask - in other words, we don't
>> have to attach a real Network object to Address objects until the
>> user tries to access it, and then we derive it from the address and
>> mask.
>
>To clarify: when you say "derive the network" are you talking about the 
>network (which is a container) or the network address = host_address & 
>netmask (which is not a container)? I think you're referring to the 
>later.

I mean a Network object which is a container (which, by definition,
has a network address + mask).

>If there's need for address+netmask, does it need to be a separate 
>class? Perhaps Address objects could simply have a netmask property, 
>defaulting to None. If you need an "address with mask" object, you 
>create an Address and set the mask:
>
>addr = Address(...)
>addr.netmask = "255.255.255.0"

Greg Ewing suggested this yesterday - I'm neutral on whether it's done this
way or as a separate class. The implementation may be somewhat cleaner if
it's a separate class, however.

>> If you have a .network attribute on an address object, checking if an
>> address is in the same network as another address becomes:
>>
>> addr_a in addr_b.network
>>
>> As the module stands, you write that as:
>>
>> addr_a in addr_b
>>
>> I don't think the intent is as clear with the later.
>
>I would find the later completely unclear and disturbing -- how can one 
>address contain another address?

Yes - that's how it works now, and I can only see it resulting in
confusion and bugs for no advantage.

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Andrew McNamara]

>To a non-specialist, "the network address" is ambiguous. There are many 
>addresses in a network, and none of them are the entire network. It's 
>like saying, given a list [2, 4, 8, 12], what's "the list item"?

A "network address" is an IP address and mask, but I understand your
confusion - we're mixing terminology from disperate domains. In my
postings, I have tried to refer to Network (a containter) and Address
(an item).

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Misc/maintainers.rst

[Jesse Noller]

On Thu, Sep 17, 2009 at 7:26 PM, A.M. Kuchling  wrote:
> On Thu, Sep 17, 2009 at 11:32:25PM +0200, Georg Brandl wrote:
>> > Should we do something similar with the FAQs at
>> > http://www.python.org/doc/faq/ ?
>>
>> They would then go into the main docs, I guess?
>
> That would make sense.  However, we already have seven different FAQs
> there, so I don't think they should all be added as peers of the
> Tutorial, Library Reference, etc.  Maybe there should be a single
> 'FAQ' document, with the existing faqs as subsections.
>
> Another option might be to put them on an entirely new site such as
> faq.python.org, and then configure www.python.org/doc/faq/ to proxy
> for it.
>
> Should I look at implementing the python.org as an output style for
> Sphinx?
>
> --amk
>

I'm definitely pro dev.python.org or python.org/dev
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] conceptual clarity

[Andrew McNamara]

>off to patch the pep and implement some of the non controversial changes.

It might be a good idea to add some use-cases to the PEP.

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] conceptual clarity

[Andrew McNamara]

>Again, the same error-catching functionality can be obtained through
>an option to the constructor. network and broadcast attributes can be
>renamed to .\1_address to alleviate confusion as well.
>
>I mentioned before that IPy's insistence on receiving masked out
>networks was one of the main reasons I wrote ipaddr to begin with.
>Having ipaddr mimic this behavior would make it significantly less
>useful. Removing functionality in the name of avoiding confusion
>doesn't make sense when the same confusion can be alleviated w/o the
>loss.

The issue is bigger than error checking - I'm maintaining that a
distinction between an Address (singleton, item) and a Network (Container)
is useful and should be embraced. The current implementation has already
partially gone this route, but hasn't completed the transition, and
this does not give the structure to users that it could - there's an
obligation on modules in the standard library to provide leadership and
clarity without being dictatorial. They are essentially silent mentors.

So, while I am not suggesting we build a bondage and discipline machine,
I am suggesting that partitioning the functionality differently will
result in a better outcome all round.

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] conceptual clarity

[R. David Murray]

On Fri, 18 Sep 2009 at 02:24, Sebastian Rittau wrote:

On Thu, Sep 17, 2009 at 02:04:11PM -0400, R. David Murray wrote:


I mean, eg, IPv4Network.fromHostIP('192.168.1.1/24').


I'd actually suggest to use

 >>> net, host = parse_network_and_host("192.168.111.33/24")
 (IPv4Network('192.168.111.0/24'), IPv4Address('192.168.111.33'))
 >>>

I think this helps the use case of the short network+gateway notation,
while keeping the concepts of network and host address cleanly separate.

Then the regular IPv4Network constructor could be strict and can be used
for validation.


I'd be happy with this solution, which was also suggested earlier
by someone else (Antoine?).

--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[R. David Murray]

On Fri, 18 Sep 2009 at 11:04, Andrew McNamara wrote:

[attribution lost; apparently Steven D'Aprano given the CC]

To a non-specialist, "the network address" is ambiguous. There are many
addresses in a network, and none of them are the entire network. It's
like saying, given a list [2, 4, 8, 12], what's "the list item"?


A "network address" is an IP address and mask, but I understand your
confusion - we're mixing terminology from disperate domains. In my
postings, I have tried to refer to Network (a containter) and Address
(an item).


Apparently not, in many people's vocabulary.  The 'network address'
is used to designate the IP address whose bits corresponding to the one
bits in the mask have been set to zero (ie: the first IP address in the
network range).

It is interesting how this item seems to lead to the greatest amount of
confusion on everyone's part, and I'm guessing it is because the common
terminology and usage blurs the line between addresses and networks.
And that's what we are trying to make clear(er) through a well structured
API.

--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Steven D'Aprano]

On Fri, 18 Sep 2009 11:04:46 am Andrew McNamara wrote:
> >To a non-specialist, "the network address" is ambiguous. There are
> > many addresses in a network, and none of them are the entire
> > network. It's like saying, given a list [2, 4, 8, 12], what's "the
> > list item"?
>
> A "network address" is an IP address and mask, but I understand your
> confusion - we're mixing terminology from disperate domains. In my
> postings, I have tried to refer to Network (a containter) and Address
> (an item).


So to clarify, how many different things which need to be handled are 
there?

Items:
1 IP address  -- a 32 bit (IPv4) or 128 bit (IPv6) number
2 Netmask -- a bit mask of the form 111..100..0
3 Network address -- the lowest address in a network, and equal 
  to (defined by?) the bitwise-AND of any address in the network 
  with the network's netmask
4 Host address -- the part of the IP address that is not masked 
  by the netmask
5 Broadcast address -- the highest address in a IPv4 network

Containers:
6 Network -- a range of IP address

Have I missed anything or got anything wrong?



-- 
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] conceptual clarity

[Steven D'Aprano]

On Fri, 18 Sep 2009 11:41:32 am Andrew McNamara wrote:

> The issue is bigger than error checking - I'm maintaining that a
> distinction between an Address (singleton, item) and a Network
> (Container) is useful and should be embraced. The current
> implementation has already partially gone this route, but hasn't
> completed the transition, and this does not give the structure to
> users that it could - there's an obligation on modules in the
> standard library to provide leadership and clarity without being
> dictatorial. They are essentially silent mentors.
>
> So, while I am not suggesting we build a bondage and discipline
> machine, I am suggesting that partitioning the functionality
> differently will result in a better outcome all round.

As one of those non-expert users, can I give a big THANK YOU to Andrew 
for this.


-- 
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] conceptual clarity

[Peter Moody]

On Thu, Sep 17, 2009 at 6:17 PM, Andrew McNamara
 wrote:
>>off to patch the pep and implement some of the non controversial changes.
>
> It might be a good idea to add some use-cases to the PEP.

There are several use-cases in the PEP already.

The problem is, for every use-case where one can show that the
existing implementation is confusing, I can come up with a use-case
showing where the existing implementation makes more sense than
anything proposed.

Cheers,
/peter

> --
> Andrew McNamara, Senior Developer, Object Craft
> http://www.object-craft.com.au/
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] conceptual clarity

[Andrew McNamara]

>> It might be a good idea to add some use-cases to the PEP.
>
>There are several use-cases in the PEP already.

Maybe the use-cases deserve their own section in the PEP, or better yet,
be pulled up into the Motivation section.

>The problem is, for every use-case where one can show that the
>existing implementation is confusing, I can come up with a use-case
>showing where the existing implementation makes more sense than
>anything proposed.

Uh, I don't think that is the intention of use-cases - they're there
to inform the design, rather than to show how a specific implementation
can be used.

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Peter Moody]

On Thu, Sep 17, 2009 at 11:10 AM, Daniel Fetchinson
 wrote:
>> 188 (check that, 190) people have downloaded the 2.0 release in the
>> last week (numbers publicly available from the code.google.com). I
>> can't tell you how many (if any) have downloaded it via svn.
>
> Downloading and using are not the same thing.

 Correct, but there is a strong positive correlation between the two.
 If you have a better method for determining what you would consider an
 appropriate level of usage, I'm all ears.
>>>
>>> A good way of determining the level of usage would be pointing to open
>>> source projects that are popular in the python community and which
>>> incorporate your module.
>>
>> well, the 2.0 release is still new. codesearch.google.com shows some
>> projects using the 1.x release; hopefully some of those 200
>> downloaders will put up some publicly indexable python code at some
>> point.
>
> I think one first needs to wait until this happens, I meana large user
> base is formed, before a meaningful discussion can be done on whether
> to include it in the stdlib or not. The long and largely academic
> thread here I think illustrates this point. Without a large user base
> it's up to anybody's gut feelings what is 'right' and what 'feels
> wrong'.

I like the sound of this.

I'm going to continue to work on the PEP and the reference
implementation, but as Martin said earlier, there's no reason to
hurry.

any discussion on ipaddr and/or PEP 3144 can continue on
ipaddr-py-...@googlegroups.com in the meantime (past spam
unfortunately means that you have to subscribe in order to post,
apologies, but all are welcome).  Hopefully, the continued work will
help iron any remaining confusion of the API.

Cheers,
/peter

> Cheers,
> Daniel
>
>
> --
> Psss, psss, put it down! - http://www.cafepress.com/putitdown
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/python-dev%40hda3.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] conceptual clarity

[Steven D'Aprano]

On Fri, 18 Sep 2009 01:29:21 pm Peter Moody wrote:
> On Thu, Sep 17, 2009 at 6:17 PM, Andrew McNamara
>
>  wrote:
> >>off to patch the pep and implement some of the non controversial
> >> changes.
> >
> > It might be a good idea to add some use-cases to the PEP.
>
> There are several use-cases in the PEP already.
>
> The problem is, for every use-case where one can show that the
> existing implementation is confusing, I can come up with a use-case
> showing where the existing implementation makes more sense than
> anything proposed.

Please excuse my skepticism, but I find that hard to believe.

Given the current API, to test if an address is in the same network as 
another address, you write:

addr_a in addr_b

Can you please give a use-case where that makes more sense than the 
suggested alternative:

addr_a in addr_b.network



-- 
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Andrew McNamara]

>On Fri, 18 Sep 2009 11:04:46 am Andrew McNamara wrote:
>> >To a non-specialist, "the network address" is ambiguous. There are
>> > many addresses in a network, and none of them are the entire
>> > network. It's like saying, given a list [2, 4, 8, 12], what's "the
>> > list item"?
>>
>> A "network address" is an IP address and mask, but I understand your
>> confusion - we're mixing terminology from disperate domains. In my
>> postings, I have tried to refer to Network (a containter) and Address
>> (an item).
>
>So to clarify, how many different things which need to be handled are 
>there?
>
>Items:
>1 IP address  -- a 32 bit (IPv4) or 128 bit (IPv6) number

Yes.

>2 Netmask -- a bit mask of the form 111..100..0

I don't think there's much to be gained by exposing a Netmask object,
although other objects might have a .netmask property returning an
IPAddress instance. Where we expose a netmask, it should be as an
Address instance (or maybe a subclass with additional restrictions).

>3 Network address -- the lowest address in a network, and equal 
>  to (defined by?) the bitwise-AND of any address in the network 
>  with the network's netmask

This idea of a "network address" being simply an IP address is in error - 
a network address was always an address and a mask, however in the
days prior to CIDR, the mask was implicitly specified by the class of
the network.

>4 Host address -- the part of the IP address that is not masked 
>  by the netmask

Well, yes, but I don't think we need an entity representing that.

>5 Broadcast address -- the highest address in a IPv4 network

Yes, but again, we don't need an entity - as with the netmask, when
exposed, it should just be an Address instance (or subclass thereof).

>Containers:
>6 Network -- a range of IP address

Yes, although not an arbitrary or discontinuous range of address.

Really, I think we just need two entities (per protocol):

 Address (& maybe AddressWithMask)

   * If no mask is specified, this is just the IP address.
   * If a mask is specified, then it gains a .network property returning a
 Network instance. It probably should also have a .netmask property
 containing an Address instance.

 Network

   * Has an IP address with netmask 
   * for consistency's sake, masked address bits are not allowed
   * behaves like a read-only container wrt Addresses

So, you want to represent an interface on your host:

  >>> if_addr = IPv4Address('10.0.0.1/24')

from this, you could get:

  >>> if_addr.address
  IPv4Address('10.0.0.1')
  >>> if_addr.netmask
  IPv4Address('255.255.255.0')
  >>> if_addr.broadcast
  IPv4Address('10.0.0.255')
  >>> if_addr.network
  IPV4Network('10.0.0.0/24')

you might also have an address for the default gateway:

  >>> router_addr = IPv4Address('10.0.0.254/24')
  >>> router_addr in if_addr.network
  True

or:

  >>> router_addr = IPv4Address('10.0.0.254')
  >>> router_addr in if_addr.network
  True

Or maybe you've subneted your LAN:

  >>> IPV4Network('10.0.0.0/24') in IPv4Network('10.0.0.0/8')
  True
  >>> IPV4Network('10.0.1.0/24') in IPv4Network('10.0.0.0/8')
  True

but:

  >>> IPV4Network('10.0.0.0/8') in IPv4Network('10.0.0.0/24')
  False

This suggests the natural behaviour if the Address mask doesn't fit in the
network:

  >>> IPv4Address('10.0.0.254/8') in IPv4Network('10.0.0.0/24')
  False

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com