On Wed, Jun 3, 2009 at 2:58 PM, Raymond Hettinger wrote:
> [GvR]
Benjamin, what would be involved in removing it? I suppose there's the
module itself, some unit tests, and some docs. (I'm not asking you to
remove it yet -- but I'm asking to look into the consequences, so that
>
[GvR]
Benjamin, what would be involved in removing it? I suppose there's the
module itself, some unit tests, and some docs. (I'm not asking you to
remove it yet -- but I'm asking to look into the consequences, so that
we can be sure to do the right thing before releasing 3.1 final.)
[Benjamin P
Benjamin Peterson schrieb:
> 2009/6/2 Guido van Rossum :
>> Benjamin, what would be involved in removing it? I suppose there's the
>> module itself, some unit tests, and some docs. (I'm not asking you to
>> remove it yet -- but I'm asking to look into the consequences, so that
>> we can be sure to
On Wed, Jun 3, 2009 at 11:16 AM, R. David Murray wrote:
> I think this hits the nail on the head. Rather than network engineers
> having a less precise understanding of IP, what we have is two different
> sets of domain requirements. Network engineers deal with networks, with
> IPs being a nece
[GvR]
Whoa. Are you all suddenly trying to turn Python into a democracy?
Arthur: I am your king!
Woman: Well I didn't vote for you!
Arthur: You don't vote for kings.
Woman: Well how'd you become king then?
[Angelic music plays...]
Arthur: The Lady of the Lake, her arm clad in the purest s
On 05:19 pm, gu...@python.org wrote:
On Wed, Jun 3, 2009 at 10:13 AM, Neil Schemenauer
wrote:
Barry Warsaw wrote:
It would be really nice if say the Cheeseshop had a voting feature.
Use PEP 10 voting to get a rough estimate of a module's popularity
(download counts alone might not tell you ev
On 07:51 am, p.f.mo...@gmail.com wrote:
2009/6/3 Stephen J. Turnbull :
One thing I would recommend is that while inclusion is not a matter of
voting, people who are recognized as domain experts on Python-Dev
*should* try to add their "+1" or "-1" early. �Especially if they
don't expect to have
On 02:44 am, a...@pythoncraft.com wrote:
On Tue, Jun 02, 2009, Guido van Rossum wrote:
I hope we can learn from this.
I'm not thrilled with adding more process just because we had a problem
here, and the only obvious solution I see is to require a PEP every
time
a module is added. Based on
On Wed, Jun 3, 2009 at 10:13 AM, Neil Schemenauer wrote:
> Barry Warsaw wrote:
>> It would be really nice if say the Cheeseshop had a voting feature.
>> Use PEP 10 voting to get a rough estimate of a module's popularity
>> (download counts alone might not tell you everything). Then at least
>> y
Barry Warsaw wrote:
> It would be really nice if say the Cheeseshop had a voting feature.
> Use PEP 10 voting to get a rough estimate of a module's popularity
> (download counts alone might not tell you everything). Then at least
> you can get a rough idea of how generally popular a module
R. David Murray wrote:
> Both approaches are valid, but lead to different design decisions.
> I don't see any reason why both needs cannot be met by a common API,
> but I'm wondering if any existing package is going to incorporate both
> approaches satisfactorily. As another poster said, each pa
On Wed, 3 Jun 2009 at 03:42, Mike Pennington wrote:
That said, I test drove ipaddr for about 30 minutes and so far like the
big-picture API design quite a bit. I'll specifically address Clay's concern
about hosts vs networks, because this issue is important to me; I've been in
the network engi
> I've just subscribed to python-dev again after being pointed towards
> this thread (thanks Raymond).
The same for me, thanks. :-)
I'm the author of IPLib [1]; I don't consider myself an expert on the
subject and my code dates back to Python 1.6 times (last updated in 2005).
Moreover, while it wo
Paul Moore wrote:
> Note 1 - by the way, I use this form because I don't understand how
> the /24 notation works. I can get the subnet mask from ipconfig, so I
> use that.
It's just a shorthand way of writing IPv4 net masks based on their
binary form:
/8 = 8 ones followed by 24 zeroes = 255.0.
On Jun 2, 2009, at 10:39 PM, Guido van Rossum wrote:
I hope we can learn from this.
One crazy thought: let's use the Cheeseshop.
When I search for 'ipaddr' I get three hits, with Google's module at
the top with a score of '8'. I really don't know what that means but
I'm guessing it means
On Jun 2, 2009, at 10:43 PM, Gregory P. Smith wrote:
Should it only be removed from py3k branch or also from trunk pending
a decision as to if the library is reworked or if something else
entirely is adopted?
I think it should be removed from trunk if it's removed from the py3k
branch. Noth
Raymond solicited a comment from me about the design of ipaddr. By way
of full disclosure, I have a small competing project called pynet.
That said, I test drove ipaddr for about 30 minutes and so far like the
big-picture API design quite a bit. I'll specifically address Clay's
concern about
2009/6/2 R. David Murray :
> On Tue, 2 Jun 2009 at 21:02, Paul Moore wrote:
>> Simple example. If I want to scan all the IP addresses on my network
>> (my IP address is 192.168.1.101) I'd probably write:
>>
>> for i in range(253):
>> ip = '192.168.1.' + str(i+1)
>> ...
>>
>> - and to
2009/6/3 Stephen J. Turnbull :
> Aahz writes:
>
> > On Tue, Jun 02, 2009, Guido van Rossum wrote:
> > >
> > > I hope we can learn from this.
> >
> > I'm not thrilled with adding more process just because we had a problem
> > here, and the only obvious solution I see is to require a PEP every
Aahz writes:
> On Tue, Jun 02, 2009, Guido van Rossum wrote:
> >
> > I hope we can learn from this.
>
> I'm not thrilled with adding more process just because we had a problem
> here, and the only obvious solution I see is to require a PEP every time
> a module is added. Based on what I'v
On 03/06/2009, at 12:39 PM, Guido van Rossum wrote:
I'm disappointed in the process -- it's as if nobody really reviewed
the API until it was released with rc1, and this despite there being a
significant discussion about its inclusion and alternatives months
ago. (Don't look at me -- I wouldn't
2009/6/2 Gregory P. Smith :
> Should it only be removed from py3k branch or also from trunk pending
> a decision as to if the library is reworked or if something else
> entirely is adopted?
I think it should disappear from the whole python tree for the moment.
Even the unstable trunk is not a good
On Tue, Jun 2, 2009 at 10:41 PM, Gregory P. Smith wrote:
> ipaddr could be changed to yield IPv4 /32 or IPv6 /128 objects when
> iterating over it instead of strings and this example would work
> properly.
I have opened an issue in the ipaddr bug tracker that I think
addresses this issue. There
2009/6/2 Aahz :
> On Tue, Jun 02, 2009, Guido van Rossum wrote:
>>
>> I hope we can learn from this.
>
> I'm not thrilled with adding more process just because we had a problem
> here, and the only obvious solution I see is to require a PEP every time
> a module is added. Based on what I've seen o
2009/6/2 Guido van Rossum :
> Benjamin, what would be involved in removing it? I suppose there's the
> module itself, some unit tests, and some docs. (I'm not asking you to
> remove it yet -- but I'm asking to look into the consequences, so that
> we can be sure to do the right thing before releasi
On Tue, Jun 02, 2009, Guido van Rossum wrote:
>
> I hope we can learn from this.
I'm not thrilled with adding more process just because we had a problem
here, and the only obvious solution I see is to require a PEP every time
a module is added. Based on what I've seen of this discussion so far, I
On Tue, Jun 2, 2009 at 7:39 PM, Guido van Rossum wrote:
>
> I'm disappointed in the process -- it's as if nobody really reviewed
> the API until it was released with rc1, and this despite there being a
> significant discussion about its inclusion and alternatives months
> ago. (Don't look at me --
On Tue, Jun 2, 2009 at 1:11 PM, Jake McGuire wrote:
> The minimal demonstration of the problem of representing networks and
> addresses using the same class:
fwiw, that (hosts vs networks in the same class) is not what you are
demonstrating below. What you demonstrate is that its silly for
itera
Well, it sounds like the current incarnation of the ipaddr module is
widely loathed, even if it also has some fans. Since it is still
available as a 3rd party module, and hasn't been available in other
releases except 3.1 beta and rc1, I expect few users will be
inconvenienced if we withdraw it at
On 03/06/2009, at 3:56 AM, Jean-Paul Calderone wrote:
On Tue, 02 Jun 2009 19:34:11 +0200, "\"Martin v. Löwis\"" > wrote:
[snip]
You seem comfortable with these quirks, but then you're not planning
to write software with this library. Developers who do intend to
write
meaningful network appl
I've just subscribed to python-dev again after being pointed towards this
thread (thanks Raymond).
I'd be the first to accept failings and oddities in the interface of my own
library. Since its release netaddr has taken its own interesting set of
twists and turns. However, all along I have tried t
Clay McClure daemons.net> writes:
>
> Not only useful, but necessary. It seems there are few people on this
> list who understand IP well enough to realize how distorted ipaddr
> actually is.
Not having myself enough knowledge about IP routing and administration (although
I did happen to dissect
On Tue, Jun 2, 2009 at 4:53 PM, R. David Murray wrote:
> Having thought more about this, I will agree with you that it would
> be useful to have an address-without-netmask class.
Not only useful, but necessary. It seems there are few people on this
list who understand IP well enough to realize h
On Tue, 2 Jun 2009 at 21:02, Paul Moore wrote:
* I'd expect separate classes for "an IP address" and "a subnet" -
I've no problem with that expectation being wrong, but I'd like some
documentation as to *why* a single class is appropriate. (More
generally, the documentation seems pretty terse). S
> Clay repeatedly pointed out that other people have objected to ipaddr and
> been ignored. It's really, really disappointing to see you continue to
> ignore not only them, but the repeated attempts Clay has made to point
> them out.
[I meant to stop discussing here, but I just want comment on th
On Tue, Jun 2, 2009 at 9:26 AM, Clay McClure wrote:
> On Tue, Jun 2, 2009 at 2:08 AM, "Martin v. Löwis" wrote:
>
>>> That doesn't solve much. IPv4 objects still always use CIDR notation
>>> when coerced to strings, meaning that IP addresses will always be
>>> rendered with a trailing "/32".
>>
>>
On Tue, 2 Jun 2009 at 12:26, Clay McClure wrote:
On Tue, Jun 2, 2009 at 2:08 AM, "Martin v. L?wis" wrote:
py> x = ipaddr.IP("30.40.50.60")
py> print(x.ip_ext_full)
30.40.50.60
Thankfully the authors have provided this obscure and strangely-named
method to get at the correct string representat
2009/6/2 Bugbee, Larry :
>> > > I don't hear a public outcry - only a single complainer.
>> >
>> > Clay repeatedly pointed out that other people have objected
>> > to ipaddr and been ignored. It's really, really disappointing
>> > to see you continue to ignore not only them, but the repeated
>> >
> The chances of a problem being introduced due to its removal
> are vanishingly small.
But that provides little consolation to the user who sees it in the
standard library, is not aware to this discussion, and builds it into
his app. Changes to the lib later may cause subtle but significant
ef
On Tue, Jun 2, 2009 at 10:34 AM, "Martin v. Löwis" wrote:
>>> We could remove it, but then what we have wouldn't really be a release
>>> candidate anymore, so the release would get delayed.
>>
>> How long do release candidates soak in the field before being accepted?
>
> For this release, the rele
We could remove it, but then what we have wouldn't really be a release
candidate anymore, so the release would get delayed.
Not true. There is a second release candidate scheduled on June 13th.
Removing the module involves doing "svn remove" on two files and
updating Misc/NEWS. Yesterday, ther
On Tue, 02 Jun 2009 19:34:11 +0200, "\"Martin v. Löwis\""
wrote:
[snip]
You seem comfortable with these quirks, but then you're not planning
to write software with this library. Developers who do intend to write
meaningful network applications do seem concerned, yet we're ignored.
I don't h
>> We could remove it, but then what we have wouldn't really be a release
>> candidate anymore, so the release would get delayed.
>
> How long do release candidates soak in the field before being accepted?
For this release, the release schedule is defined in PEP 375
> I'm curious if an exception
On Tue, Jun 2, 2009 at 2:08 AM, "Martin v. Löwis" wrote:
>> That doesn't solve much. IPv4 objects still always use CIDR notation
>> when coerced to strings, meaning that IP addresses will always be
>> rendered with a trailing "/32".
>
> That's not true:
>
> py> x = ipaddr.IP("30.40.50.60")
> py>
On Tue, Jun 2, 2009 at 2:15 AM, "Martin v. Löwis" wrote:
> We could remove it, but then what we have wouldn't really be a release
> candidate anymore, so the release would get delayed.
How long do release candidates soak in the field before being accepted?
I'm curious if an exception could be m
On Tue, Jun 2, 2009 at 9:22 AM, R. David Murray wrote:
> ip[0]
>>
>> '10.33.11.17'
>
> Actually I find that very intuitive if I understand that the objects
> are always networks.
I suspect the authors would disagree with you on this point, since
they insist that host routes and host addresse
On Mon, 1 Jun 2009 at 18:54, Jake McGuire wrote:
On Mon, Jun 1, 2009 at 12:16 PM, "Martin v. L?wis" wrote:
As for Clay McLure's issue: I feel it's primarily a matter of taste.
I see nothing morally wrong in using the same class for hosts and
networks, i.e. representing a host as a network of siz
> This argument makes no sense. The feasibility of removing the library
> does not depend on the severity of the issues found within it. Either
> it is hard to remove the library, or it is easy. If it's hard to
> remove, it doesn't get any easier because I discover a fatal flaw.
We could remove it
Clay McClure wrote:
> On Tue, Jun 2, 2009 at 1:38 AM, "Martin v. Löwis" wrote:
>
>> For the net-vs-host issue, I think a backwards-compatible solution
>> is possible: just give the IP() function an option parameter that
>> makes it reject a netmask during parsing.
>
> That doesn't solve much. IP
On Tue, Jun 2, 2009 at 1:47 AM, "Martin v. Löwis" wrote:
>> If this were a core feature that many developers were anxiously
>> awaiting, I could understand the desire to release and iterate. But is
>> there really a pressing need for an IP library in the stdlib?
>
> You should have asked this que
On Tue, Jun 2, 2009 at 1:38 AM, "Martin v. Löwis" wrote:
> For the net-vs-host issue, I think a backwards-compatible solution
> is possible: just give the IP() function an option parameter that
> makes it reject a netmask during parsing.
That doesn't solve much. IPv4 objects still always use CID
> If this were a core feature that many developers were anxiously
> awaiting, I could understand the desire to release and iterate. But is
> there really a pressing need for an IP library in the stdlib?
You should have asked this question a few month ago. Now, release
mechanics make it difficult t
> Clay is basically correct. The ipaddr.py API is missing important
> features, and it would probably be a mistake to add it to the python
> standard library if that means we'd have to maintain compatibility for
> the indefinite future.
>From a maintenance point of view, these two statements don'
On Mon, Jun 1, 2009 at 11:32 AM, Guido van Rossum wrote:
> I haven't read the bug, but given the extensive real-life use that
> ipaddr.py has seen at Google before inclusion into the stdlib, I think
> "deep conceptual flaws" must be an overstatement.
When the users of the library are also the au
On Mon, Jun 1, 2009 at 6:54 PM, Jake McGuire wrote:
> On Mon, Jun 1, 2009 at 12:16 PM, "Martin v. Löwis" wrote:
>
>> As for Clay McLure's issue: I feel it's primarily a matter of taste.
>> I see nothing morally wrong in using the same class for hosts and
>> networks, i.e. representing a host as a
On Mon, Jun 1, 2009 at 12:16 PM, "Martin v. Löwis" wrote:
> As for Clay McLure's issue: I feel it's primarily a matter of taste.
> I see nothing morally wrong in using the same class for hosts and
> networks, i.e. representing a host as a network of size 1. I can
> understand why people dislike th
Raymond Hettinger wrote:
> Also at issue is whether the
> addition was too rushed (see David Moss's comment on the tracker and
> later comments by Antoine Pitrou).
That comment was from January 2009; it had two aspects
a) is ipaddr getting special treatment just because it was contributed
by Go
On Mon, 1 Jun 2009 at 11:32, Raymond Hettinger wrote:
Does anyone here know if Clay's concern about subnets vs netmasks in accurate
and whether it affects the usability of the module?
I can't speak to usability of the module, not having looked at it yet,
but as far as I know from 10+ years of e
I haven't read the bug, but given the extensive real-life use that
ipaddr.py has seen at Google before inclusion into the stdlib, I think
"deep conceptual flaws" must be an overstatement. There may be real
differences of opinion about the politically correct way to view
subnets and netmasks, but I
In http://bugs.python.org/issue3959 , Clay McClure is raising some objections to the new ipaddr.py module. JP Calderone shares his
concerns. I think they were the only commenters not directly affiliated with one of the competing projects. The issues they've
raised seem serious, but I don't kno
60 matches
Mail list logo
