[Python-Dev] Serious regression in doctest in Py3.1rc1
Hi, I can't currently file a bug report on this, but I was told by Lisandro Dalcín that there is a serious problem with the doctest module in Py3.1rc1. In Cython, we use doctests to test the compiler in that we compile a Python/Cython module with doctests into a C module and then run doctest on the imported extension module. >From the error report it seems to me that doctest is now trying to read the module itself through linecache for some reason, which horribly fails for a binary module. Could someone please look into this? I'll open up a bug report tomorrow unless someone beats me to it. Thanks, Stefan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with Py3.1's new ipaddr
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 time > > a module is added. Based on what I've seen of this discussion so far, I > > think that cure would at this time be worse than the disease. > > +1 [...] > > 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 time to participate actively in discussion. > > After all, they can always change their assessment based on either > changes or as a response to a persuasive lobby, precisely because it's > not a vote. FWIW, I'd add some points: 1. Publishing the documentation somewhere prominent would help. I don't know if that happened here, but it makes it a *lot* easier for people to "have a quick look". Downloading a zip file, unpacking the docs and opening a HTML file (or worse still, building it first!) can be enough of a barrier to stop people who are pressed for time from commenting. (Once the module was included, it gets into the online Python docs, hence I could read them and comment). 2. Encouraging a clear +1/-1 from people, in addition to discussion on specific points, would clarify things. I believe Martin commented that he hadn't realised that one of the opposing comments was a strong enough objection to count as a -1. 3. Discussion should happen on python-dev, not on the tracker. (Some people may object to this, I know). I saw the call for input to the tracker item, and thought "that's not a module I'm likely to need, I'll leave it to the experts" and did nothing more. When the discussion flared up on python-dev, on the other hand, I kept skimming the discussion, and when I saw something that seemed at my level, I felt encouraged to comment. Also, seeing that there *was* disagreement encouraged me to comment - if the experts aren't agreeing, maybe my non-expert view might be helpful input on usability/intuitiveness. But I agree, let's not add more process if a bit of focus in the discussion is enough. Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with Py3.1's new ipaddr
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 heck with generality.
>>
>> Even after reading the documentation, I've *no idea* how I would use
>> the ipaddr module to do this better. Let alone in as few lines.
>
> net = ipaddr.IP('192.168.1.0/24'):
> for i in range(253):
> ip = net[i]
> ...
>
> So, that's one example that needs to be added to the docs.
>
> I'd have liked to write that as:
>
> for ip in ipaddr.IP('192.168.1.0/24')[:253]:
> ...
>
> but apparently it doesn't support slicing (time for an RFE :)
Given that what I *want* to do is to skip the "special" cases of 0 and
255, would the following work?
net = ipaddr.IP('192.168.1.101/255.255.255.0') # Note 1
for ip in net:
if ip.ip = ip.broadcast or ip.is_multicast():
continue
...
That would be what I mean by the module helping me to avoid "gotchas"
- like assuming 0 and 255 are the "special" multicast and broadcast
(or whatever they are) addresses that I shouldn't be testing in my
port scanner.
I'd like a .is_broadcast() method. Does that expose my lack of
understanding, or is it a sensible thing to add?
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. Ideally, I'd rather just put my IP address and have the
module work out the "obvious" subnet (at my level of use, it's always
255.255.255.0 for 192.168 addresses) but I guess that's not actually a
well-defined idea.
Paul.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with Py3.1's new ipaddr
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 hosts vs networks, because this issue is important to me; I've been in the network engineering field for over 15 years, worked on Cisco's product development team, and held a CCIE (consider it the equivalent of a CPA for network engineers) for 10 years... Clay seems to object to ipaddr's IP object because it is not the same as the object model used in the BSD ip stack. Indeed, I'm one of the raving fans of what BSD has done for the quality of ip networking, but let's also consider their requirements. BSD must approach ip networking from a host perspective, it is the consumer of individual IP packets and their payloads. ipaddr's whole point of existence is really driven towards the manipulation of potentially massive lists of ip addresses. This is no small difference in requirements, and I believe ipaddr's different approach makes their code much simpler for the tasks it needs to do. Incorporating host addresses as a special case of a /32 IPv4 network or /128 IPv6 network makes a lot of sense to me, in fact, I also chose this same object model. Perl's NetAddr::IP does this too, it is considered the gold standard for perl's address manipulation module. Whether python includes ipaddr now, later, or uses another module entirely does not bother me. Whatever is included should have a very stable API, and major bugs should be worked out. Documentation should be good enough for the average consumer, and if anything this is where ipaddr to be lacking a bit. I hope that python does include something to manipulate IPv4 and IPv6 address blocks in the future, since this is a big hole is python's batteries-included philosophy. However, I'd need more time at the wheel of ipaddr before I could comment whether this truly is ready for inclusion in stdlib. All the best, \m ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Serious regression in doctest in Py3.1rc1
Hello, 2009/6/3 Stefan Behnel : > Hi, > > I can't currently file a bug report on this, but I was told by Lisandro > Dalcín that there is a serious problem with the doctest module in Py3.1rc1. > In Cython, we use doctests to test the compiler in that we compile a > Python/Cython module with doctests into a C module and then run doctest on > the imported extension module. > > >From the error report it seems to me that doctest is now trying to read the > module itself through linecache for some reason, which horribly fails for a > binary module. > > Could someone please look into this? I'll open up a bug report tomorrow > unless someone beats me to it. I don't have the time either, but the problem looks very similar to http://bugs.python.org/issue4050 The fix was to replace: file = inspect.getsourcefile(object) or inspect.getfile(object) was replaced with file = inspect.getsourcefile(object) -- Amaury Forgeot d'Arc ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with Py3.1's new ipaddr
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. Nothing goes into Python 2.7 that isn't already in Python 3.1. -Barry PGP.sig Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with Py3.1's new ipaddr
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 that module is "two times better" than the next highest score of 4 for ipaddresslib. 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 is in the wider community. Also, a module should have to live on its own two feet for while on Cheeseshop before being considered for inclusion in the stdlib. -Barry PGP.sig Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with Py3.1's new ipaddr
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.0.0 /16 = 16 ones followed by 16 zeroes = 255.255.0.0 /24 = 24 ones followed by 8 zeroes = 255.255.255.0 /30 = 30 ones followed by 2 zeroes = 255.255.255.252 /32 = 32 ones followed by no zeroes = 255.255.255.255 It's particularly convenient when you're dividing subnets up into chunks that don't align with a byte boundary in the IPv4 address (e.g. /27 can easily be recognised as giving a subnet containing 2**5 = 32 hosts, but the subnet size is significantly less obvious when written using the equivalent 255.255.255.224 netmask). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Issues with Py3.1's new ipaddr
> 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 works for me and its almost non-existent user base, I assume it can't be used for anything but as a source of ideas. > There is a veritable graveyard of stuff out there! Some good, > some not so good. The fact is that most of the times a programmer writes yet another Python IP module to cover only a very limited and usually simple aspect of IP manipulation that he needs at the given time (a conversion to/from decimal, a check for inclusion in a CIDR, ...) > A sensible discussion from a *broad* base of network admins, > sysadmins and developers using Python on the formulation of a > reasonable functional specification and design for a brand new > library To me, this makes a lot of sense: check which are the most used modules and ask the users. Generically speaking, I tend to agree with Clay, as I always had looked at IP addresses, netmasks and CIDR blocks as separate concepts, but again: I'm not an expert. +++ [1] http://erlug.linux.it/~da/soft/iplib/ Only supports IPv4; its main use is to convert amongst notations, but can be used to check if an IP (or another subnet) is included in a CIDR block and to gather some basic information about a CIDR. -- Davide Alberani [GPG KeyID: 0x465BFD47] http://erlug.linux.it/~da/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with Py3.1's new ipaddr
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 engineering field for over 15 years, worked on Cisco's product development team, and held a CCIE (consider it the equivalent of a CPA for network engineers) for 10 years... Clay seems to object to ipaddr's IP object because it is not the same as the object model used in the BSD ip stack. Indeed, I'm one of the raving fans of what BSD has done for the quality of ip networking, but let's also consider their requirements. BSD must approach ip networking from a host perspective, it is the consumer of individual IP packets and their payloads. ipaddr's whole point of existence is really driven towards the manipulation of potentially massive lists of ip addresses. This is no small difference in requirements, and I believe ipaddr's different approach makes their code much simpler for the tasks it needs to do. Incorporating host addresses as a special case of a /32 IPv4 network or /128 IPv6 network makes a lot of sense to me, in fact, I also chose this same object model. Perl's NetAddr::IP does this too, it is considered the gold standard for perl's address manipulation module. 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 necessary special case. Others deal with host addresses, with networks as an additional data type. 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 package that gets written solves the problems that the particular author(s) needed solved. Since it seems clear that ipaddr does not address the needs of the "other half" of the user base, and that its API considered on its own does have design flaws that would be difficult to fix in a backward compatible fashion (eg: returning strings from __getitem__), I withdraw my support for keeping it in 3.1. --David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with Py3.1's new ipaddr
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 package that gets > written solves the problems that the particular author(s) needed solved. I wonder if part of the problem is the name of the module. Just from "ipaddr", I'd expect it to deal with host addresses (what I think of as an IP address) and would probably approach its use with the wrong expectations. I could see frustration and irritation following from that. If the module was called "networks" instead of "ipaddr", it might help. Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with Py3.1's new ipaddr
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 is in the > wider community. Also, a module should have to live on its own two > feet for while on Cheeseshop before being considered for inclusion in > the stdlib. Better yet would be something like Debian's popularity-contest mechanism (it provides opt-in voting of packages based on what is installed on your machine). popularity-contest runs from a cron job. Maybe when Python is installed it could ask if you want to submit package statistics. If so, installing a package with distutils would submit the name and version number to a central server. If we knew which batteries were most popular we could make sure they are included in the package. ;-) Neil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with Py3.1's new ipaddr
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 >> you can get a rough idea of how generally popular a module is in the >> wider community. Also, a module should have to live on its own two >> feet for while on Cheeseshop before being considered for inclusion in >> the stdlib. > > Better yet would be something like Debian's popularity-contest > mechanism (it provides opt-in voting of packages based on what is > installed on your machine). popularity-contest runs from a cron > job. Maybe when Python is installed it could ask if you want to > submit package statistics. If so, installing a package with > distutils would submit the name and version number to a central > server. > > If we knew which batteries were most popular we could make sure they > are included in the package. ;-) Whoa. Are you all suddenly trying to turn Python into a democracy? I'm outta here if that ever happens (even if I were voted BDFL by a majority :-). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Issues with process and discussions (Re: Issues with Py3.1's new ipaddr)
On 02:39 am, [email protected] 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 recognize a netmask if it bit me in the behind, and I can honestly say that I don't know whether /8 means to look only at the first 8 bits or whether it means to mask off the last 8 bits.) I hope we can learn from this. As he pointed out to Martin, Jean-Paul voiced objections several months ago which are similar to the ones which are now being discussed. To be fair, he didn't unambiguously say "... and therefore don't include this library"; he simply suggested that netaddr was superior in some ways and that perhaps some documentation could illuminate why ipaddr was better. I've been frustrated with similar aspects of Python's development process in the past. The biggest problem I can see is that it's too hard to follow the discussion, and catch oneself up on the discussion thus far. It's also difficult to refer back to posts much earlier in the history of an email discussion, and that frequently needs to be done when someone jumps into the middle of a discussion. The way Twisted dealt with this particular issue was to move *all* discussions relevant to a particular feature into the ticket for that feature. If discussion starts up on the mailing list, within a few messages of it starting, someone on the dev team will pipe up and say "Hey, here's the ticket for this, could you add a link to this discussion and a summary". Once on a ticket, the phraseology and typesetting used by our core team has reached a very precise consensus. Like the feature? "Merge this patch" or "Land this branch". Don't like it? "Thanks for your patch, but:", followed by a list of enumerated feedback. The required reactions to such feedback are equally well understood. Even if a comment isn't a full, formal code review, it still follows a similar style. This system is possibly too simplistic for the more wide-ranging development of Python; although Twisted has its share of enthusiastic discussions, there is rarely the level of controversy I see here on python-dev, so I can't recommend it as such. I can say that keeping ticket discussions on tickets is generally a good idea, though, especially in a system like roundup or trac where it's easy to say "see message 7" rather than repeating yourself. It seems that there is a habit of occasionally using ASF-style +1/+0/-0/-1 markers, but it's inconsistently applied. More importantly, nobody ever actually adds them up, so it's not entirely clear when they should be used. To go back to JP's original comments though: what was the right thing for him to do, back in January, when he had these concerns? Should he have said "I am therefore -1 on this inclusion"? Should he have been discussing this on the mailing list rather than the tracker? Should he have kept coming back to the ticket and answering every single message reinforcing his original conclusions? I honestly don't think it's very clear what one is "officially" supposed to do. Without a clear expectation that one should say "No" to features that are problematic, it seems gratuitously mean to do so; so, it's nicer to just say "here's what I found" with the hopes that someone will evaluate that feedback. Unfortunately it seems like the winning strategy here is just to keep flogging a dead horse until it's a dead horse hamburger; reply and reply and reply until everybody gets sick of talking about it. Repeat your original points in every post so that nobody will miss them. I think everyone is ill-served by this discussion format. Certainly when I voice my own objections or support for something, I'd like to just stop by, add a note for the committers to take into account when considering the issue, and then go away. So, here are my recommendations: 1. Use the tracker for discussing tickets, so that it's easy to refer back to a previous point in the discussion, and so that people working on those tickets can easily find your commentary. 2. Use the mailing list for drawing attention to these discussions if they are of general interest, especially if the discussion is time- critical. In this case, an announcement "You have six weeks to review ipaddr now until its inclusion is permanent, anyone interested please look at issue 3959." 3. If you have an opinion, put your +1/+0/-0/-1 on a line by itself at the top of your message, so that it's easy for newcomers to the discussion to get a general feel. Of course, this won't prevent all meandering discussions, or discussions that are too late to the party, but I do think it will help. However, I think before everyone just starts doing this, even *more* important is my meta-suggestion: let's agree on how and when feedba
Re: [Python-Dev] Issues with Py3.1's new ipaddr
On 02:44 am, [email protected] 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 what I've seen of this discussion so far, I think that cure would at this time be worse than the disease. I thought the solution that I just proposed was pretty obvious ;-). But in all seriousness, even if an improvement looks nothing like what I just proposed, it seems like a simple failure of imagination to say that nothing could make this situation better. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with Py3.1's new ipaddr
On 07:51 am, [email protected] 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 time to participate actively in discussion. 2. Encouraging a clear +1/-1 from people, in addition to discussion on specific points, would clarify things. I believe Martin commented that he hadn't realised that one of the opposing comments was a strong enough objection to count as a -1. +1 :-) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with process and discussions (Re: Issues with Py3.1's new ipaddr)
2009/6/3 : > So, here are my recommendations: > > 1. Use the tracker for discussing tickets, so that it's easy to refer back > to a previous point in the discussion, and so that people working on those > tickets can easily find your commentary. > 2. Use the mailing list for drawing attention to these discussions if they > are of general interest, especially if the discussion is time- critical. In > this case, an announcement "You have six weeks to review ipaddr now until > its inclusion is permanent, anyone interested please look at issue 3959." > 3. If you have an opinion, put your +1/+0/-0/-1 on a line by itself at the > top of your message, so that it's easy for newcomers to the discussion to > get a general feel. Mostly, I agree, but I definitely disagree, I'm afraid, on the use of the tracker for discussions. To keep track of discussions on a ticket, I have to personally keep a list of the tickets I'm interested in, check back regularly to see if there's anything new, and keep a mental note of where I've read up to so I know what's new. RSS would make this simpler, certainly, but I'm not sure about how I'd use it (it's not how I currently use RSS, so I'd have to mess round with my current setup to make it appropriate). Email is delivered to me by default - I get anything new in my python-dev folder, and I can skip or read the discussion as I choose. I don't have to take action just to monitor things. (In other words, the default is for people to see the discussions, rather than the other way around. Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with Py3.1's new ipaddr
On 05:19 pm, [email protected] 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 everything). �Then at least you can get a rough idea of how generally popular a module is in the wider community. �Also, a module should have to live on its own two feet for while on Cheeseshop before being considered for inclusion in the stdlib. Better yet would be something like Debian's popularity-contest mechanism (it provides opt-in voting of packages based on what is installed on your machine). �popularity-contest runs from a cron job. �Maybe when Python is installed it could ask if you want to submit package statistics. �If so, installing a package with distutils would submit the name and version number to a central server. If we knew which batteries were most popular we could make sure they are included in the package. ;-) Whoa. Are you all suddenly trying to turn Python into a democracy? I'm outta here if that ever happens (even if I were voted BDFL by a majority :-). I'm sure that what Barry and Neil are recommending is the same as what I did later: a way to give our most beloved regent accurate data on the populace's current mood. Certainly we wouldn't be discussing our plans for a democratic coup out in the open like this! Clearly, that would be foolish ;-). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with process and discussions (Re: Issues with Py3.1's new ipaddr)
On 05:42 pm, [email protected] wrote: 2009/6/3 : So, here are my recommendations: 1. Use the tracker for discussing tickets, so that it's easy to refer back to a previous point in the discussion, and so that people working on those tickets can easily find your commentary. 2. Use the mailing list for drawing attention to these discussions if they are of general interest, especially if the discussion is time- critical. In this case, an announcement "You have six weeks to review ipaddr now until its inclusion is permanent, anyone interested please look at issue 3959." 3. If you have an opinion, put your +1/+0/-0/-1 on a line by itself at the top of your message, so that it's easy for newcomers to the discussion to get a general feel. Mostly, I agree, but I definitely disagree, I'm afraid, on the use of the tracker for discussions. To keep track of discussions on a ticket, I have to personally keep a list of the tickets I'm interested in, check back regularly to see if there's anything new, and keep a mental note of where I've read up to so I know what's new. RSS would make this simpler, certainly, but I'm not sure about how I'd use it (it's not how I currently use RSS, so I'd have to mess round with my current setup to make it appropriate). Email is delivered to me by default - I get anything new in my python-dev folder, and I can skip or read the discussion as I choose. I don't have to take action just to monitor things. (In other words, the default is for people to see the discussions, rather than the other way around. A good point, but there are a couple of technical solutions to this problem, which, according to http://wiki.python.org/moin/TrackerDocs/, have already been implemented. If you want to get email about new issues, subscribe to new-bugs- [email protected]. If you want to know about every message on every issue, subscribe to [email protected]. But, frankly, I think it's a bad idea to subscribe to python-bugs-list for announcements. The whole point here is that there is simply too much going on in python development for anyone to reasonably keep track of at a low level. Guido himself has complained on numerous occasions of being too busy to monitor things closely. A better model is to subscribe to new-bugs-announce and selectively pay attention to the bugs which are interesting to you; and, when a discussion you're involved in gets interesting and becomes of more general interest, raise it on python-dev. (On the other hand, if you want to subscribe to get your own personal searchable archive, then by all means.) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with Py3.1's new ipaddr
[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 shimmering silmite held aloft Excalibur from the bosom of the water, signifying by divine providence that I, Arthur, was to carry Excalibur. THAT is why I am your king! Dennis interrupting: Listen, strange women lyin' in ponds distributin' swords is no basis for a system of government! Supreme executive power derives from a mandate from the masses, not from some farcical aquatic ceremony! --- Dennis: Oh, but you can't expect to wield supreme executive power just because some watery tart threw a sword at you! --- Dennis: Oh but if I went 'round sayin' I was Emperor, just because some moistened bint lobbed a scimitar at me, they'd put me away! --- Dennis: Help! Help! I'm being oppressed! Violence inherent in the system! Violence inherent in the system! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with Py3.1's new ipaddr
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 necessary special case. Others deal with host addresses, > with networks as an additional data type. It has been brought to my attention that my use of the word "imprecise" may have been construed as an insult. For that I apologize. That was not my intent. I am sure that your understanding of IP in your domain (network engineering) is as good or better than mine in my domain (UNIX administration). That is not the point I was arguing. Had you said that thinking of addresses as having netmasks is a useful mental model, I would have agreed with you wholeheartedly. To me, this is similar to thinking of voltage as pressure. Instead, you said (or at least implied) that addresses in fact do have netmasks, which I think is technically an imprecise way of describing how the technology works. To me, that would be like building a voltmeter calibrated in pascals. As another poster has commented, I think the name of the module is the source of some confusion. While I see the validity of your use case, that is not the use case I had in mind for a module named "ipaddr". In any case, I think with some enhanced documentation and maybe some class name changes, we can clarify ipaddr's API and strive to make it support both use cases. Your continued input will be invaluable as we move forward with the PEP. Clay ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with process and discussions (Re: Issues with Py3.1's new ipaddr)
On Wed, Jun 3, 2009 at 10:41 AM, wrote: > > On 02:39 am, [email protected] 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 recognize a netmask if it bit me >> in the behind, and I can honestly say that I don't know whether /8 >> means to look only at the first 8 bits or whether it means to mask off >> the last 8 bits.) >> >> I hope we can learn from this. > > As he pointed out to Martin, Jean-Paul voiced objections several months ago > which are similar to the ones which are now being discussed. To be fair, he > didn't unambiguously say "... and therefore don't include this library"; he > simply suggested that netaddr was superior in some ways and that perhaps > some documentation could illuminate why ipaddr was better. The thing that stands out about the earlier tracker/mailing list discussions is how very few people affirmatively wanted ipaddr added to the standard library. Most people thought it sounded ok in principle, didn't care, or thought it was not a great idea but didn't feel like arguing about it. -jake ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with process and discussions (Re: Issues with Py3.1's new ipaddr)
In article <20090603181236.12555.1355794514.divmod.xquotient.12...@weber.divmod.com >[email protected] wrote: > If you want to get email about new issues, subscribe to new-bugs- > [email protected]. If you want to know about every message on > every issue, subscribe to [email protected]. > > But, frankly, I think it's a bad idea to subscribe to python-bugs-list > for announcements. The whole point here is that there is simply too > much going on in python development for anyone to reasonably keep track > of at a low level. Guido himself has complained on numerous occasions > of being too busy to monitor things closely. A better model is to > subscribe to new-bugs-announce and selectively pay attention to the bugs > which are interesting to you; and, when a discussion you're involved in > gets interesting and becomes of more general interest, raise it on > python-dev. Another option: if you are more comfortable with managing information flow via usenet newsgroups than via email lists, gmane.org provides mail-to-nntp gateways and archiving of most of the major python mailing lists, including this one, the bugs list, and code checkins. It also supports posting via your news reader, rss feeds, searching, and several web interfaces. http://dir.gmane.org/gmane.comp.python.bugs http://dir.gmane.org/gmane.comp.python.cvs http://dir.gmane.org/gmane.comp.python.devel http://dir.gmane.org/index.php?prefix=gmane.comp.python -- Ned Deily, [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with process and discussions (Re: Issues with Py3.1's new ipaddr)
Paul Moore wrote: 2009/6/3 : So, here are my recommendations: 1. Use the tracker for discussing tickets, so that it's easy to refer back to a previous point in the discussion, and so that people working on those tickets can easily find your commentary. 2. Use the mailing list for drawing attention to these discussions if they are of general interest, especially if the discussion is time- critical. In this case, an announcement "You have six weeks to review ipaddr now until its inclusion is permanent, anyone interested please look at issue 3959." 3. If you have an opinion, put your +1/+0/-0/-1 on a line by itself at the top of your message, so that it's easy for newcomers to the discussion to get a general feel. Mostly, I agree, but I definitely disagree, I'm afraid, on the use of the tracker for discussions. To keep track of discussions on a ticket, I have to personally keep a list of the tickets I'm interested in, check back regularly to see if there's anything new, Not true - if you are added as nosy on a tracker item (which happens when you make a comment or you can do yourself) then you get emailed about new comments. The email contains the body of the comment so you can follow discussions completely by email only going to the tracker to add responses. Michael and keep a mental note of where I've read up to so I know what's new. RSS would make this simpler, certainly, but I'm not sure about how I'd use it (it's not how I currently use RSS, so I'd have to mess round with my current setup to make it appropriate). Email is delivered to me by default - I get anything new in my python-dev folder, and I can skip or read the discussion as I choose. I don't have to take action just to monitor things. (In other words, the default is for people to see the discussions, rather than the other way around. Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with process and discussions (Re: Issues with Py3.1's new ipaddr)
> To go back to JP's original comments though: what was the right thing > for him to do, back in January, when he had these concerns? Should he > have said "I am therefore -1 on this inclusion"? Should he have been > discussing this on the mailing list rather than the tracker? Should he > have kept coming back to the ticket and answering every single message > reinforcing his original conclusions? I honestly don't think it's very > clear what one is "officially" supposed to do. To me, it's fairly clear: what the committer needs to get is guidance in any action to take. In most cases, the set of possible actions comes down to three: a) reject-as-is b) commit-as-is c) commit-with-changes (specify changes to make) [d) take no action at this point, until certain preconditions are met] For d), it is common to request, to the submitter, resubmit-with-changes, then the code needs to be reevaluated when the submitter claims to have implemented the requested changes. In the specific case, JP didn't propose an action to take, hence it wasn't clear (to me) whom his comment was directed to; I understood it as "the module has these minor flaws, they should be fixed at some point", which means "commit, then change later". This is what happened. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with process and discussions (Re: Issues with Py3.1's new ipaddr)
> The thing that stands out about the earlier tracker/mailing list > discussions is how very few people affirmatively wanted ipaddr added > to the standard library. Most people thought it sounded ok in > principle, didn't care, or thought it was not a great idea but didn't > feel like arguing about it. I specifically thought "manipulating IP addresses is a frequent task, and probably everybody's requirements will be different. So starting with this library is as good as starting with any other - we can add use cases as we go". I was in favor of ipaddr because his author offered to maintain it. I then didn't have the time to review it myself, and was happy that others picked it up. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with process and discussions (Re: Issues with Py3.1's new ipaddr)
On Wed, Jun 3, 2009 at 2:56 PM, Michael Foord wrote: > Paul Moore wrote: >> >> 2009/6/3 : >> >>> >>> So, here are my recommendations: >>> >>> 1. Use the tracker for discussing tickets, so that it's easy to refer >>> back >>> to a previous point in the discussion, and so that people working on >>> those >>> tickets can easily find your commentary. >>> 2. Use the mailing list for drawing attention to these discussions if >>> they >>> are of general interest, especially if the discussion is time- critical. >>> In >>> this case, an announcement "You have six weeks to review ipaddr now until >>> its inclusion is permanent, anyone interested please look at issue 3959." >>> 3. If you have an opinion, put your +1/+0/-0/-1 on a line by itself at >>> the >>> top of your message, so that it's easy for newcomers to the discussion to >>> get a general feel. >>> >> >> Mostly, I agree, but I definitely disagree, I'm afraid, on the use of >> the tracker for discussions. To keep track of discussions on a ticket, >> I have to personally keep a list of the tickets I'm interested in, >> check back regularly to see if there's anything new, > > Not true - if you are added as nosy on a tracker item (which happens when > you make a comment or you can do yourself) then you get emailed about new > comments. The email contains the body of the comment so you can follow > discussions completely by email only going to the tracker to add responses. > > Michael > You can also directly reply to tracker issues via email, which is how I do most of my responses. It's cool. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with process and discussions (Re: Issues with Py3.1's new ipaddr)
> Not true - if you are added as nosy on a tracker item (which happens > when you make a comment or you can do yourself) then you get emailed > about new comments. The email contains the body of the comment so you > can follow discussions completely by email only going to the tracker to > add responses. Actually, one of roundup's big advantages over many competitors is that you can also respond by email; many contributors actually do that. You only have to remember that this isn't really email, so you can usually omit salute and signature. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with process and discussions (Re: Issues with Py3.1's new ipaddr)
[email protected] wrote: So, here are my recommendations: 1. Use the tracker for discussing tickets, so that it's easy to refer back to a previous point in the discussion, and so that people working on those tickets can easily find your commentary. 2. Use the mailing list for drawing attention to these discussions if they are of general interest, especially if the discussion is time- critical. In this case, an announcement "You have six weeks to review ipaddr now until its inclusion is permanent, anyone interested please look at issue 3959." 3. If you have an opinion, put your +1/+0/-0/-1 on a line by itself at the top of your message, so that it's easy for newcomers to the discussion to get a general feel. I watched and was greatly impressed by the video demo of Google's new Wave collaborative communication system. I believe it would/will help with some of the chronic problems we (and others) have. Someone already added a click-on Yes/No/Maybe client-side widget (for group outings) that tabulates on the wave who made each vote, with votes changeable. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with process and discussions (Re: Issues with Py3.1's new ipaddr)
Terry Reedy udel.edu> writes: > > I watched and was greatly impressed by the video demo of Google's new > Wave collaborative communication system. I believe it would/will help > with some of the chronic problems we (and others) have. I really don't think technical systems are an answer to social issues. It's a flaw of the engineering mindset. (even when there's "Google" engraved on it ;-)) cheers Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with Py3.1's new ipaddr
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 do the right thing before releasing 3.1 final.) > > As Raymond and Gregory have pointed out in this thread, the library is > quite independent as it stands now in the stlib, so should be trivial > to remove. Nothing else should be affected. Don't forget the what's new :) Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with Py3.1's new ipaddr
[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 Peterson] As Raymond and Gregory have pointed out in this thread, the library is quite independent as it stands now in the stlib, so should be trivial to remove. Nothing else should be affected. Guido, have you made a firm decision to remove ipaddr.py from 3.1? The guys on IRC are chomping at the bit. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with Py3.1's new ipaddr
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 we can be sure to do the right thing before releasing 3.1 final.) > > [Benjamin Peterson] >>> >>> As Raymond and Gregory have pointed out in this thread, the library is >>> quite independent as it stands now in the stlib, so should be trivial >>> to remove. Nothing else should be affected. > > Guido, have you made a firm decision to remove ipaddr.py from 3.1? > The guys on IRC are chomping at the bit. I don't make firm decisions any more (this is something that comes with old age). Let them remove it. If it means Python will never have such functionality, because the users can't agree on the correct semantic model, so be it. It's pretty advanced stuff, some people are happy to write their own based on the RFCs, others will gladly download one of the existing contenders (ipaddr included). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Google Wave as a developer communication tool (was: Issues with process and discussions (Re: Issues with Py3.1's new ipaddr))
Terry Reedy writes: > I watched and was greatly impressed by the video demo of Google's new > Wave collaborative communication system. I believe it would/will help > with some of the chronic problems we (and others) have. I watched that too. It appears to be heavily reliant on *very* fast internet access for participants in a wave. That's far from universal in the Python community, let alone the internet at large. It also appears to be heavily reliant on the wave's existence at a single point of failure (the hosting server): if that one point becomes unreliable, all participants are hosed. Neither of these problems exist with email (or NNTP). -- \ “Well, my brother says Hello. So, hooray for speech therapy.” | `\ —Emo Philips | _o__) | Ben Finney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Google Wave as a developer communication tool (was: Issues with process and discussions (Re: Issues with Py3.1's new ipaddr))
Ben Finney wrote: > Terry Reedy writes: > > > I watched and was greatly impressed by the video demo of Google's new > > Wave collaborative communication system. I believe it would/will help > > with some of the chronic problems we (and others) have. > > I watched that too. It appears to be heavily reliant on *very* fast > internet access for participants in a wave. That's far from universal in > the Python community, let alone the internet at large. And on HTML 5. Those of us using IE might be hosed, but perhaps Python developers all use Firefox? (I use Camino.) > It also appears to be heavily reliant on the wave's existence at a > single point of failure (the hosting server): if that one point becomes > unreliable, all participants are hosed. Well, they've got this server synchronization protocol. Might mitigate both problems. I'm thinking about building a Python Wave server to run in UpLib, if I can find the time. Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with process and discussions (Re: Issues with Py3.1's new ipaddr)
Michael Foord wrote: if you are added as nosy on a tracker item (which happens when you make a comment or you can do yourself) then you get emailed about new comments. That's good, but... only going to the tracker to add responses. is not so good. If the goal is to ensure that all previous discussion on a given issue is reliably recorded, then email replies ought to be archived under the relevant ticket automatically. For me at least, having to go somewhere special to post a reply would be too error-prone. I get a large number of Python-related messages in my inbox from a number of sources, and I don't usually pay much attention to exactly where they're coming from. I just hit reply-all and trust that it will go somewhere sensible. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with process and discussions (Re: Issues with Py3.1's new ipaddr)
Antoine Pitrou writes: > Terry Reedy udel.edu> writes: > > > > I watched and was greatly impressed by the video demo of Google's new > > Wave collaborative communication system. I believe it would/will help > > with some of the chronic problems we (and others) have. > > I really don't think technical systems are an answer to social > issues. It's a flaw of the engineering mindset. That depends on the definition of "problem". For example, if the problem is "half our people detest web interfaces and want to discuss issues by email", then "Roundup: nosy list" *is* a technical system that is an answer. I agree that Terry wasn't particularly specific about what impressed him and how it would help for what problem. But rather than just say "technology is not a universal answer", we should ask "what problem does this address?" (Personally, I'm satisfied from the example Terry gave that he had the "summarizing the opinions of those whose opinions we respect in this domain" problem in mind, and I think there *are* technical solutions to that. Terry?) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with process and discussions (Re: Issues with Py3.1's new ipaddr)
On Thu, 4 Jun 2009 at 12:23, Greg Ewing wrote: Michael Foord wrote: if you are added as nosy on a tracker item (which happens when you make a comment or you can do yourself) then you get emailed about new comments. That's good, but... only going to the tracker to add responses. is not so good. If the goal is to ensure that all previous discussion on a given issue is reliably recorded, then email replies ought to be archived under the relevant ticket automatically. As Martin sad, replies work. Michael was mistaken in thinking you have to go to the tracker to post a followup (I initially did not know I could just hit reply either). You can even open new tickets via email, but I've never tried that. --David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues with process and discussions (Re: Issues with Py3.1's new ipaddr)
On 3 Jun, 07:08 pm, [email protected] wrote: To go back to JP's original comments though: what was the right thing for him to do, back in January, when he had these concerns? To me, it's fairly clear: what the committer needs to get is guidance in any action to take. In most cases, the set of possible actions comes down to three: a) reject-as-is b) commit-as-is c) commit-with-changes (specify changes to make) [d) take no action at this point, until certain preconditions are met] For d), it is common to request, to the submitter, resubmit-with-changes, then the code needs to be reevaluated when the submitter claims to have implemented the requested changes. Is there a document which lists these things, and explains how it is desirable to communicate them? I recently updated Twisted's equivalent document, adding minutae like which buttons to click on in our issue tracker, since that seems obvious to me but apparently wasn't obvious to a lot of new contributors. In the specific case, JP didn't propose an action to take, hence it wasn't clear (to me) whom his comment was directed to; I understood it as "the module has these minor flaws, they should be fixed at some point", which means "commit, then change later". This is what happened. My reading of it suggests that he was saying "netaddr appears to be superior in every way, so python should include that instead. But, if someone is insisting on ipaddr here are the things that could change about it". The important thing here is that interpretation of the comment is required, so I can definitely see how you saw it the way you did. There is no "-1" in his comment, and there's no documentation (that I'm aware of) which says that a "-1" is required, or how it will be used or interpreted. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Google Wave as a developer communication tool
Ben Finney wrote: Terry Reedy writes: I watched and was greatly impressed by the video demo of Google's new Wave collaborative communication system. I believe it would/will help with some of the chronic problems we (and others) have. Example: if PEPs were waves, then responses could either be entered as live edits (with permission) or comments immediately following the relevant text (as with email/newsgroups) visible to all. Much easier than current situation. Edits are marked in red shading for those who have previously seen document. Many have complained that it is hard to read multiple versions of a PEP since so much is new and there is no indication of what is new to the particular reader. I watched that too. It appears to be heavily reliant on *very* fast internet access for participants in a wave. That's far from universal in the Python community, let alone the internet at large. Even a slow connection would make participation in PEPs better than today. And being able to get a version of the docs that hi-lites "what's new for you" would also be very nice. It also appears to be heavily reliant on the wave's existence at a single point of failure (the hosting server): if that one point becomes unreliable, all participants are hosed. We have that problem already with the tracker, which does occasionally go down for a bit. And the svn host? (One reason to move to distributed system.) Neither of these problems exist with email (or NNTP). But do for an email list, like this one. Or a wiki. Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
