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
28 matches
Mail list logo
