2009/6/3 Stephen J. Turnbull step...@xemacs.org:
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
2009/6/2 R. David Murray rdmur...@bitdance.com:
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)
...
-
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
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.
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
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.
OT
It's just a shorthand way of writing IPv4 net masks based on their
binary form:
/8 = 8 ones followed by 24 zeroes =
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
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
R. David Murray rdmur...@bitdance.com 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
Barry Warsaw ba...@python.org 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
On Wed, Jun 3, 2009 at 10:13 AM, Neil Schemenauer n...@arctrix.com wrote:
Barry Warsaw ba...@python.org 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
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 07:51 am, p.f.mo...@gmail.com wrote:
2009/6/3 Stephen J. Turnbull step...@xemacs.org:
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
On 05:19 pm, gu...@python.org wrote:
On Wed, Jun 3, 2009 at 10:13 AM, Neil Schemenauer n...@arctrix.com
wrote:
Barry Warsaw ba...@python.org 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
[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
On Wed, Jun 3, 2009 at 11:16 AM, R. David Murray rdmur...@bitdance.com 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
Benjamin Peterson schrieb:
2009/6/2 Guido van Rossum gu...@python.org:
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
[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
On Wed, Jun 3, 2009 at 2:58 PM, Raymond Hettinger pyt...@rcn.com 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
we
On Tue, Jun 2, 2009 at 1:47 AM, Martin v. Löwis mar...@v.loewis.de 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
Clay McClure wrote:
On Tue, Jun 2, 2009 at 1:38 AM, Martin v. Löwis mar...@v.loewis.de 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
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,
On Mon, 1 Jun 2009 at 18:54, Jake McGuire wrote:
On Mon, Jun 1, 2009 at 12:16 PM, Martin v. L?wis mar...@v.loewis.dewrote:
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
On Tue, Jun 2, 2009 at 9:22 AM, R. David Murray rdmur...@bitdance.com 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
On Tue, Jun 2, 2009 at 2:15 AM, Martin v. Löwis mar...@v.loewis.de 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
On Tue, Jun 2, 2009 at 2:08 AM, Martin v. Löwis mar...@v.loewis.de 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
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 could
On Tue, 02 Jun 2009 19:34:11 +0200, \Martin v. Löwis\ mar...@v.loewis.de
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
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, there
On Tue, Jun 2, 2009 at 10:34 AM, Martin v. Löwis mar...@v.loewis.de 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
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
2009/6/2 Bugbee, Larry larry.bug...@boeing.com:
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
On Tue, 2 Jun 2009 at 12:26, Clay McClure wrote:
On Tue, Jun 2, 2009 at 2:08 AM, Martin v. L?wis mar...@v.loewis.de 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
On Tue, Jun 2, 2009 at 9:26 AM, Clay McClure c...@daemons.net wrote:
On Tue, Jun 2, 2009 at 2:08 AM, Martin v. Löwis mar...@v.loewis.de 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
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 this
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).
On Tue, Jun 2, 2009 at 4:53 PM, R. David Murray rdmur...@bitdance.com 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
Clay McClure clay at 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
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
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\ mar...@v.loewis.de
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
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 Tue, Jun 2, 2009 at 1:11 PM, Jake McGuire mcgu...@google.com 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
On Tue, Jun 2, 2009 at 7:39 PM, Guido van Rossum gu...@python.org 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
2009/6/2 Guido van Rossum gu...@python.org:
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
2009/6/2 Aahz a...@pythoncraft.com:
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
On Tue, Jun 2, 2009 at 10:41 PM, Gregory P. Smith g...@krypto.org 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
2009/6/2 Gregory P. Smith g...@krypto.org:
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
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
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've seen
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
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
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
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
On Mon, Jun 1, 2009 at 12:16 PM, Martin v. Löwis mar...@v.loewis.dewrote:
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
On Mon, Jun 1, 2009 at 6:54 PM, Jake McGuire mcgu...@google.com wrote:
On Mon, Jun 1, 2009 at 12:16 PM, Martin v. Löwis mar...@v.loewis.dewrote:
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,
On Mon, Jun 1, 2009 at 11:32 AM, Guido van Rossum guido at python.org 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
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't
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 to
On Tue, Jun 2, 2009 at 1:38 AM, Martin v. Löwis mar...@v.loewis.de 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
59 matches
Mail list logo
