Re: [Python-Dev] PEP 3144 review.

[Martin v. Löwis]

>>> I don't see any valid reason for entering a network as
>>> "192.168.1.1/24" rather
>>> than the canonical "192.168.1.0/24". The former might indicate a
>>> typing error
>>> or
>>> a mental slip, so let's be helpful and signal it to the user.
>>
>> Or perhaps there can be an optional "strict=True" (or "strict=False")
>> argument
>> to the constructor / parsing function.
> 
> If so, I hope that we'd default to strict=True.

I don't see the point of enforcing strictness here. There are good use
cases: if you know your address is 82.94.164.162, how do you compute
what you should spell for 82.94.164.162/27? It's very easy to make a
mistake here, and doing the computation in your head is really not
something that should be necessary, given that a computer can get it
correct easily.

Regards,
Martin

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

[python-3000]

On Tue, Sep 15, 2009 at 09:35:13PM +0200, Sebastian Rittau wrote:
> On Tue, Sep 15, 2009 at 01:16:06PM -0400, Scott Dial wrote:
> 
> > I have to concur with the opinions above. I was very confused by the
> > following error:
> > 
> > >>> addr = ipaddr.IPAddress("10.1.2.3/255.255.240.0")
> > ...
> > ipaddr.IPAddressIPValidationError: '98.223.189.24/255.255.240.0' is not
> > a valid address (hint, it's probably a network)
> > 
> > Because, it *is* a address of a host on a network.
> 
> To me, 10.1.2.3/255.255.240.0 is not a host address, but specifies a
> network. I.e., 10.1.2.3/255.255.240.0 == 10.1.0.0/255.255.240.0 ==
> 10.1.35.200/20.
We shouldn't invent another bicycle here. It is a host address, that ALSO
specifies a network mask, that is not /32. Mask /32 just may be omitted when
written, but assumed, when stored by computer.

What you talk about is "address with mask". It is just IP address plus mask
information. IP address and mask just written together, one after another.
You MAY use mask to extract network part from an address, and have a "set" of
IP addresses, or range of IP addresses, or "network" as you say.
But you are not forced to do that with "MUST" statement, because you may also
use mask and IP address to compute widely used default value for a "broadcast"
address, or you may extract "host" part from the whole IP address.

There is no semantical difference between IPAddress for hosts and IPAddress for
networks, look at 'inet' type of PostgreSQL. Python shouldn't have separate
types for that - it is stupid, people will say 'python programmers are lamers'.
If you need only one IP address - you write AA.BB.CC.DD[/32] or /255.255.255.255
and the mask value may be omitted here. If you need to specify a larger range of
IP addresses, you specify another mask value, that is simple.


> 
> > >>> net = ipaddr.IPNetwork("10.1.2.3/255.255.240.0")
> > 
> > But then, I was dumbfounded as to how I could get the gateway IP from
> > this IPNetwork object.
> 
> Well, you can't. There is no way to determine a gateway, without querying
> the network topology. This is clearly outside the scope of this module.
> The only two known host addresses of a network are the network address
> (10.1.0.0 in the example you gave) and the broadcast address (10.1.15.255).
> 
> > It took me a while to figure out that you can
> > iterate over IPNetwork instances:
> > 
> > >>> gateway = net[1]
> > 
> > I was then confused, because:
> > 
> > >>> print(type(gateway))
> > 
> > 
> > Which sorta blew my mind.. I fully expected to receive an IPNetwork back
> > from that operation. It is unclear to me why the network information
> > gets chucked by that operation.
> 
> This makes perfect sense to me. An IP network consists of a list of IP
> addresses. Returning /32 networks seems kind of pointless to me.
Why? What differ IP Host address from IP Network address with mask /32?
Don't say "they have different python classes".
Well, I know, that an element is not a set containing only that element.
But that is about mathematical objects. What difference between /32 IP Network
and IP Host for Python?

Why IPNetwork can't be used where IPAddress is used?
When you only need IP address, you only use address part and ignore mask.
Why IPAddress can't be used where IPNetwork is accepted?
It is just IPNetwork with /32 mask.

It is counterintuitive for me, network administrator.

> 
> > I foresee having to work around that in
> > real applications by doing something obnoxious like:
> > 
> > >>> actual_gateway = ipaddr.IPNetwork("%s/%s" % (gateway, addr.netmask))
> 
> But a gateway is not an IP address plus hostmask. A gateway is just a single
> IP address. What is the use of adding a hostmask to the gateway IP address
> or some other IP address inside the network?
Just to specify an address together with a mask, for short. It is widespread.
People are used to it.
When a gateway address written with a mask, it fully specifies you IP stack
configuration, it specifies (when computed as usual):
   1. netmask
   2. your subnetwork address
   3. host address
   4. address of default route
   5. subnetwork broadcast address
   6. I don't know, maybe something else?
   7. Oh, yes, it shows you the range of IP addresses, available for your use,
  if it was your subnetwork.
So, what is better to write on network diagrams or other documentation, those
five data pieces or just one gateway-with-a-mask?


> 
>  - 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/python-3000%40udmvt.ru

-- 
Alexey S.
___
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: IP Address Manipulation Library for the Python Standard Library

[Alexey S]

On Wed, Aug 19, 2009 at 02:28:38PM -0400, Glyph Lefkowitz wrote:
> On Wed, Aug 19, 2009 at 2:20 PM, Eric Smith  wrote:
> 
> 
> > I think using .network and .broadcast are pretty well understood to be the
> > [0] and [-1] of the network address block. I don't think we want to start
> > creating new terms or access patterns here.
> >
> > +1 on leaving .network and .broadcast as-is (including returning a
> > IPvXAddress object).
> >
> 
> -1.  I think 'network.number' or 'network.zero' is a lot clearer than
> 'network.network'.  Maybe '.broadcast' would be okay, as long as it *can* be
> adjusted for those unusual, or maybe even only hypothetical, networks where
> it is not the [-1].
Real life example: network with a /31 mask.
There are only two hosts: 0 and 1
first host configures the other's host as broadcast address and vice versa.
NOTE - broadcasts are different here!
Everything works, no one ever need to address "network" address, broadcasting
works as expected. It works well between two our routers.
What is wrong here? It just works for two Linuxes. It emulates point-to-point.
Well, some weird soft will not let you to configure that (on Windows?heh)? So
just let Python be off the shame list.

Another real life examples include /32 networks on PPP. Just a point-to-point.
No need for broadcasts and networks, a host just have one IP address and
send all traffic via point-to-point link, no addressing is required there.
This is a working dialup configuration, it works for me, it works for you, 
probably.
It is not weird, it is common, it is used for PPPoE, for ADSL, for dialup.


-- 
Alexey S.
___
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] displayhook behavior in pdb

[Georg Brandl]

May I have a short vote on this issue:

   http://bugs.python.org/issue6903

In short, pdb (since 2.6) uses a separate displayhook in order to avoid
_ being reassigned (which screws up debugging apps that use _ as gettext).
In that displayhook, I did not add the suppression of printing None, as
it can be confusing to look at variables and get no output:

(Pdb) foo
1
(Pdb) bar
(Pdb)

(You could argue that this is what the "p" command is for though.)

Now in Python 3, where print is a function, if you call print in a loop
(e.g. to debug a list or dictionary, as it is advertised in the pdb docs
under the "alias" command), the output has the printed values interspersed
with "None"s.

Now, what is the lesser evil?

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] displayhook behavior in pdb

[Michael Foord]

Georg Brandl wrote:

May I have a short vote on this issue:

   http://bugs.python.org/issue6903

In short, pdb (since 2.6) uses a separate displayhook in order to avoid
_ being reassigned (which screws up debugging apps that use _ as gettext).
In that displayhook, I did not add the suppression of printing None, as
it can be confusing to look at variables and get no output:

(Pdb) foo
1
(Pdb) bar
(Pdb)

(You could argue that this is what the "p" command is for though.)

Now in Python 3, where print is a function, if you call print in a loop
(e.g. to debug a list or dictionary, as it is advertised in the pdb docs
under the "alias" command), the output has the printed values interspersed
with "None"s.

Now, what is the lesser evil?

  


IMO not showing the extraneous Nones is preferable.

Michael


cheers,
Georg

  



--
http://www.ironpythoninaction.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] displayhook behavior in pdb

[Paul Moore]

2009/9/16 Michael Foord :
> Georg Brandl wrote:
>>
>> May I have a short vote on this issue:
>>
>>   http://bugs.python.org/issue6903
>>
>> In short, pdb (since 2.6) uses a separate displayhook in order to avoid
>> _ being reassigned (which screws up debugging apps that use _ as gettext).
>> In that displayhook, I did not add the suppression of printing None, as
>> it can be confusing to look at variables and get no output:
>>
>> (Pdb) foo
>> 1
>> (Pdb) bar
>> (Pdb)
>>
>> (You could argue that this is what the "p" command is for though.)
>>
>> Now in Python 3, where print is a function, if you call print in a loop
>> (e.g. to debug a list or dictionary, as it is advertised in the pdb docs
>> under the "alias" command), the output has the printed values interspersed
>> with "None"s.
>>
>> Now, what is the lesser evil?
>>
>>
>
> IMO not showing the extraneous Nones is preferable.

I agree (although I don't use pdb, so my view shouldn't be given too
much weight...)
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] PEP 3144 review.

[Steven D'Aprano]

I've been skimming emails in this thread, since most of them go over my 
head and I have no current need for an ipaddress module. But one thing 
I noticed stands out and needs commenting on:

On Wed, 16 Sep 2009 11:05:26 am Peter Moody wrote:
> On Tue, Sep 15, 2009 at 6:02 PM, Eric Smith  
wrote:
> > I completely agree. I don't know of any situation where I'd want a
> > network of "192.168.1.1/24" to be anything other than an error.
>
> when you're entering the address of your nic.

Eric is talking about a network. Peter replies by talking about an 
address. Perhaps I'm naive, but surely addresses aren't networks? If 
Peter's use-case is to treat addresses and networks interchangeably, I 
can't imagine that could be a good thing. Is it? What do the relevant 
RFCs say?

As an outsider to this argument, and judging from the lack of agreement 
here, it seems to me that some (many? most?) developers who have need 
of ipaddress functions are a little unclear about the difference, or 
lack thereof, between addresses and networks. Is it our aim to pander 
to such confusion, and have a module which will Just Work for such 
users, even at the risk of sometimes accepting invalid input. Or is it 
to have a module which is strict and forces the user to Do The Right 
Thing, even at the cost of being less easy to use?

For what it's worth, it seems to me that it would be better to have a 
strict module in the standard lib, and leave the DWIM code to third 
parties.



-- 
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] Python Language Summit #2 in February

[Michael Foord]

A.M. Kuchling wrote:

PyCon 2010 will be February 19-21 2010 in Atlanta, Georgia (US).
Van Lindberg, PyCon chair, has approved having another Python Language
Summit on Thursday, February 18 2010.  The web page for it is


The Python Language Summit is an invitation-only event for developers
of Python implementations and the standard library, to discuss issues
of common concern to all implementors.

It will mostly be organized similarly to last year's event.  I'm going
to drop the initial open discussion, which wasn't very useful, and
we'll just have three 1.5-hour discussion sessions.  The fourth time
slot will be left open for chatting, development, or whatever the
attendees want to do.

We therefore need to decide what those three sessions should be about.
Please discuss on python-dev and hopefully we can arrive at some
consensus on topics of reasonably wide current interest.  (See
http://us.pycon.org/2009/about/summits/language/ for a reminder of
last year's topics.)
  


Given the long discussion on the stdlib-sig it seems like a discussion 
of the standard library would be useful. Potential topics include (some 
of which partially overlap each other):


* Clarifying the deprecation process of modules including whether we 
will *ever* remove deprecated modules
* Breaking the standard library into a separate development repository 
(which we decided to do at the last language summit but haven't yet - 
several developers are still keen to do this)
* Deprecating and removing more obsolete / unmaintained modules (I 
believe a new PEP on this will be coming soon)
* The goals of the standard library - some people want a 'dead' standard 
library (as in dead-stable) others want to see an actively improving 
standard library
* Bringing new best-of-breed modules into the standard library (and what 
to when they fully or partly duplicate existing functionality)


All the best,

Michael



Feel free to raise discussions on other lists such as jython-dev,
catalog-sig, or wherever, but please summarize the results here on
python-dev; I won't see discussions on other lists.

Like last time, invitations will be sent to the committers for Python,
Jython, IronPython, PyPy, Pynie, plus a few extra people and projects.
If you want to suggest another project or person who should be
invited, please send me a private e-mail.


Andrew M. Kuchling
a...@amk.ca
___
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/fuzzyman%40voidspace.org.uk
  



--
http://www.ironpythoninaction.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.

[Paul Moore]

2009/9/16 Steven D'Aprano :
> I've been skimming emails in this thread, since most of them go over my
> head and I have no current need for an ipaddress module.

Same here.

> As an outsider to this argument, and judging from the lack of agreement
> here, it seems to me that some (many? most?) developers who have need
> of ipaddress functions are a little unclear about the difference, or
> lack thereof, between addresses and networks. Is it our aim to pander
> to such confusion, and have a module which will Just Work for such
> users, even at the risk of sometimes accepting invalid input. Or is it
> to have a module which is strict and forces the user to Do The Right
> Thing, even at the cost of being less easy to use?
>
> For what it's worth, it seems to me that it would be better to have a
> strict module in the standard lib, and leave the DWIM code to third
> parties.

As a non-expert, I find the confusion between network, address,
address with mask, etc to be extremely unhelpful. I haven't looked to
confirm if it's a confusion that only exists in the discussion, or if
it's in the code as well. However, from my POV, I'd rather have a
module that made the concepts clear and unambiguous, effectively
educating me in the details of correct usage while I used it, rather
than one that catered to my muddled thinking and allowed me to remain
confused.

Of course, the discussion seems to imply that even the experts have a
confused view, so maybe I'm being too ambitious here :-)

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] PEP 3144 review.

[Nick Coghlan]

Steven D'Aprano wrote:
> I've been skimming emails in this thread, since most of them go over my 
> head and I have no current need for an ipaddress module. But one thing 
> I noticed stands out and needs commenting on:
> 
> On Wed, 16 Sep 2009 11:05:26 am Peter Moody wrote:
>> On Tue, Sep 15, 2009 at 6:02 PM, Eric Smith  
> wrote:
>>> I completely agree. I don't know of any situation where I'd want a
>>> network of "192.168.1.1/24" to be anything other than an error.
>> when you're entering the address of your nic.
> 
> Eric is talking about a network. Peter replies by talking about an 
> address.

Martin explained it better in another part of the thread:
> if you know your address is 82.94.164.162, how do you compute
> what you should spell for 82.94.164.162/27? 

Or, to put it another way, given an arbitrary host in a network (e.g.
your own machine or the default gateway) and the netmask for that
network, calculate the network address.

With a "lax" parser on IPNetwork this is a trivial task - just create
the network object and then retrieve the network address from it.

If, on the other hand, IPNetwork demands that you already know the
network address before allowing you to create an IPNetwork object, then
you're pretty much out of luck - if all you have to work with are the IP
strings then this is actually a tricky calculation.

If the default IPNetwork constructor was made more strict, then this
functionality would have to be made available another way (probably as
an alternate constructor like IPNetwork.from_host_address rather than as
a boolean 'strict' option)

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.

[Antoine Pitrou]

Stephen J. Turnbull  xemacs.org> writes:
> 
> Rather, don't you want to just give IPv4Address an attribute
> 'network'?  This could then be filled in by the indexing method on
> IPv4Network.

It doesn't make sense to me. An address, conceptually, doesn't have a "network".
If I say "213.5.4.68", it isn't part of a specific network /a priori/.

Not only doesn't it make sense to me, but it creates ambiguities.
Do two similar addresses, but with different "networks", compare and hash
equally? Both answers are unsatisfactory and will create nasty surprises for
users.

I don't see what's difficult in remembering the network object by yourself if
you need it. Python is not Java, it has lightweight syntax, useful datatypes and
notations (e.g. tuples). You don't need to have every use case taken care of by
a dedicated library API.

(to make an analogy: if I take an item from a list, it doesn't hold a reference
to the list just in case it might be practical to do so)

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] PEP 3144 review.

[Jake McGuire]

On Tue, Sep 15, 2009 at 11:36 AM, Peter Moody  wrote:

> On Tue, Sep 15, 2009 at 11:33 AM, Jake McGuire  wrote:
> > On Tue, Sep 15, 2009 at 10:36 AM, Peter Moody  wrote:
> >>
> >> On Tue, Sep 15, 2009 at 10:16 AM, Jake McGuire 
> wrote:
> >> > On Mon, Sep 14, 2009 at 9:54 AM, Guido van Rossum 
> >> > wrote:
> >> >>
> >> >> What's the opinion of the other interested party or parties? I don't
> >> >> want a repeat of the events last time, where we had to pull it at the
> >> >> last time because there hadn't been enough discussion.
> >> >
> >> > How many other people are using this library?  I think it's hard to
> give
> >> > really useful feedback on an API without using it for some non-trivial
> >> > task,
> >> > but maybe other people don't have this problem.
> >> > -jake
> >>
> >> 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.
>

Put something on the project page (or download page if possible) saying
"ipaddr is being considered for inclusion in the Python standard library.
 We want to make sure it meets your needs, but we need you to tell us.  If
you use ipaddr and like it, please let us know on ip-addr-dev."

I dunno, maybe it's too much work.  But no one else seems to have an opinion
strong enough to share, at least not at this point.

-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

Re: [Python-Dev] PEP 3144 review.

[Jake McGuire]

On Tue, Sep 15, 2009 at 11:44 AM, Jake McGuire  wrote:

> On Tue, Sep 15, 2009 at 11:36 AM, Peter Moody  wrote:
>
>> On Tue, Sep 15, 2009 at 11:33 AM, Jake McGuire 
>> wrote:
>> > On Tue, Sep 15, 2009 at 10:36 AM, Peter Moody  wrote:
>> >>
>> >> On Tue, Sep 15, 2009 at 10:16 AM, Jake McGuire 
>> wrote:
>> >> > On Mon, Sep 14, 2009 at 9:54 AM, Guido van Rossum 
>> >> > wrote:
>> >> >>
>> >> >> What's the opinion of the other interested party or parties? I don't
>> >> >> want a repeat of the events last time, where we had to pull it at
>> the
>> >> >> last time because there hadn't been enough discussion.
>> >> >
>> >> > How many other people are using this library?  I think it's hard to
>> give
>> >> > really useful feedback on an API without using it for some
>> non-trivial
>> >> > task,
>> >> > but maybe other people don't have this problem.
>> >> > -jake
>> >>
>> >> 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.
>>
>
> Put something on the project page (or download page if possible) saying
> "ipaddr is being considered for inclusion in the Python standard library.
>  We want to make sure it meets your needs, but we need you to tell us.  If
> you use ipaddr and like it, please let us know on ip-addr-dev."
>
> I dunno, maybe it's too much work.  But no one else seems to have an
> opinion strong enough to share, at least not at this point.
>

To clarify: there will always be some group of people happy to tell you that
whatever you made is crap and that it should have been done differently.
 There may be many more people out there who think that what you did is
great.  But those people probably don't read python-dev so their voices
don't get heard when it comes to deciding what to do with PEP 3144.

The easiest way to get their voices heard is to ask them to speak up, and
the one place you know they visited was the ipaddr page on code.google.com,
so you may as well ask them there.

-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

Re: [Python-Dev] Python Language Summit #2 in February

[Antoine Pitrou]

Michael Foord  voidspace.org.uk> writes:
> 
> Given the long discussion on the stdlib-sig it seems like a discussion 
> of the standard library would be useful. Potential topics include (some 
> of which partially overlap each other):
> 
[snip]

Let me suggest the following additional point:

* Clarifying maintainership. What is a maintainer, what can be expected from him
and what is *not* expected from him. Whether maintainers are, or are not,
"owners". What the relationship of other core developers to maintainers should
be, and should not be.

Of course, all this will perhaps have been discussed before the summit.

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] Python Language Summit #2 in February

[Michael Foord]

Antoine Pitrou wrote:

Michael Foord  voidspace.org.uk> writes:
  
Given the long discussion on the stdlib-sig it seems like a discussion 
of the standard library would be useful. Potential topics include (some 
of which partially overlap each other):




[snip]

Let me suggest the following additional point:

* Clarifying maintainership. What is a maintainer, what can be expected from him
and what is *not* expected from him. Whether maintainers are, or are not,
"owners". What the relationship of other core developers to maintainers should
be, and should not be.
  


Yup, good addition.


Of course, all this will perhaps have been discussed before the summit.

  


When we add discussing the relationship of the other implementations to 
the standard library I think there is plenty to discuss, even if some of 
the points are clearer or closer to being settled (or as settled as they 
can possibly get) by the time of the summit.


Michael


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/fuzzyman%40voidspace.org.uk
  



--
http://www.ironpythoninaction.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] Python Language Summit #2 in February

[Barry Warsaw]

On Sep 16, 2009, at 7:53 AM, Antoine Pitrou wrote:

Of course, all this will perhaps have been discussed before the  
summit.


Sure, but not resolved.  :)

I do think stdlib evolution should be high on the list of topics.

-B



PGP.sig
Description: This is a digitally signed message part
___
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.

[exarkun]

On 11:10 am, ncogh...@gmail.com wrote:

Steven D'Aprano wrote:
I've been skimming emails in this thread, since most of them go over 
my

head and I have no current need for an ipaddress module. But one thing
I noticed stands out and needs commenting on:

On Wed, 16 Sep 2009 11:05:26 am Peter Moody wrote:

On Tue, Sep 15, 2009 at 6:02 PM, Eric Smith 

wrote:

I completely agree. I don't know of any situation where I'd want a
network of "192.168.1.1/24" to be anything other than an error.

when you're entering the address of your nic.


Eric is talking about a network. Peter replies by talking about an
address.


Martin explained it better in another part of the thread:

if you know your address is 82.94.164.162, how do you compute
what you should spell for 82.94.164.162/27?


Or, to put it another way, given an arbitrary host in a network (e.g.
your own machine or the default gateway) and the netmask for that
network, calculate the network address.

With a "lax" parser on IPNetwork this is a trivial task - just create
the network object and then retrieve the network address from it.

If, on the other hand, IPNetwork demands that you already know the
network address before allowing you to create an IPNetwork object, then
you're pretty much out of luck - if all you have to work with are the 
IP

strings then this is actually a tricky calculation.

If the default IPNetwork constructor was made more strict, then this
functionality would have to be made available another way (probably as
an alternate constructor like IPNetwork.from_host_address rather than 
as

a boolean 'strict' option)


This seems to be the right solution to me, particularly the use of an 
alternate constructor rather than an ambiguously named flag.


Jean-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] Python 2.6.3

[Barry Warsaw]

On Sep 15, 2009, at 9:53 AM, Ronald Oussoren wrote:


The IDLE issue is IMHO a release blocker, as is issue 6851.


So that leaves 4 release blockers for 2.6.3.  Three of these are  
assigned to Ronald.  Ronald are you sure you will have time to fix  
these by then?  The one I'm still uncertain on is the IDLE hang.  If  
this only affects OS X 10.6 and there is no progress on it by the time  
2.6.3 is otherwise ready, I'm willing to knock this down in severity.


Martin, you have the other showstopper bug for 2.6.3.  Do you think  
you will be able to fix that one in time?


-Barry



PGP.sig
Description: This is a digitally signed message part
___
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]

exar...@twistedmatrix.com wrote:
> On 11:10 am, ncogh...@gmail.com wrote:
>> If the default IPNetwork constructor was made more strict, then this
>> functionality would have to be made available another way (probably as
>> an alternate constructor like IPNetwork.from_host_address rather than as
>> a boolean 'strict' option)
> 
> This seems to be the right solution to me, particularly the use of an
> alternate constructor rather than an ambiguously named flag.

Particular since someone pointed out that the "Network" object was
remembering which IP address happened to be passed to the constructor
(which is "Address with Mask" behaviour, as has been mentioned).

That said, I've been trying to refrain from commenting on specifics of
the API, as I haven't tried to use it for anything.

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] Python Language Summit #2 in February

[Eric Smith]

A.M. Kuchling wrote:

We therefore need to decide what those three sessions should be about.
Please discuss on python-dev and hopefully we can arrive at some
consensus on topics of reasonably wide current interest.  (See
http://us.pycon.org/2009/about/summits/language/ for a reminder of
last year's topics.)


I'd like to have a discussion on the future of 2.x, at least as far as 
core development goes. Supporting both 2.x and 3.x cuts my contributions 
in half, at best. For example, in order to keep 2.x and 3.x nearly in 
sync, Mark and I back-ported the API's for short-float-repr to 2.x, even 
though 2.x itself didn't see any benefit from that work (well, at least 
not much of a benefit).


My initial thought is let's stop after 2.7 (if we even release 2.7). But 
it all depends on uptake of 3.x, and what stopping core development 
means to the community.


Can we discuss this at the language summit?

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] displayhook behavior in pdb

[Guido van Rossum]

On Wed, Sep 16, 2009 at 3:48 AM, Paul Moore  wrote:

> 2009/9/16 Michael Foord :
> > Georg Brandl wrote:
> >>
> >> May I have a short vote on this issue:
> >>
> >>   http://bugs.python.org/issue6903
> >>
> >> In short, pdb (since 2.6) uses a separate displayhook in order to avoid
> >> _ being reassigned (which screws up debugging apps that use _ as
> gettext).
> >> In that displayhook, I did not add the suppression of printing None, as
> >> it can be confusing to look at variables and get no output:
> >>
> >> (Pdb) foo
> >> 1
> >> (Pdb) bar
> >> (Pdb)
> >>
> >> (You could argue that this is what the "p" command is for though.)
> >>
> >> Now in Python 3, where print is a function, if you call print in a loop
> >> (e.g. to debug a list or dictionary, as it is advertised in the pdb docs
> >> under the "alias" command), the output has the printed values
> interspersed
> >> with "None"s.
> >>
> >> Now, what is the lesser evil?
> >>
> >>
> >
> > IMO not showing the extraneous Nones is preferable.
>
> I agree (although I don't use pdb, so my view shouldn't be given too
> much weight...)
>

I *do* use pdb a lot, and I agree that the new behavior is weird.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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 12:50, exar...@twistedmatrix.com wrote:

On 11:10 am, ncogh...@gmail.com wrote:

Or, to put it another way, given an arbitrary host in a network (e.g.
your own machine or the default gateway) and the netmask for that
network, calculate the network address.

With a "lax" parser on IPNetwork this is a trivial task - just create
the network object and then retrieve the network address from it.

If, on the other hand, IPNetwork demands that you already know the
network address before allowing you to create an IPNetwork object, then
you're pretty much out of luck - if all you have to work with are the IP
strings then this is actually a tricky calculation.

If the default IPNetwork constructor was made more strict, then this
functionality would have to be made available another way (probably as
an alternate constructor like IPNetwork.from_host_address rather than as
a boolean 'strict' option)


This seems to be the right solution to me, particularly the use of an 
alternate constructor rather than an ambiguously named flag.


+1

--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 12:04, Paul Moore wrote:

Of course, the discussion seems to imply that even the experts have a
confused view, so maybe I'm being too ambitious here :-)


Part of the problem, as we discovered in the last go-round on
ipaddr, is that there are two types of experts:  those who primarily
deal with networks and for whom host addresses are just a special
case, and those who primarily deal with host addresses, for whom
networks are relevant only in certain contexts.

I hope we are converging on something that works for both.  That should
certainly be a goal, since the fact that it didn't was what scuttled
inclusion last time.

--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] displayhook behavior in pdb

[Georg Brandl]

Guido van Rossum schrieb:

> >> Now, what is the lesser evil?
> >>
> >>
> >
> > IMO not showing the extraneous Nones is preferable.
> 
> I agree (although I don't use pdb, so my view shouldn't be given too
> much weight...)
> 
> 
> I *do* use pdb a lot, and I agree that the new behavior is weird. 

Okay, I've fixed it in trunk and will backport soon.

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] Python 2.6.3

[Brett Cannon]

On Wed, Sep 16, 2009 at 05:52, Barry Warsaw  wrote:
> On Sep 15, 2009, at 9:53 AM, Ronald Oussoren wrote:
>
>> The IDLE issue is IMHO a release blocker, as is issue 6851.
>
> So that leaves 4 release blockers for 2.6.3.  Three of these are assigned to
> Ronald.  Ronald are you sure you will have time to fix these by then?  The
> one I'm still uncertain on is the IDLE hang.  If this only affects OS X 10.6
> and there is no progress on it by the time 2.6.3 is otherwise ready, I'm
> willing to knock this down in severity.
>
> Martin, you have the other showstopper bug for 2.6.3.  Do you think you will
> be able to fix that one in time?

That issue doesn't require Martin specifically. I just needed to know
if changing the BaseException struct would be bad (Georg answered w/
"yes"). It will probably fall on to me (or Georg if his proposed
solution pans out) to get this fixed.

-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] Python 2.6.3

[Ronald Oussoren]

On 16 Sep, 2009, at 14:52, Barry Warsaw wrote:


On Sep 15, 2009, at 9:53 AM, Ronald Oussoren wrote:


The IDLE issue is IMHO a release blocker, as is issue 6851.


So that leaves 4 release blockers for 2.6.3.  Three of these are  
assigned to Ronald.  Ronald are you sure you will have time to fix  
these by then?  The one I'm still uncertain on is the IDLE hang.  If  
this only affects OS X 10.6 and there is no progress on it by the  
time 2.6.3 is otherwise ready, I'm willing to knock this down in  
severity.


I don't know for sure if I'll be able to fix these issues, I'll  
basicly just have time to work on this during the weekend.


* IDLE hang on OSX 10.6:   I don't really know where to start looking,  
this may have something to do with Tk-Cocoa (which is used on 10.6 and  
not on earlier releases). There is a patch for Tk-Cocoa support on the  
tracker, but I haven't had time yet to fully test that.


* Compile error for ctypes on 10.6: Should be easy to fix. Apple has  
released the sources of the copy of libffi included with 10.6.1, I'll  
use that to work on a patch.


* Crash with urllib and threads on OSX 10.6: This probably requires  
rewriting some code using ctypes in C. The crash seems to occur when  
CoreFoundation tries to initialise itself after being loaded on a  
secondairy thread by ctypes. To make matters worse the ctypes type  
annotations in urllib are not correct for 64-bit code (but the crash  
happens in 32-bit mode as well)


Ronald

smime.p7s
Description: S/MIME cryptographic signature
___
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] pthreads, fork, import, and execvp

[Thomas Wouters]

On Wed, Sep 9, 2009 at 23:56, Nick Coghlan  wrote:

> Thomas Wouters wrote:
> > Your idea of making this an API called a 'fork lock' or something
> > sounds good (though I think it needs a better name.  PyBeforeFork &
> > PyAfterFork?).  The subprocess module, for example, disables garbage
> > collection before forking and restores it afterwards to avoid
> > http://bugs.python.org/issue1336.  That type of thing could also be
> > done in such a function.
> >
> >
> > Unfortunately it's rather hard to make those functions work correctly
> > with the current API -- we can't provide functions you can just use as
> > arguments to pthread_atfork because the global interpreter lock is not
> > re-entrant and we have no way of testing whether the current thread
> > holds the GIL.
>
> I thought "make sure I have the GIL, either by already having it or
> waiting for it if I don't yet have it" was the entire point of the
> PyGILState_Ensure() API? [1]
>

Hm, yeah. For some reason I was certain it was inappropriate, back when I
was trying to create a pthread_atfork-friendly set of functions. At the time
I was also hip-deep in the awfulness of Python/thread*.c and its unsafe
punning and unwarranted assumptions, so I may have overreacted. I added this
as a feature-request issue ( http://bugs.python.org/issue6923 ) and will
look at it some more.

In the mean time, I fixed the biggest source of issues by checking in the
change to make at least calls to fork() made by Python be safe, also
backported to 2.6.

-- 
Thomas Wouters 

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
___
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?

Besides what has already been said in the thread, I have a bunch of 
comments:

It should be noted
that __len__ doesn't work as expected since python internals has this
limited to a 32 bit integer and it would need to be at least 128 bits 
to
work with IPV6.

You should clarify what it means: does the result get truncated, or is an 
error thrown when it can't fit inside an int?

1. all IP addresses and networks, both IPv4 and IPv6. (IPAddrBase)

2. all IP addresses of both versions. (BaseIP)

3. all IP networks of both version. (BaseNet)

4. all IPv4 objects, both addresses and networks. (BaseV4)

5. all IPv6 objects, both addresses and networks. (BaseV6)

Should those base classes be exposed publically? It may make life more 
difficult if an alternate implementation (say, a C accelerator) wants to 
adopt a different code sharing strategy.

If they are not to be part of the public API, their names should be 
prefixed with an underscore.


___
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 Wed, Sep 16, 2009 at 1:35 PM, 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?
>
> Besides what has already been said in the thread, I have a bunch of
> comments:
>
>    It should be noted
>    that __len__ doesn't work as expected since python internals has this
>    limited to a 32 bit integer and it would need to be at least 128 bits
> to
>    work with IPV6.
>
> You should clarify what it means: does the result get truncated, or is an
> error thrown when it can't fit inside an int?

I'll clarify this, but it looks like this:

>>> len(xrange(0xF))
Traceback (most recent call last):
  File "", line 1, in 
OverflowError: long int too large to convert to int
>>>

basically, __len__(self): can only return an int. At least that's what
I recall from the discussion.

>    1. all IP addresses and networks, both IPv4 and IPv6. (IPAddrBase)
>
>    2. all IP addresses of both versions. (BaseIP)
>
>    3. all IP networks of both version. (BaseNet)
>
>    4. all IPv4 objects, both addresses and networks. (BaseV4)
>
>    5. all IPv6 objects, both addresses and networks. (BaseV6)
>
> Should those base classes be exposed publically? It may make life more
> difficult if an alternate implementation (say, a C accelerator) wants to
> adopt a different code sharing strategy.
>
> If they are not to be part of the public API, their names should be
> prefixed with an underscore.

makes sense. I see no need for them to be public. private they go.

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

[Terry Reedy]

Peter Moody wrote:

On Wed, Sep 16, 2009 at 1:35 PM, 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?

Besides what has already been said in the thread, I have a bunch of
comments:

   It should be noted
   that __len__ doesn't work as expected since python internals has this
   limited to a 32 bit integer and it would need to be at least 128 bits
to
   work with IPV6.

You should clarify what it means: does the result get truncated, or is an
error thrown when it can't fit inside an int?


I'll clarify this, but it looks like this:


len(xrange(0xF))

Traceback (most recent call last):
  File "", line 1, in 
OverflowError: long int too large to convert to int

basically, __len__(self): can only return an int. At least that's what
I recall from the discussion.


FWIW, the limitation remains in Py3, with a modified error msg.
>>> len(range(0xF))
Traceback (most recent call last):
  File "", line 1, in 
len(range(0xF))
OverflowError: Python int too large to convert to C ssize_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.

[Greg Ewing]

Nick Coghlan wrote:


Or, to put it another way, given an arbitrary host in a network (e.g.
your own machine or the default gateway) and the netmask for that
network, calculate the network address.


Some people have claimed that the gateway address of a
network isn't necessarily the zero address in that network.
If that's true, then you *can't* calculate the network
address from a host address and a netmask -- there isn't
enough information. Furthermore, an IPNetwork object
needs to be able to represent a network address whose
address part contains bits that aren't in the mask.

--
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] PEP 3144 review.

[Eric Smith]

Eric.

"Greg Ewing"  wrote:

>Nick Coghlan wrote:
>
>> Or, to put it another way, given an arbitrary host in a network (e.g.
>> your own machine or the default gateway) and the netmask for that
>> network, calculate the network address.
>
>Some people have claimed that the gateway address of a
>network isn't necessarily the zero address in that network.
>If that's true, then you *can't* calculate the network
>address from a host address and a netmask -- there isn't
>enough information. Furthermore, an IPNetwork object
>needs to be able to represent a network address whose
>address part contains bits that aren't in the mask.

I don't see why that would be considered a network address, then. It sounds to 
me like that's a host address plus a netmask.___
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.

[Cameron Simpson]

On 15Sep2009 13:16, Scott Dial  wrote:
| It just happened that I needed a tool today to calculate the gateway IP
| for an interface, and I took it as an opportunity to try out this ipaddr
| module. I'll attempt to relate my experience below...
| 
| I have to concur with the opinions above. I was very confused by the
| following error:
| 
| >>> addr = ipaddr.IPAddress("10.1.2.3/255.255.240.0")
| ...
| ipaddr.IPAddressIPValidationError: '98.223.189.24/255.255.240.0' is not
| a valid address (hint, it's probably a network)

It sure looks like a network to me, too.

| Because, it *is* a address of a host on a network. I gave in and said:

No, it is an IP address plus a network mask, and that notation is
generally used to describe a network (base IP of network plus the mask
to indicate its range).

| >>> net = ipaddr.IPNetwork("10.1.2.3/255.255.240.0")
| 
| But then, I was dumbfounded as to how I could get the gateway IP from
| this IPNetwork object. It took me a while to figure out that you can
| iterate over IPNetwork instances:
| 
| >>> gateway = net[1]

Shrug. It is a common convention for a network's _default_ gateway to be the
network's base address + 1. But certainly not necessary. If that convention
is also your convention, then good.

| I was then confused, because:
| 
| >>> print(type(gateway))
| 
| 
| Which sorta blew my mind.. I fully expected to receive an IPNetwork back
| from that operation.

I have no idea why you would expect that. A gateway is just the IP
_address_ of a host that will route packets to other networks. It is
inherently an address, and not a network.

Remember that a network (well, a host on a network) may have multiple
gateways; usually a single "default" gateway, and potentially others for
special routes to particular other networks. There's no need to have
just one gateway address.

Perhaps you are thinking of routing table entries (such as recited by
"netstat -r" on a UNIX box). They normally consist of a network
specification (base-addr/network-mask) and a gateway _address_.

| It is unclear to me why the network information
| gets chucked by that operation. I foresee having to work around that in
| real applications by doing something obnoxious like:
| 
| >>> actual_gateway = ipaddr.IPNetwork("%s/%s" % (gateway, addr.netmask))
| 
| But since I only actually needed the IP address for the gateway, it
| fulfilled my needs.

And that is a clue. You only need the gateway IP address in your needs
because a gateway _is_ an IP address.

It is quite possible you are thinking the word "gateway", but actually
thinking about a "route".

| In the end, I found the names IPNetwork/IPAddress and their
| instantiations confusing.

I really believe that you are confused in this instance, not the module.

| ISTM that IPNetwork is overloaded and plays
| two roles of being an IPNetwork and being an IPAddressWithNetwork. And
| finally, it's unclear to me why iterating over a IPNetwork would not
| produce a sequence of IPNetwork(/IPAddressWithNetwork) objects.
| 
| ISTM that if I started with an IPNetwork object, the API should always
| return IPNetwork objects.

Not for methods that produce addresses!

| If I want just an IPAddress object, then I can
| always fetch the "ip" attribute to get that. Perhaps there is some
| compelling conceptual argument as to why this is not correct, but it
| seems like the API destroys information needlessly.

I really think you have the wrong mental image of what these terms mean.

Nothing in your examples seems surprising, confusing or wrong to me.

Cheers,
-- 
Cameron Simpson  DoD#743
http://www.cskk.ezoshosting.com/cs/
___
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 Thu, 17 Sep 2009 at 09:59, Greg Ewing wrote:

Nick Coghlan wrote:


 Or, to put it another way, given an arbitrary host in a network (e.g.
 your own machine or the default gateway) and the netmask for that
 network, calculate the network address.


Some people have claimed that the gateway address of a
network isn't necessarily the zero address in that network.
If that's true, then you *can't* calculate the network
address from a host address and a netmask -- there isn't
enough information. Furthermore, an IPNetwork object
needs to be able to represent a network address whose
address part contains bits that aren't in the mask.


A 'gateway' is an IP (ie: host) in a network to which you route packets
for delivery elsewhere.  That's a very different thing from the 'network
number' (or 'network address' or 'network zero' or 'network identifier'
or whatever you want to call it).  Any IP in a network can be a gateway
IP, and in many networks there is more than one gateway (and thus the
need for routing tables...)

A network is conventionally represented by an IP address in which the
bits corresponding to the one bits in the netmask are set to zero, plus
the netmask.  That IP with the bits set to zero is the 'network number'
or zero for the network, and it is almost never used as the address for a
host in the network.  Thus it would be very surprising to find it being
used as a gateway address.

There is no reason why an IPNetwork object should record any bits from
the portion of the IP address that are covered by the mask bits.  To do
otherwise is to conflate Networks with individual IPs, which is what
got IPAddr rejected the first time around.  (And for those of you who
don't know/remember, I was initially an IPAddr booster in its original
incarnation, because I come from a network engineering background.)

This existence of this kind of confusion is why I voted +1 for the
IPNetwork constructor rejecting input with non-zero bits covered by the
mask, and a separate constructor method to return the network object
representing the network that a given IP address is in when a given
mask is applied to it.  (Which is easily computed by applying the mask
to the 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

Re: [Python-Dev] PEP 3144 review.

[Daniel Stutzbach]

On Wed, Sep 16, 2009 at 4:59 PM, Greg Ewing wrote:

> Some people have claimed that the gateway address of a
> network isn't necessarily the zero address in that network.
>

I'll go further: I don't think it's even legal for the gateway address to be
the zero address of the network (and I used to program the embedded software
in routers for a living :) ).


> If that's true, then you *can't* calculate the network
> address from a host address and a netmask -- there isn't
> enough information.


In a router or operating system kernel, an IPv4 address or netmask is stored
in a 32-bit unsigned integer.  Host addresses, network addresses, and
netmasks satisfy the following properties, where & is the bitwise-AND
operation:

network address & netmask == network address
host address & netmask == network address of that host

A gateway is just a host that will forward packets.  A gateway address has
the same properties as a host address and isn't the same as the zero
address.

Every host has a routing table that contains a list of (network address,
gateway, netmask) tuples.  To see the list, just run "/sbin/route -n" on any
Linux system (and most other Unixes; root is not typically required) or
"route print" on a Windows system.

To route a packet, the operating system essentially performs the following
algorithm:

def find_gateway_for_destination(destination_address):
for (network_address, gateway, netmask) in
list_of_routing_table_entires:
if network_address == destination_address & netmask:
return gateway
raise DestinationUnreachable

Furthermore, an IPNetwork object
> needs to be able to represent a network address whose
> address part contains bits that aren't in the mask.
>

Network addresses never contain bits that aren't in the mask (due to the
rule: "network address & netmask == network address").

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

[Greg Ewing]

R. David Murray wrote:


A network is conventionally represented by an IP address in which the
bits corresponding to the one bits in the netmask are set to zero, plus
the netmask.


Okay, that's clarified things for me, thanks.

In that case, we shouldn't be talking about a "network address"
at all, but just a "network", and it makes sense to have

1) A class called IPNetwork that contains an IP number
and a mask, with the IP number constrained not to have
any ones where the mask has zeroes, and

2) A class called IPAddress which only contains an
IP number.

It seems that some people would also like to have

3) A class called IPAddressWithMask that contains an
IP number and a mask, with no constraints,

but I'm not enough of an expert to know whether such
a thing would be used often enough to be worth having
a special type for it, as opposed to using an
(IPNetwork, IPAddress) pair, or attaching a 'network'
attribute to an IPAddress, or some other solution
when the need arises.

--
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] PEP 3144 review.

[Andrew McNamara]

>R. David Murray wrote:
>
>> A network is conventionally represented by an IP address in which the
>> bits corresponding to the one bits in the netmask are set to zero, plus
>> the netmask.
>
>Okay, that's clarified things for me, thanks.

Put another way, an "Address" describes a single end-point and a "Network"
describes a set of (contiguous) Addresses.

Where things have become confused is that, for practical reasons, it is
convenient to have a representation for an Address and it's containing
Network (the later can be derived from the Address and a mask). We tried
to make the current Network entity do double-duty, but it is just leading
to confusion.

This is why I proprose there be three entities:

 * an Address entity (same as the current one)
 * a Network entity (like now, but requires masked bits to be zero)
 * an AddressWithMask entity (existing Network, but no container behaviour)

There is a school of thought that says we only need a single class
that behaves like the current Network entity - end-points are simply
represented by an all-ones mask. This is, I think, where we started. But
this scheme was rejected.

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

>> Some people have claimed that the gateway address of a
>> network isn't necessarily the zero address in that network.

It almost never is - conventions vary, but it is often the network address
plus one, or the broadcast address minus one.

>I'll go further: I don't think it's even legal for the gateway address to be
>the zero address of the network (and I used to program the embedded software
>in routers for a living :) ).

I don't think the RFCs forbid the zero address being used, and
"enlightened" network stacks allow it (typically routers) to achieve
better utilisation of the limited IPv4 address space (for a /24 or larger,
wasting one address out of 255 isn't too bad, but it is now typical to
use much smaller nets - right down to /30).

>> If that's true, then you *can't* calculate the network
>> address from a host address and a netmask -- there isn't
>> enough information.

You can always calculate the network address from the IP address plus
mask - the network address is simply the bits that are not masked. 

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

-- 
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 Wed, Sep 16, 2009 at 5:30 PM, Andrew McNamara
 wrote:
>>R. David Murray wrote:
>>
>>> A network is conventionally represented by an IP address in which the
>>> bits corresponding to the one bits in the netmask are set to zero, plus
>>> the netmask.
>>
>>Okay, that's clarified things for me, thanks.
>
> Put another way, an "Address" describes a single end-point and a "Network"
> describes a set of (contiguous) Addresses.
>
> Where things have become confused is that, for practical reasons, it is
> convenient to have a representation for an Address and it's containing
> Network (the later can be derived from the Address and a mask). We tried
> to make the current Network entity do double-duty, but it is just leading
> to confusion.
>
> This is why I proprose there be three entities:
>
>  * an Address entity (same as the current one)
>  * a Network entity (like now, but requires masked bits to be zero)
>  * an AddressWithMask entity (existing Network, but no container behaviour)

This proposal actually leads to 6 entities (3 for IPv4 and 3 for IPv6).

It's still unclear to me what is gained by pulling AddressWithMask
functionality out of the current network classes. It's easy enough for
the concerned developer who to check if the entered network address
does actually have all of its host bits set to zero. It is not my
experience that this behavior is desired so often that having the
network classes behave as they do now leads to a great deal of
confusion.

> There is a school of thought that says we only need a single class
> that behaves like the current Network entity - end-points are simply
> represented by an all-ones mask. This is, I think, where we started. But
> this scheme was rejected.

I don't think anything has actually been rejected.

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

[Andrew McNamara]

>This proposal actually leads to 6 entities (3 for IPv4 and 3 for IPv6).

Yes, I know - I was just trying to keep to the point.

>It's still unclear to me what is gained by pulling AddressWithMask
>functionality out of the current network classes. It's easy enough for
>the concerned developer who to check if the entered network address
>does actually have all of its host bits set to zero. It is not my
>experience that this behavior is desired so often that having the
>network classes behave as they do now leads to a great deal of
>confusion.

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.

A particular case in point - if you want to represent a single IP address
with netmask (say an interface), you use a Network class, not an Address
class. And the .network attribute returns a Address class!

The reason I suggest having the Network class assert that masked bits be
zero is two-fold:

 * it ensures the correct class is being used for the job
 * it ensures application-user errors are detected as early as possible

I also suggest the AddressWithMask classes not have any network/container
behaviours for a similar reason. If the developer needs these, the
.network attribute is only a lookup away.

-- 
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 Wed, Sep 16, 2009 at 6:32 PM, Andrew McNamara
 wrote:
>>This proposal actually leads to 6 entities (3 for IPv4 and 3 for IPv6).
>
> Yes, I know - I was just trying to keep to the point.
>
>>It's still unclear to me what is gained by pulling AddressWithMask
>>functionality out of the current network classes. It's easy enough for
>>the concerned developer who to check if the entered network address
>>does actually have all of its host bits set to zero. It is not my
>>experience that this behavior is desired so often that having the
>>network classes behave as they do now leads to a great deal of
>>confusion.
>
> 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.

> A particular case in point - if you want to represent a single IP address
> with netmask (say an interface), you use a Network class, not an Address
> class. And the .network attribute returns a Address class!

Right, and I don't see where the confusion lies.  You have an address
+ netmask. ergo, you have a Network object.  The single address that
defines the base address (most commonly referred to as the network
address) is an Address object. there is no netmask associated with
that single address, ergo, it's an Address object.

> The reason I suggest having the Network class assert that masked bits be
> zero is two-fold:
>
>  * it ensures the correct class is being used for the job
>  * it ensures application-user errors are detected as early as possible
>
> I also suggest the AddressWithMask classes not have any network/container
> behaviours for a similar reason. If the developer needs these, the
> .network attribute is only a lookup away.

the problem I have with this approach is that it seems like a long way
to go for a shortcut (of checking if addr.ip != addr.network: raise
Error).

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

[Greg Ewing]

Andrew McNamara wrote:


I also suggest the AddressWithMask classes not have any network/container
behaviours for a similar reason. If the developer needs these, the
.network attribute is only a lookup away.


Another way to approach this would be for the Address
object to potentially have a 'network' attribute
referencing a Network object.

Then there are only two classes, but three use cases
are covered:

1) a Network

2) a plain, network-agnostic Address with network == None

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.

--
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] PEP 3144 review.

[Greg Ewing]

Peter Moody wrote:

I don't see where the confusion lies.  You have an address
+ netmask. ergo, you have a Network object.  The single address that
defines the base address (most commonly referred to as the network
address) is an Address object. there is no netmask associated with
that single address, ergo, it's an Address object.


But if I understand correctly, you *don't* have a network,
you have something representing a particular host address
within a network, plus information that lets you deduce the
network to which it belongs. So calling the object a
'Network' is a misnomer.

What's more, I don't see the point of having a 'network'
attribute without a mask, because the zero address of a
network on its own doesn't define the network. You need
the zero address plus a mask to do that.

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.

--
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] PEP 3144 review.

[Andrew McNamara]

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

>> A particular case in point - if you want to represent a single IP address
>> with netmask (say an interface), you use a Network class, not an Address
>> class. And the .network attribute returns a Address class!
>
>Right, and I don't see where the confusion lies.  

I suggest you are too close to the implementation to be surprised by it. 8-)

>You have an address + netmask. ergo, you have a Network object.  

In a common use case, however, this instance will not represent a
network at all, but an address. It will have container-like behaviour,
but it should not (this is a property of networks, not addresses). So
the instance will be misnamed and have behaviours that are, at best,
misleading.

>The single address that defines the base address (most commonly referred
>to as the network address) is an Address object. there is no netmask
>associated with that single address, ergo, it's an Address object.

I would argue that a Network never has a single address - by definition,
it has two or more nodes. A .network attribute should return a Network
instance. If you want the base address, this probably should be called
.base_address or just .address (to parallel the .netmask attribute).

>> The reason I suggest having the Network class assert that masked bits be
>> zero is two-fold:
>>
>> * it ensures the correct class is being used for the job
>> * it ensures application-user errors are detected as early as possible
>>
>> I also suggest the AddressWithMask classes not have any network/container
>> behaviours for a similar reason. If the developer needs these, the
>> .network attribute is only a lookup away.
>
>the problem I have with this approach is that it seems like a long way
>to go for a shortcut (of checking if addr.ip != addr.network: raise
>Error).

This isn't about shortcuts, but about correctness... having the Network
object represent a network, and having Address objects represent
end-points, and having errors discovered as early as possible.

What I'm arguing here is that singletons should not simultaneously be
containers - it's not pythonic, and it leads to ambiguity. The underlying
IP concepts don't require it either: an IP address is a singleton, a
network is a container, and there is no overlap. Yes, an address may be a
member of a network, and having a reference to that network on the address
object is valuable, but the address should not behave like a network.

-- 
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 Wed, Sep 16, 2009 at 7:48 PM, Greg Ewing  wrote:
> Peter Moody wrote:
>>
>> I don't see where the confusion lies.  You have an address
>> + netmask. ergo, you have a Network object.  The single address that
>> defines the base address (most commonly referred to as the network
>> address) is an Address object. there is no netmask associated with
>> that single address, ergo, it's an Address object.
>
> But if I understand correctly, you *don't* have a network,
> you have something representing a particular host address
> within a network, plus information that lets you deduce the
> network to which it belongs. So calling the object a
> 'Network' is a misnomer.
>
> What's more, I don't see the point of having a 'network'
> attribute without a mask, because the zero address of a
> network on its own doesn't define the network. You need
> the zero address plus a mask to do that.
>
> 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.

>
> --
> 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] PEP 3144 review.

[Andrew McNamara]

>Another way to approach this would be for the Address object to
>potentially have a 'network' attribute referencing a Network object.

Yes - that's reasonable.

>Then there are only two classes, but three use cases are covered:
>
>1) a Network
>
>2) a plain, network-agnostic Address with network == None
>
>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

I think you still need to support the common notations:

Address('10.0.0.1') # .network == None

Address('10.0.0.1/255.255.255.0')
Address('10.0.0.1/24')

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

Yes.

(Of course, we're simplifying - there would really be classes for each
protocol).

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

>>> A particular case in point - if you want to represent a single IP address
>>> with netmask (say an interface), you use a Network class, not an Address
>>> class. And the .network attribute returns a Address class!
>>
>>Right, and I don't see where the confusion lies.
>
> I suggest you are too close to the implementation to be surprised by it. 8-)

touche :)

>>You have an address + netmask. ergo, you have a Network object.
>
> In a common use case, however, this instance will not represent a
> network at all, but an address. It will have container-like behaviour,
> but it should not (this is a property of networks, not addresses). So
> the instance will be misnamed and have behaviours that are, at best,
> misleading.
>
>>The single address that defines the base address (most commonly referred
>>to as the network address) is an Address object. there is no netmask
>>associated with that single address, ergo, it's an Address object.
>
> I would argue that a Network never has a single address - by definition,
> it has two or more nodes. A .network attribute should return a Network
> instance. If you want the base address, this probably should be called
> .base_address or just .address (to parallel the .netmask attribute).

.network is shorthand for network address. are .network_address and
.broadcast_address less confusing?  I have to say, though,
.network/.broadcast are fairly common (IPy uses .net, netaddr and ipv4
use, IIRC .network...)

>>> The reason I suggest having the Network class assert that masked bits be
>>> zero is two-fold:
>>>
>>> * it ensures the correct class is being used for the job
>>> * it ensures application-user errors are detected as early as possible
>>>
>>> I also suggest the AddressWithMask classes not have any network/container
>>> behaviours for a similar reason. If the developer needs these, the
>>> .network attribute is only a lookup away.
>>
>>the problem I have with this approach is that it seems like a long way
>>to go for a shortcut (of checking if addr.ip != addr.network: raise
>>Error).
>
> This isn't about shortcuts, but about correctness... having the Network
> object represent a network, and having Address objects represent
> end-points, and having errors discovered as early as possible.

Then what I don't see is the purpose of your
network-only-network-object. essentially identical functionality can
be obtained with the module as is w/o the added complexity of new
classes.

Cheers,
/peter

> What I'm arguing here is that singletons should not simultaneously be
> containers - it's not pythonic, and it leads to ambiguity. The underlying
> IP concepts don't require it either: an IP address is a singleton, a
> network is a container, and there is no overlap. Yes, an address may be a
> member of a network, and having a reference to that network on the address
> object is valuable, but the address should not behave like a network.
>
> --
> 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 Wed, Sep 16, 2009 at 8:36 PM, Peter Moody  wrote:
> 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.
>
 A particular case in point - if you want to represent a single IP address
 with netmask (say an interface), you use a Network class, not an Address
 class. And the .network attribute returns a Address class!
>>>
>>>Right, and I don't see where the confusion lies.
>>
>> I suggest you are too close to the implementation to be surprised by it. 8-)
>
> touche :)
>
>>>You have an address + netmask. ergo, you have a Network object.
>>
>> In a common use case, however, this instance will not represent a
>> network at all, but an address. It will have container-like behaviour,
>> but it should not (this is a property of networks, not addresses). So
>> the instance will be misnamed and have behaviours that are, at best,
>> misleading.
>>
>>>The single address that defines the base address (most commonly referred
>>>to as the network address) is an Address object. there is no netmask
>>>associated with that single address, ergo, it's an Address object.
>>
>> I would argue that a Network never has a single address - by definition,
>> it has two or more nodes. A .network attribute should return a Network
>> instance. If you want the base address, this probably should be called
>> .base_address or just .address (to parallel the .netmask attribute).
>
> .network is shorthand for network address. are .network_address and
> .broadcast_address less confusing?  I have to say, though,
> .network/.broadcast are fairly common (IPy uses .net, netaddr and ipv4
> use, IIRC .network...)
>
 The reason I suggest having the Network class assert that masked bits be
 zero is two-fold:

 * it ensures the correct class is being used for the job
 * it ensures application-user errors are detected as early as possible

 I also suggest the AddressWithMask classes not have any network/container
 behaviours for a similar reason. If the developer needs these, the
 .network attribute is only a lookup away.
>>>
>>>the problem I have with this approach is that it seems like a long way
>>>to go for a shortcut (of checking if addr.ip != addr.network: raise
>>>Error).
>>
>> This isn't about shortcuts, but about correctness... having the Network
>> object represent a network, and having Address objects represent
>> end-points, and having errors discovered as early as possible.
>
> Then what I don't see is the purpose of your
> network-only-network-object. essentially identical functionality can
> be obtained with the module as is w/o the added complexity of new
> classes.

Since you mentioned correctness; it seems like we're coming back to an
option to the IPv?Network().__init__ methods which strictly checks for
host bits being masked to zero. this provides, I think, the
functionality/error checking you're looking for w/o the need for new
classes.

Cheers,
/peter


> Cheers,
> /peter
>
>> What I'm arguing here is that singletons should not simultaneously be
>> containers - it's not pythonic, and it leads to ambiguity. The underlying
>> IP concepts don't require it either: an IP address is a singleton, a
>> network is a container, and there is no overlap. Yes, an address may be a
>> member of a network, and having a reference to that network on the address
>> object is valuable, but the address should not behave like a network.
>>
>> --
>> 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.

[Scott Dial]

Peter Moody wrote:
> 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.

Speaking as the originator of this thread of discourse, the lack of a
3rd class was exactly the source of my confusion and my inability to
communicate my confusion to everyone. I clearly did not understand the
intended uses of the IPNetwork type because it was capable of playing
two roles that are decidedly different conceptually. So, I must
respectfully disagree with you.

>>> You have an address + netmask. ergo, you have a Network object.
>> In a common use case, however, this instance will not represent a
>> network at all, but an address. It will have container-like behaviour,
>> but it should not (this is a property of networks, not addresses). So
>> the instance will be misnamed and have behaviours that are, at best,
>> misleading.

This is exactly the confusion and duality that I struggled with.

>> This isn't about shortcuts, but about correctness... having the Network
>> object represent a network, and having Address objects represent
>> end-points, and having errors discovered as early as possible.
> 
> Then what I don't see is the purpose of your
> network-only-network-object. essentially identical functionality can
> be obtained with the module as is w/o the added complexity of new
> classes.

The purpose is to avoid conflating IPNetwork with an IPAddress that has
a mask. If the IPNetwork didn't accept a non-zero host and instead
required a developer to use a helper to construct a IPNetwork with a
proper address, then there would be less confusion about what exactly a
IPNetwork is meant to represent. As it stands, it's purposes is muddled
by accepting host addresses too.

I am rather indifferent whether there needs to be a IPAddressWithMask
type. If that is needed, then it is rather easy to create a type that
does that. And, if it is a common pattern, then it could be added to the
module later in life.

-- 
Scott Dial
sc...@scottdial.com
scod...@cs.indiana.edu

-- 
Scott Dial
sc...@scottdial.com
scod...@cs.indiana.edu
___
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.

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Scott Dial wrote:

> The purpose is to avoid conflating IPNetwork with an IPAddress that has
> a mask.

I'm not confused by anything in this discussion except the repeated
harping on the (to me imaginary) concept of "address with a mask".
Conceptually:

 - Addresses don't have masks:  they are just 32- (128-) bit integers.

 - Any given address can belong to a number of networks, based on a
   given topology.

 - Masks are also 32- (128-) bit integers, which happen to have the
   property that their leftmost N bits are all zero and the rest are all
   one.

 - One can construct a network from the combination of an address and
   a mask.  Such a network *never* needs to know what the address was
   before masking.

 - Networks *do* know their "zero" address, as well as their "last
   address", and can do "containment" operations on addresses (I'm not
   clear on the need to do such operations on other networks, rather
   than just using their zero addresses).

At the API level, it is convenient to represent the combination
(address, mask) as a single string (e.g., '192.168.1.0/24'):  parsing
that string should return a network, not an address.  Let's keep the
"parsing human readable / writable strings" part separate from the clear
conceptual map.

> If the IPNetwork didn't accept a non-zero host and instead
> required a developer to use a helper to construct a IPNetwork with a
> proper address, then there would be less confusion about what exactly a
> IPNetwork is meant to represent. As it stands, it's purposes is muddled
> by accepting host addresses too.

I can't imagine why it would be useful to try to infer a network from an
address:  "In the face of ambiguity, refuse the temptation to guess."

> I am rather indifferent whether there needs to be a IPAddressWithMask
> type. If that is needed, then it is rather easy to create a type that
> does that. And, if it is a common pattern, then it could be added to the
> module later in life.

Agreed.


Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKsbeU+gerLs4ltQ4RAlG0AJ9ZvhuXHsTL2hheW/vlzeMmArs5rgCeLDLS
eKWSAdkdv++umepu+nK0/7I=
=N7ej
-END PGP SIGNATURE-

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

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

It's mostly just minor refactoring and renaming, which I think makes
things clearer, although I agree this is merely an opinion. I would be
interest to hear what others think. To summarise:

 * an address is a singleton (a network endpoint), with no container
   behaviour. It may optionally reference it's network (via the .network
   attribute), .address returns mask-less address. 

 * a network is a container-like object. For consistency, .network should
   return self and raise an exception if the mask conflicts with the
   address, .address returns the base address, .mask returns an address
   object.

>> I would argue that a Network never has a single address - by definition,
>> it has two or more nodes. A .network attribute should return a Network
>> instance. If you want the base address, this probably should be called
>> .base_address or just .address (to parallel the .netmask attribute).
>
>.network is shorthand for network address. are .network_address and
>.broadcast_address less confusing?  I have to say, though,
>.network/.broadcast are fairly common (IPy uses .net, netaddr and ipv4
>use, IIRC .network...)

Yes, I understand your motivation, but I still think it's going to be more
confusing the way you have it.

>> This isn't about shortcuts, but about correctness... having the Network
>> object represent a network, and having Address objects represent
>> end-points, and having errors discovered as early as possible.
>
>Then what I don't see is the purpose of your
>network-only-network-object. essentially identical functionality can
>be obtained with the module as is w/o the added complexity of new
>classes.

Certainly, I'm not talking about adding functionality. What I am
suggesting is that if we wish to have a distinction between networks and
addresses, then that distinction should be clear and strong, such that
the choice of which to use is obvious, and if the wrong one is used,
the error is discovered as early as possible.

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

Sorry if I sound like a cracked record - these are subtle concepts,
and my ability to explain what I mean is less than is needed, but we'll
get there in the end.

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

[Stephen J. Turnbull]

Andrew McNamara writes:

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

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.

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

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

Obviously all the above applies to IPv6 classes, too.
___
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