[issue18588] timeit examples should be consistent
Changes by Clay McClure : -- assignee: docs@python components: Documentation nosy: claymation, docs@python priority: normal severity: normal status: open title: timeit examples should be consistent type: enhancement versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue18588> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18588] timeit examples should be consistent
New submission from Clay McClure: The timeit module documentation includes examples of command-line and programmatic invocation, but the results between the two sets of examples don't agree. This patch brings the results into agreement with each other. -- keywords: +patch Added file: http://bugs.python.org/file31076/18588.patch ___ Python tracker <http://bugs.python.org/issue18588> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18588] timeit examples should be consistent
Clay McClure added the comment: There's a 68% difference in running time between the command-line and programmatic invocations shown in the current documentation, and a 1% difference between the runtimes shown in the patch. I can't speak for why that is the case, but I did find it somewhat confusing when trying to interpret the timeit documentation. Being a somewhat pedantic and trivial patch, I'm fine if you want to close it wontfix. -- ___ Python tracker <http://bugs.python.org/issue18588> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
Clay McClure added the comment:
Since Python 2.7 and 3.1 have not yet shipped, I hope it's not too late
to
continue this discussion. I have no vested interest in either ipaddr or
netaddr, but I am interested in seeing a well-designed and usable IP
address
library included in the stdlib.
>From reading the comments in this issue, it seems most of the discussion
focused on netaddr's API. There seems to have been little discussion
about
the merits of ipaddr's API, which is unfortunate given that ipaddr is
the
library being included in the stdlib. There was some technical
discussion on
the ipaddr and netaddr lists, but it amounted to each developer
defending his
library, and neither party seemed willing to compromise on key design
decisions. At the end of the reconciliation period, ipaddr looks much
the
same as it did before, albeit with prettier indentation.
When looking for an IP address library for use in a network scanning and
discovery application I wrote last year, I decided against ipaddr
because of
its conflation of address and network -- it seems strange to me to have
one
class modeling both concepts.
After reading the technical discussion on the ipaddr and netaddr lists,
it is
clear to me that ipaddr's designers have a somewhat limited
understanding of
IP addressing, and have not designed an API that articulates IP concepts
particularly well. For example, see pmoody's earlier comments in this
ticket:
> all addresses have a subnet, even if its an implied /32
This is not only incorrect, but it demonstrates a deep misunderstanding
of
how IP works. IP addresses most certainly do not have a "subnet", or a
mask
of any sort. An IPv4 address is simply a 32-bit number.
IPv4 *networks* have masks, of course, hence the name "netmask". These
network masks are used by the routing process to lookup the next hop (or
directly connected network) for an IP datagram by matching the
datagram's
destination address against the networks and masks defined in the
routing
table.
> specifying a network as ("1.1.1.0", "1.1.1.255") seems a lot more
> off-putting than "1.1.1.0/24".
Since networks are commonly represented in at least three forms, the API
should support at least these:
CIDR/prefix notation: "192.168.1.0/24"
address+mask notation: "192.168.1.0/255.255.255.0"
range notation: "192.168.1.0-192.168.1.255"
> I guess I don't see the utility in an address range of .1 - .22
> (or something arbitrary, something which doesn't fall on a power-of-2
> boundary); when dealing with ranges of addresses, i've always only
> wanted to/needed to manipulate sub-networks of addresses.
This statement demonstrates an extremely narrow view of the problem
domain.
Access lists and DHCP pools are two common examples of where arbitrary
address ranges are useful.
At least three concepts deserve first-class treatment in any meaningful
IP
address library:
* addresses
* ranges of addresses
* networks
To conflate these is a mistake.
My hope is that now that a library has been selected, it can be improved
before Python 2.7 and 3.1 ship. Now is the best time to make
backwards-incompatible API changes; once ipaddr ships with the stdlib,
we're
stuck with it. If it remains as-is, it will be deadweight for those app
developers like myself who prefer an API that more accurately reflects
the
problem domain.
To this end, now that ipaddr is moving to Python stdlib, will Google's
contributor license agreement restriction be lifted? I would like to
contribute, but have not been able to secure a corporate CLA from my
employer.
Cheers,
Clay
--
nosy: +claymation
___
Python tracker
<http://bugs.python.org/issue3959>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
Clay McClure added the comment:
On Mon, Jun 1, 2009 at 1:09 PM, Martin v. Löwis wrote:
>> My hope is that now that a library has been selected, it can be improved
>> before Python 2.7 and 3.1 ship.
>
> That is fairly unlikely. The 3.1 release candidate has been produced,
> so the only options possible at this point are to either go ahead with
> what is in the code, or withdraw the library from 3.1 if it can be
> demonstrated to have severe flaws.
False
>>> ipaddr.IPv4('192.168.1.1') == ipaddr.IPv4('192.168.1.1/32')
True
ipaddr makes no distinction between two fundamentally different
concepts -- to my mind, that is a serious flaw.
ipaddr has many other quirks that, while not technically flaws, are
design warts that deserve to be fixed before its target audience is
amplified by its inclusion in the stdlib.
To those arguing for ipaddr's inclusion in the stdlib, how many of you
will actually use ipaddr to develop software? As an actual developer
of network scanning and discovery software, I can tell you that I
would rather roll my own library than use ipaddr as it exists today.
Clay
--
___
Python tracker
<http://bugs.python.org/issue3959>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
Clay McClure added the comment: Strangely, the leading line of my last response was eaten by the bug tracker. It read: >>> 1 == (1,) -- ___ Python tracker <http://bugs.python.org/issue3959> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
Clay McClure added the comment:
On Mon, Jun 1, 2009 at 5:02 PM, R. David Murray wrote:
>> >>> ipaddr.IPv4('192.168.1.1') == ipaddr.IPv4('192.168.1.1/32')
>> True
>
> As a network engineer I don't see any inherent problem with that equality.
> In fact I make use of that conceptual equality on a regular basis.
For an example of why 192.168.1.1 != 192.168.1.1/32, look no further
than ifconfig:
# ifconfig en0 192.168.1.1/32
# ifconfig en0
en0: flags=8863 mtu 1500
inet 192.168.1.1 netmask 0x broadcast 192.168.1.1
...
# ifconfig en0 192.168.1.1
# ifconfig en0
en0: flags=8863 mtu 1500
inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255
...
Can you provide an example of when 192.168.1.1 does in fact equal
192.168.1.1/32?
> Further, if you were to add a specifically 'address-without-netmask'
> type, the above equality would still be true, because then the above
> would be comparing two addresses-with-netmasks and you would want to
> apply the hostmask to a bare address for convenience. To get inequality,
> you'd be comparing two different object types...which comparison would
> be False by default.
I don't follow. Assuming hypothetical Address and Network classes, as
accurately models the problem domain, we would have:
False
That seems to me the correct behavior, since an address is in fact not
the same thing as a network.
Clay
--
___
Python tracker
<http://bugs.python.org/issue3959>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
Clay McClure added the comment:
On Mon, Jun 1, 2009 at 4:54 PM, Martin v. Löwis wrote:
> Do you have an application in mind where this lack of distinction
> would prevent writing the application in a straight-forward way?
> IOW, could you do something if they were distinct that you can't
> do because they are not?
Consider applications that use ipaddr.IPv4 objects to configure
network interfaces:
ifconfig: 255.255.255.0/32: bad value
That's because ipaddr wrongly appends a prefix length to all
ipaddr.IPv4 objects, even those representing addresses, which do not
have prefix lengths.
Consider applications that need to validate addresses (or networks,
but not both) supplied as user input:
address = ipaddr.IP(input)
if isinstance(address, ipaddr.IPv4):
if address.prefixlen != 32:
raise TypeError("Expecting IP address, not network")
elif isinstance(address, ipaddr.IPv6):
if address.prefixlen != 128:
raise TypeError("Expecting IP address, not network")
Given its myriad quirks, it is really rather surprising that ipaddr is
being considered for inclusion in the Python stdlib.
Clay
--
___
Python tracker
<http://bugs.python.org/issue3959>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
Clay McClure added the comment:
On Mon, Jun 1, 2009 at 4:51 PM, pmoody wrote:
>>>>> ipaddr.IPv4('192.168.1.1') == ipaddr.IPv4('192.168.1.1/32')
>> True
>>
>> ipaddr makes no distinction between two fundamentally different
>> concepts -- to my mind, that is a serious flaw.
>
> I don't see these a fundamentally different, I guess. can you
> demonstrate how this equivalency makes ipaddr unusable?
Fortunately, it's not up for debate: RFC-791 defines an IP address as
a 32-bit number, with no provision for a mask. Networks are defined by
their address and their mask. To correctly model them in an
object-oriented system, we would say that a Network has-a Address,
certainly not that a Network is-a Address.
> I haven't seen any new issues on code.google.com (and I haven't heard
> of any being reported on the python bugtracker), so since you're using
> this thread to report issues, can you elaborate?
I will go ahead and open issues on code.google.com.
> have used it to develop software and will continue to use it to
> develop software.
I'd like to hear from application developers outside of Google. The
two that have commented on this issue seem not to prefer ipaddr's API.
Clay
--
___
Python tracker
<http://bugs.python.org/issue3959>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
Clay McClure added the comment: On Mon, Jun 1, 2009 at 7:51 PM, pmoody wrote: >> For an example of why 192.168.1.1 != 192.168.1.1/32, look no further >> than ifconfig: >> >> # ifconfig en0 192.168.1.1/32 >> # ifconfig en0 >> en0: flags=8863 mtu 1500 >> inet 192.168.1.1 netmask 0x broadcast 192.168.1.1 >> ... >> >> # ifconfig en0 192.168.1.1 >> # ifconfig en0 >> en0: flags=8863 mtu 1500 >> inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 >> ... > > what this shows is that your copy of darwin defaults to a /24 > prefixlen; ipaddr assumes a /32 prefixlen. I don't see anything > particularly *more* intuitive with darwin, but in any event, it seems > to provide support for assuming a prefixlen when none is supplied. The example demonstrates one case where the strings '192.168.1.1' and '192.168.1.1/32' are not equivalent -- it wouldn't be hard to find other examples -- yet you seem to think that (a) this is Darwin-specific behavior, and that (b) this discrepancy is acceptable and does not constitute a design flaw. You're wrong on both fronts, since in fact all IP implementations understand classful addressing (as per RFC-791), not just Darwin, and your insistence on the equality of '192.168.1.1' and '192.168.1.1/32' means that your library is unusable in applications that pass ipaddr.IPv4 objects to ifconfig. Clay -- ___ Python tracker <http://bugs.python.org/issue3959> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
Clay McClure added the comment: On Mon, Jun 1, 2009 at 8:05 PM, R. David Murray wrote: > In pre-CIDR days, assuming a prefixlen of 24 for a 192.168.x.x address > made sense. Nowadays it is better not to make that assumption. So I > find ipaddr's default of 32 to be "safer" than using a class based default. Sorry, but why should you determine what is better for my application? > The larger point, however, is that there _is_ a mask associated with the > address in ifconfig. There _must_ be one. So that is not an example > that shows that a separate address class is useful. Again, you're wrong. The mask that you see in ifconfig is associated with the network to which the interface is attached, not the interface address. You also see a broadcast address in the ifconfig output, but certainly you don't believe that the broadcast address is a property of the interface address? No, of course not; it's a property of the network to which the interface is attached -- just like the mask. That's why we call it a "netmask". > As for an example of when the equivalence is useful, it is useful every > time I set up an access rule or route that applies to a single host. Host routes are routes like all others -- they have a destination address and a mask. That a host route has a prefix length of 32 does not imply that the host route is equivalent to the host address. You're confusing the two concepts. > Most networking > software that I've dealt with requires explicit netmasks (often with a > shorthand to specify an ip/hostmask pair). By "ip/hostmask" pair, you actually mean "ip/netmask" pair, and yes, this is a convenient notation for expressing two distinct but related concepts: an address, and a mask. Addresses do not have masks; networks do. I am not sure how to be any more clear about that point, yet you still seem not to understand. > It is true that when a > netmask isn't required it generally defaults to the classful netmask, > but having such a default is becoming more rare with time, in my > experience (because of CIDR). I'm not advocating classful routing, I'm merely stating (emphatically and without ambiguity) that addresses and networks are different: networks have masks; addresses do not. The ipaddr library forces a mask on me every time I specify an address. In my view, that is a design flaw. Clay -- ___ Python tracker <http://bugs.python.org/issue3959> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
Clay McClure added the comment:
On Mon, Jun 1, 2009 at 9:03 PM, pmoody wrote:
>> ifconfig: 255.255.255.0/32: bad value
>>
>> That's because ipaddr wrongly appends a prefix length to all
>> ipaddr.IPv4 objects, even those representing addresses, which do not
>> have prefix lengths.
>
> I'm not sure what you're trying to do here, can you elaborate?
Let's say I have a UI that prompts users for two pieces of
information: interface address, and network mask. I then take those
two strings and make ipaddr.IPv4 objects out of them. This lets me
validate their correctness, and lets me perform convenient
calculations and tests (things the ipaddr library has done well).
Next, I take the IPv4 objects, coerce them to strings, and pass them
to ifconfig to configure an interface.
Assuming the user has supplied this information:
Interface address = '192.168.1.1'
Network mask = '255.255.255.0'
the following would get passed to ifconfig:
ifconfig en0 192.168.1.1/32 netmask 255.255.255.0/32
Clearly this is not what we expect, nor even legal. The principle of
least surprise is violated here, if nothing else.
We could work around this, of course, but why should we have to work
around our libraries when simply fixing them isn't that hard?
>> if isinstance(address, ipaddr.IPv4):
>> if address.prefixlen != 32:
>> raise TypeError("Expecting IP address, not network")
>> elif isinstance(address, ipaddr.IPv6):
>> if address.prefixlen != 128:
>> raise TypeError("Expecting IP address, not network")
>
> i'm not sure what's onerous about this code. you're missing a
> try/except around ipaddr.IP(), but otherwise it seems fine.
Your definition of onerous apparently differs from mine :)
In my own applications, when I'm expecting a network, I use an
IPNetwork class, and when I'm expecting an address, I use an IPAddress
class. This means I can simply rely on the class constructors to do
the type checking for me. With ipaddr, I have to do the validation
myself. Simple isinstance() testing and duck typing don't work because
networks and addresses are represented (wrongly) by the same class.
> it's actually already been included, but that's beside the point. I'm
> now asking you a second time to submit bug reports if there are issues
> which you see; perhaps these 'myriad of quirks' can be fixed, perhaps
> not. yelling here doesn't actually do anything productive.
Rest assured, I've opened one issue and will open one or two more
before the night is out.
I'm sorry that you think "yelling" is unproductive. I happen to think
that healthy debate breeds better code.
Cheers,
Clay
--
___
Python tracker
<http://bugs.python.org/issue3959>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
Clay McClure added the comment: On Tue, Jun 2, 2009 at 1:21 AM, Martin v. Löwis wrote: >> I will go ahead and open issues on code.google.com. > > If you want to see them fixed in Python, please report them to this > tracker. I'd like to see the issues fixed upstream, and the library removed from Python until it is satisfactory to the developers who will actually use it. To my knowledge, every developer (outside of Google) who has commented on the issue has indicated a preference for a different API. Thanks, Clay -- ___ Python tracker <http://bugs.python.org/issue3959> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
Clay McClure added the comment: On Tue, Jun 2, 2009 at 2:18 AM, Martin v. Löwis wrote: >> I'd like to see the issues fixed upstream, and the library removed >> from Python until it is satisfactory to the developers who will >> actually use it. To my knowledge, every developer (outside of Google) >> who has commented on the issue has indicated a preference for a >> different API. > > That's not true - I'm outside of Google, and have not indicated such > a preference. You've indicated no preference either way, and have said: "I personally have no plans for using this library, or any other IP address library" I should think you would seek the opinion of those developers who actually do have plans to use an IP address library. As far as I can tell, every developer in that category, outside of Google, that has commented on this issue here or in python-dev has advocated a different API. Clay -- ___ Python tracker <http://bugs.python.org/issue3959> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
Clay McClure added the comment: On Tue, Jun 2, 2009 at 2:52 AM, pmoody wrote: >> As far as I can >> tell, every developer in that category, outside of Google, that has >> commented on this issue here or in python-dev has advocated a >> different API. > > Is there some sort of conspiracy theory-ish reason that a google > software engineer might be somehow unfairly influenced? >From reading your comments and the code, it is clear that concepts that aren't relevant at Google have been neglected. For that reason, developers at Google who are already familiar with ipaddr might consider its API quite natural because of their institutionalized thinking. But since this library is now intended for general purpose use outside Google, I should think it is important to consult developers outside Google who have been exposed to a broader range of IP addressing issues. I don't believe that "good enough for Google" ought to be our acid test. The fact that developers outside Google seem to prefer a different API is not new -- comments in this issue dating back several months reflect that fact. What I don't see is a comment that explains why their concerns were not considered. Clay -- ___ Python tracker <http://bugs.python.org/issue3959> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
