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 i
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
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
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
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, ever
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
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
>&g
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 "
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 150
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
>> conc
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 c
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.
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.o
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,
>
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 s
15 matches
Mail list logo
