Issues with Py3.1's new ipaddr
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 are also the authors of the library, it is not surprising that the library enjoys "extensive real-life use." The real test of a library is not how well it succeeds at one installation, but how well it meets the needs of the larger user base. Having read the code and the author's comments, it seems to me that networking concepts not employed at Google have been neglected. While some of these features are easily added to ipaddr, their omission exposes a narrow view of the problem domain that has resulted in more fundamental problems in the library, such as the conflation of addresses and networks.
I think we should just stick to "sorry, too late, try again for 3.2". We've done that with plenty of more important flaws that were discovered on the verge of a release, and I don't recall ever regretting it. We can always add more features to the module in 3.2.
My concerns are not so much about adding features as they are about changing the API. Addressing the concerns that I and others have raised requires making backwards-incompatible changes. Doing that now, before ipaddr enjoys widespread deployment as part of the stdlib, seems prudent. Removing ipaddr from 3.1 appears to me less painful than fixing apps when ipaddr's API changes in 3.2. 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? Until a satisfactory library is available for inclusion in the stdlib, the few developers that do require such functionality can easily enough download a library that meets their needs. Clay
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 remove the library, except if a severe problem was uncovered - which you haven't been able to demonstrate. I don't believe that your issue "hosts and nets are represented with the same class" is severe: it is very well possible to use the IP function to represent individual hosts (including having a string representation that doesn't print a netmask). The only possibly-missing feature is support for rejecting host strings that include a mask on parsing; that can be added in a backwards-compatible way as an optional parameter to the IP function (as discussed on the tracker). Regards, Martin
On Tue, Jun 2, 2009 at 1:47 AM, "Martin v. Löwis" <martin@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 this question a few month ago. Now, release mechanics make it difficult to remove the library, except if a severe problem was uncovered - which you haven't been able to demonstrate.
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. I've actually provided several examples of where the library fails when used in common scenarios, yet your solution involves incremental hacks that don't fix the underlying problems. You write as if you have a vested interest in releasing the library -- why?
I don't believe that your issue "hosts and nets are represented with the same class" is severe: it is very well possible to use the IP function to represent individual hosts (including having a string representation that doesn't print a netmask). The only possibly-missing feature is support for rejecting host strings that include a mask on parsing; that can be added in a backwards-compatible way as an optional parameter to the IP function (as discussed on the tracker).
There are other missing features, but again, my concern is not about missing features: it's about a quirky API that conflates concepts in the problem domain, leading to subtle bugs and breaking the principle of least surprise. Clay
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, but then what we have wouldn't really be a release candidate anymore, so the release would get delayed.
I've actually provided several examples of where the library fails when used in common scenarios, yet your solution involves incremental hacks that don't fix the underlying problems. You write as if you have a vested interest in releasing the library -- why?
I have a vested interest in releasing Python 3.1, and in sticking to decisions that have been made by other committers. I trust these fellow committers, so I defend their decisions. I personally have no plans for using this library, or any other IP address library (at least not in any application I plan to write soon). At the moment, I'm struggling more with IP address libraries in Perl.
There are other missing features, but again, my concern is not about missing features: it's about a quirky API that conflates concepts in the problem domain, leading to subtle bugs and breaking the principle of least surprise.
I believe the API appears more quirky to you than it actually is, probably because you don't have understood it fully (but I might be wrong with that, and there might be a different reason). Regards, Martin
On Tue, Jun 2, 2009 at 2:15 AM, "Martin v. Löwis" <martin@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 exception could be made in this case, given that you have admitted that ipaddr is not an important library. The chances of a problem being introduced due to its removal are vanishingly small. No other components of the stdlib depend on ipaddr, and the few (approximately zero?) developers who will have started writing applications depending on ipaddr due to its inclusion in the release candidate could simply download the library from Google.
I believe the API appears more quirky to you than it actually is, probably because you don't have understood it fully (but I might be wrong with that, and there might be a different reason).
I believe the API is quirky because: * It tries to represent distinct domain model concepts in a single class * Its methods and properties are strangely named * Methods and properties that should return domain model objects return native types instead * It cannot correctly parse output from netstat, nor can it correctly pass values to ifconfig 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. If you consult the issue notes, you'll see objections of the type I just mentioned were raised months ago, yet no work has been done to correct them. The only changes that I can see were related to pedantic style issues: camel case and indentation. Clay
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 be made in this case, given that you have admitted that ipaddr is not an important library.
This would be need to be decided by the release manager. However, given that Guido has already pronounced on this issue, Benjamin is unlikely to change anything.
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 hear a public outcry - only a single complainer. Regards, Martin
On Tue, 02 Jun 2009 19:34:11 +0200, "\"Martin v. Löwis\"" <martin@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 ignored.
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 attempts Clay has made to point them out. I don't have time to argue this issue, but I agree with essentially everything Clay has said in this thread, and I commented about these problems on the ticket months ago, before ipaddr was added. Jean-Paul
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 remark] I had seen objections from Victor Stinner, which I did not fully understand, but he seemed to be saying that he is ok with including ipaddr. I had also seen objections from David Moss, which he then seems to have withdrawn. I did not take your message (msg78675 in the tracker) as an objection - you just seemed to express a preference to use netaddr instead. You said it had minor quirks, and some of them have to be removed - but I would not infer that the library should be exclude because of these minor quirks.
I don't have time to argue this issue, but I agree with essentially everything Clay has said in this thread, and I commented about these problems on the ticket months ago, before ipaddr was added.
I now understand (but honestly didn't understand before) that you are objecting to ipaddr's inclusion, and that you would prefer its removal at this point. Regards, Martin
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\"" <martin@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 ignored.
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 attempts Clay has made to point them out.
I don't have time to argue this issue, but I agree with essentially everything Clay has said in this thread, and I commented about these problems on the ticket months ago, before ipaddr was added.
Indeed... "Me too" - I've been quietly concerned with these issues, but have have not said anything as Clay's postings pretty much cover it (and swine flu response is trumping all my other priorities).
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 this point. 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.) 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. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Tue, Jun 2, 2009 at 7:39 PM, Guido van Rossum <guido@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 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.
Yep, thats a fair summary. Removal will be trivial. 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?
2009/6/2 Gregory P. Smith <greg@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 is not a good place for a module pending uncertain, future changes. -- Regards, Benjamin
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
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. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ my-python-code-runs-5x-faster-this-month-thanks-to-dumping-$2K- on-a-new-machine-ly y'rs - tim
2009/6/2 Aahz <aahz@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 I've seen of this discussion so far, I think that cure would at this time be worse than the disease.
I don't think he's suggesting adding more process yet, just in the diagnosis phase. -- Regards, Benjamin
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 A couple of people commented that they didn't say anything because they were really busy. I don't think there's much you can do about that, unless the time machine can be used to unmutate the swine flu! FWIW I also agree with Martin's assessment of the thread in the tracker that it looked like there was only one person strongly opposed. Mostly an unfortunate combination of circumstances. 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.
2009/6/3 Stephen J. Turnbull <stephen@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 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.
On 07:51 am, p.f.moore@gmail.com wrote:
2009/6/3 Stephen J. Turnbull <stephen@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 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 :-)
On 02:44 am, aahz@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 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.
2009/6/2 Guido van Rossum <guido@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 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. -- Regards, Benjamin
Benjamin Peterson schrieb:
2009/6/2 Guido van Rossum <guido@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 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
[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
On Wed, Jun 3, 2009 at 2:58 PM, Raymond Hettinger <python@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 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/)
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 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.
When including third-party modules into the standard library, we've generally only included them after they have broad acceptance in the community. In this case, however, it seems that while the ipaddr module had acceptance within Google, it had not had much exposure to the broader python community. I think if anyone other than Guido had proposed adding the module to the standard library, we would not have even considered it until it had spent some time standing on it's own two feet.
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
Barry Warsaw <barry@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 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
On Wed, Jun 3, 2009 at 10:13 AM, Neil Schemenauer <nas@arctrix.com> wrote:
Barry Warsaw <barry@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 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/)
[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!
On 05:19 pm, guido@python.org wrote:
On Wed, Jun 3, 2009 at 10:13 AM, Neil Schemenauer <nas@arctrix.com> wrote:
Barry Warsaw <barry@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 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 ;-).
On 02:39 am, guido@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 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 feedback is useful, and when it will be considered, so that it's not just a contest to overflow Guido's inbox. The opinion of the committers who will be considering feedback is much more important than mine :).
2009/6/3 <glyph@divmod.com>:
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.
On 05:42 pm, p.f.moore@gmail.com wrote:
2009/6/3 <glyph@divmod.com>:
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- announce@mail.python.org. If you want to know about every message on every issue, subscribe to python-bugs-list@mail.python.org. 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.)
In article <20090603181236.12555.1355794514.divmod.xquotient.12321@weber.divmod.com
glyph@divmod.com wrote: If you want to get email about new issues, subscribe to new-bugs- announce@mail.python.org. If you want to know about every message on every issue, subscribe to python-bugs-list@mail.python.org.
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, nad@acm.org
Paul Moore wrote:
2009/6/3 <glyph@divmod.com>:
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.u...
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog
On Wed, Jun 3, 2009 at 2:56 PM, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
Paul Moore wrote:
2009/6/3 <glyph@divmod.com>:
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.
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
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
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
Paul Moore wrote:
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.
Others have already noted that Roundup not only emails you with new comments, but also lets you reply via email. That happens for anyone on the nosy list for an issue (commenting on an issue automatically adds you to the nosy list). In addition, you can fairly easily create a saved query to show you all the open tickets that you are on the nosy list for. (Although I created and saved my query for that so long ago that I don't recall the exact details on how to go about doing that). Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
2009/6/4 Nick Coghlan <ncoghlan@gmail.com>:
Paul Moore wrote:
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.
Others have already noted that Roundup not only emails you with new comments, but also lets you reply via email. That happens for anyone on the nosy list for an issue (commenting on an issue automatically adds you to the nosy list).
In addition, you can fairly easily create a saved query to show you all the open tickets that you are on the nosy list for. (Although I created and saved my query for that so long ago that I don't recall the exact details on how to go about doing that).
Agreed, and thanks to all for the pointers to features I wasn't aware of. I could still argue that there are downsides (need to take action to set myself as nosy on an issue, possibly setting up a new mail filter, housekeeping cruft, the fact that people don't quote in the same way on tracker items) that make tracker discussions less attractive to me, but it's very personal things. Let's leave it as merely that I wouldn't have contributed to the ipaddr discussion if it had been solely on the tracker (not even if pointers to and reminders of the tracker item were posted to python-dev). My input wasn't very valuable, so maybe that doesn't matter much. Maybe the key point is that keeping discussion on the tracker introduces a barrier to participation by lurkers, FWIW. Paul.
On Thu, Jun 4, 2009 at 6:20 AM, Paul Moore <p.f.moore@gmail.com> wrote: ...
I could still argue that there are downsides (need to take action to set myself as nosy on an issue, possibly setting up a new mail filter, housekeeping cruft, the fact that people don't quote in the same way on tracker items) that make tracker discussions less attractive to me, but it's very personal things.
How hard would it be to set up a bot that will subscribe to python-dev and archive messages that have [issueXXXX] in the subject under appropriate roundup ticket? This way if discussion started on roundup, it would only take adding python-dev in CC to bring it to the larger python-dev audience and adding issue number to the python-dev thread subject will be all it takes to archive new messages on roundup. This would not solve a problem of linking threads that start on python-dev before a ticket is opened, but with some proper conventions this problem can be solved as well.
On Thu, Jun 04, 2009 at 11:03:22AM -0400, Alexander Belopolsky wrote: -> On Thu, Jun 4, 2009 at 6:20 AM, Paul Moore <p.f.moore@gmail.com> wrote: -> ... -> > I could still argue that there are downsides (need to take action to -> > set myself as nosy on an issue, possibly setting up a new mail filter, -> > housekeeping cruft, the fact that people don't quote in the same way -> > on tracker items) that make tracker discussions less attractive to me, -> > but it's very personal things. -> -> How hard would it be to set up a bot that will subscribe to python-dev -> and archive messages that have [issueXXXX] in the subject under -> appropriate roundup ticket? This way if discussion started on -> roundup, it would only take adding python-dev in CC to bring it to the -> larger python-dev audience and adding issue number to the python-dev -> thread subject will be all it takes to archive new messages on -> roundup. This would not solve a problem of linking threads that start -> on python-dev before a ticket is opened, but with some proper -> conventions this problem can be solved as well. In my experience this kind automated stuff is too fragile to work reliably & specifically over time, which is what we would want -- "fire and forget". Is there a good python-dev archive search mechanism (other than to google "python-dev <term>" ;) out there? Wouldn't that help? cheers, --titus -- C. Titus Brown, ctb@msu.edu
Alternatively, one could create a python-dev profile on roundup and encourage people to add python-dev to the nosy list when discussion needs to be broaden. This way replies to all will be posted in both places. Once discussion gets too specialized, someone can remove python-dev from the "nosies." No new code is required to set this up as far as I can tell. On Thu, Jun 4, 2009 at 11:08 AM, C. Titus Brown <ctb@msu.edu> wrote:
On Thu, Jun 04, 2009 at 11:03:22AM -0400, Alexander Belopolsky wrote: -> On Thu, Jun 4, 2009 at 6:20 AM, Paul Moore <p.f.moore@gmail.com> wrote: -> ... -> > I could still argue that there are downsides (need to take action to -> > set myself as nosy on an issue, possibly setting up a new mail filter, -> > housekeeping cruft, the fact that people don't quote in the same way -> > on tracker items) that make tracker discussions less attractive to me, -> > but it's very personal things. -> -> How hard would it be to set up a bot that will subscribe to python-dev -> and archive messages that have [issueXXXX] in the subject under -> appropriate roundup ticket? This way if discussion started on -> roundup, it would only take adding python-dev in CC to bring it to the -> larger python-dev audience and adding issue number to the python-dev -> thread subject will be all it takes to archive new messages on -> roundup. This would not solve a problem of linking threads that start -> on python-dev before a ticket is opened, but with some proper -> conventions this problem can be solved as well.
In my experience this kind automated stuff is too fragile to work reliably & specifically over time, which is what we would want -- "fire and forget".
Is there a good python-dev archive search mechanism (other than to google "python-dev <term>" ;) out there? Wouldn't that help?
cheers, --titus -- C. Titus Brown, ctb@msu.edu
Alexander Belopolsky wrote:
Alternatively, one could create a python-dev profile on roundup and encourage people to add python-dev to the nosy list when discussion needs to be broaden. This way replies to all will be posted in both places. Once discussion gets too specialized, someone can remove python-dev from the "nosies." No new code is required to set this up as far as I can tell.
That would certainly be possible. I'm not sure whether it *should* be done, though. If anybody actually wants that feature, please create a ticket in the meta tracker. Regards, Martin
On Thu, Jun 4, 2009 at 5:08 PM, C. Titus Brown <ctb@msu.edu> wrote:
In my experience this kind automated stuff is too fragile to work reliably & specifically over time, which is what we would want -- "fire and forget".
You could a python-dev account in the tracker and allow people to nosy it.
Is there a good python-dev archive search mechanism (other than to google "python-dev <term>" ;) out there? Wouldn't that help?
Like http://python.markmail.org/? Cheers, Dirkjan
Is there a good python-dev archive search mechanism (other than to google "python-dev <term>" ;) out there? Wouldn't that help?
I would add site:mail.python.org into the google query, but apart from that: what's wrong with google search? Regards, Martin
On Thu, Jun 04, 2009 at 05:54:23PM +0200, "Martin v. L?wis" wrote: -> > Is there a good python-dev archive search mechanism (other than to -> > google "python-dev <term>" ;) out there? Wouldn't that help? -> -> I would add site:mail.python.org into the google query, but apart from -> that: what's wrong with google search? It generally points you towards the right messages in the python-dev archives, but those are kept by month and the threading doesn't always work well. Sometimes conversations span many months, and threading can be an immense help for understanding the discussion. Something like MarkMail (as Dirkjan mentioned) may have a better interface. I'll give it a try. thanks, --titus -- C. Titus Brown, ctb@msu.edu
In article <20090604173400.GB25702@idyll.org>, "C. Titus Brown" <ctb@msu.edu> wrote:
Something like MarkMail (as Dirkjan mentioned) may have a better interface. I'll give it a try.
Or http://search.gmane.org/ with group gmane.comp.python.devel -- Ned Deily, nad@acm.org
In addition, you can fairly easily create a saved query to show you all the open tickets that you are on the nosy list for. (Although I created and saved my query for that so long ago that I don't recall the exact details on how to go about doing that).
It's fairly easy. Start a search, put your account name into "Nosy list member", and put "My nosy" (or some such) into "Query name**". Then hit search, and watch "My nosy" appear under "Your queries". Regards, Martin
Martin v. Löwis wrote:
In addition, you can fairly easily create a saved query to show you all the open tickets that you are on the nosy list for. (Although I created and saved my query for that so long ago that I don't recall the exact details on how to go about doing that).
It's fairly easy. Start a search, put your account name into "Nosy list member", and put "My nosy" (or some such) into "Query name**". Then hit search, and watch "My nosy" appear under "Your queries".
Done. Wow. Thanks. tjr
On Wed, Jun 3, 2009 at 10:41 AM, <glyph@divmod.com> wrote:
On 02:39 am, guido@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 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
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
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
On 3 Jun, 07:08 pm, martin@v.loewis.de 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.
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.
I'm not quite sure whether this is what you are asking for, but there is http://www.python.org/dev/workflow/
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.
Well, there is http://www.python.org/dev/peps/pep-0010/ I personally use them sometimes, but wouldn't insist on others using them. Regards, Martin
glyph@divmod.com 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.
Terry Reedy <tjreedy <at> 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.
Antoine Pitrou writes:
Terry Reedy <tjreedy <at> 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?)
Stephen J. Turnbull wrote:
Antoine Pitrou writes:
Terry Reedy <tjreedy <at> 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.
Well, its true that telephones did not cure people of dishonesty, but it did make communication-at-a-distance, truthful or otherwise, easier.
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.
And for me, it is very helpful.
I agree that Terry wasn't particularly specific about what impressed him and how it would help for what problem.
Right. A quick three lines plus a few more. There were several things that Wave brings together. I will suggest specific experiments when it is actually available for use.
But rather than just say "technology is not a universal answer", we should ask "what problem does this address?"
As I said in my response to Ben Finney, two problems addressed are 1. Reading a document that has been edited since you read it last. The old method of in-place deltas -- typically strikeout for deletions and some other special marking for additions -- has stood that test of time. Many word processors do this, but Waves improve on them by individualizing the markings for the particular reader and then removing them once read. 2. Multiple people editing a document. One solution is the "You're it" method, whether informal by passing a doc around either on paper or electronicly or formal by VCS checkout. Another is edit in isolation, merge, and resolve conflicts. Waves allow real-time simultaneous editing and merging via micro-deltas, so conflicts are immediately apparent. This would generally work better with text docs than with code, which needs to be frequently frozen to run, but code might even be workable for side-by-side pair or sprint programming.
(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?)
The current 'summarize opinion' system is somewhat haphazard and informal, with no auto-tabulation. It seems to have broken-down a bit for the ipaddr issue, at least until the last few days when the best solution was to remove and defer. Better would have been either not add and defer or add with generally supported revision. I speculate that if there had been a proto-pep wave (though not then possible) with a vote widget with buttons such as Accept as is, Probably accept after revision, Don't know, and Reject, we might have reached a better outcome sooner. Terry Jan Reedy
Terry Reedy <tjreedy@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 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
Ben Finney <ben+python@benfinney.id.au> wrote:
Terry Reedy <tjreedy@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 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
Ben Finney wrote:
Terry Reedy <tjreedy@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.
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
Terry Reedy <tjreedy@udel.edu> writes:
Ben Finney wrote:
I watched [the Google Wave presentation] 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.
How can you know that? A slow link doesn't punish email or NNTP communication the way an interactive web application does. Why would Google Wave be any less punitive to low-bandwidth users than existing live web applications? I would not want to put money against Google technologists giving lower priority to the needs of the majority of internet users without fast connections.
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.)
Right. These are all reasons for moving toward distributed systems; Python has chosen to do so already with its VCS. Why would the choice of a new communications technology not take this into consideration?
Neither of these problems exist with email (or NNTP).
But do for an email list, like this one. Or a wiki.
No. None of mailing list, NNTP, or wiki are heavily punitive to low-bandwidth links. -- \ “Creativity can be a social contribution, but only in so far as | `\ society is free to use the results.” —Richard Stallman | _o__) | Ben Finney
Ben Finney <ben+python@benfinney.id.au> writes:
Terry Reedy <tjreedy@udel.edu> writes:
Even a slow connection would make participation in PEPs better than today.
How can you know that? A slow link doesn't punish email or NNTP communication the way an interactive web application does.
Strike that; reverse it. Should be “A slow link is not punished by email or NNTP communication the way it is by an interactive web application”. -- \ “I went over to the neighbor's and asked to borrow a cup of | `\ salt. ‘What are you making?’ ‘A salt lick.’” —Steven Wright | _o__) | Ben Finney
Ben Finney wrote:
Terry Reedy <tjreedy@udel.edu> writes:
Ben Finney wrote:
I watched [the Google Wave presentation] 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.
How can you know that? A slow link doesn't punish email or NNTP communication the way an interactive web application does. Why would Google Wave be any less punitive to low-bandwidth users than existing live web applications?
I am not sure of what 'live web application' you have in mind to compare to ;-). A general answer is text stream versus binary blob stream. A wave is more like a souped-up mailing-list or newsgroup thread or wiki page than an online game. You open your wave client and PEPxxx.wave is marked as having new content. At your leisure, you open it (or perhaps you have marked it 'download updates in background'). That that takes longer with a slow connection is no different than with other text streams. If you type in a comment, even 1200 baud upsteam is fast enough. Where do you get 'punitive' in this?
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.)
Right. These are all reasons for moving toward distributed systems; Python has chosen to do so already with its VCS. Why would the choice of a new communications technology not take this into consideration?
It should. The wave protocol includes server-to-server mirroring. A wave can be shared across multiple servers.
Neither of these problems exist with email (or NNTP). But do for an email list, like this one. Or a wiki.
The second of 'these problems' was 'single point of failure'. That *can* apply to email and wiki.
No. None of mailing list, NNTP, or wiki are heavily punitive to low-bandwidth links.
I would not expect that to be much more true of a text-only wave. It is binary content (and embeded ad links) that made broadband really necessary for web surfing. Terry Jan Reedy
On Thu, Jun 04, 2009 at 01:15:16PM -0400, Terry Reedy wrote:
marked as having new content. At your leisure, you open it (or perhaps you have marked it 'download updates in background'). That that takes longer with a slow connection is no different than with other text streams. If you type in a comment, even 1200 baud upsteam is fast enough. Where do you get 'punitive' in this?
I visited my parents at Christmas. They live in a rural area, don't have great phone lines, and my dad's computer ends up getting about a 21Kb modem connection (not even 38.4!). I discovered that great swaths of the Web 2.0 world were effectively unusable for me; after login, the Twitter home page took 3 minutes to display. Logging into my bank was a tortuous 10 minute process. I never succeeded in getting into Facebook at all. Many pages don't render until they're completely downloaded. The little AJAXy update that adds an extra second or two on a fast connection becomes shockingly painful on a slow connection. The JS files are organized Unless Google Wave is written with attention to such slow connections (which I doubt -- such users are pretty rare, after all), I would assume it will be unusable. The bandwidth is enough for a character by character stream, but web browser apps impose many overheads atop that stream. --amk
Google Wave is also still in tightly restricted beta. Gmail went through a long invite-only period. Until we have an idea of how long it will be until basically all python developers who want a Wave account can get one, it doesn't make sense to talk about using it for python development, IMO. -jake
On Thu, Jun 04, 2009, Terry Reedy wrote:
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.
It sounds like Wave requires a high-powered browser, similar to Google Maps. That makes me -1 because I want to continue using Lynx. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "Given that C++ has pointers and typecasts, it's really hard to have a serious conversation about type safety with a C++ programmer and keep a straight face. It's kind of like having a guy who juggles chainsaws wearing body armor arguing with a guy who juggles rubber chickens wearing a T-shirt about who's in more danger." --Roy Smith, c.l.py, 2004.05.23
Aahz <aahz@pythoncraft.com> writes:
It sounds like Wave requires a high-powered browser, similar to Google Maps. That makes me -1 because I want to continue using Lynx.
I'm not sure - I think you can implement your own choices at different points. What's interesting to me so far is less the current UI/flashiness (drag 'n drop photos, real-time keystrokes, etc...) they are showing, than the openness of the protocol and implementation, opening the door to all sorts of potential uses and/or integrations with existing systems. Other than convenience for interactive use, and as a reference client, I'm not sure how critical a browser really is to the system. Fundamentally, wave seems to be rich, versioned (or at least time tracked), content management system with well defined server to server and server to client communication protocols, including conflict resolution. They even brought up VCS-like concepts (currently unimplemented) of having waves branch and evolve independently, fold changes back into a parent wave and then re-distribute down to the other children over time, which points to a reasonable central data structure. For example, if you jump to about 1:08:13 in the presentation you can see a more textual display implemented by an independent wave server/client - almost newsreader like. I presume such a client has to make similar decisions as to display of non-textual data as Lynx has to with the web. Or if you embed the wave in a web page, it could still be handled by text browsers (the blog integration at 20:43 for example) or perhaps with RSS. Server robots could help too - a robot participating in the wave could produce a more text-friendly reader version, perhaps published elsewhere on the web or in a different system. They demoed, for example, integrating with Google Code's bug tracking back end at 1:02:30 where comments in the wave were reflected into the bug comments (though the reverse direction wasn't implemented yet), or even the twitter integration at 57:53. -- David
On Tue, Jun 2, 2009 at 10:34 AM, "Martin v. Löwis" <martin@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 release schedule is defined in PEP 375
I'm curious if an exception could be made in this case, given that you have admitted that ipaddr is not an important library.
This would be need to be decided by the release manager. However, given that Guido has already pronounced on this issue, Benjamin is unlikely to change anything.
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 hear a public outcry - only a single complainer.
I normally just lurk on python-dev, but I will comment on this thread. I manage several large IP address spaces and I've written my own IP address tools in the past. The comments on the thread motivated me to look at the ipaddr module. I fully agree with Clay's comments. I would not use the module as it stands. I apologize for lurking too much and not commenting earlier. casevh
Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/casevh%40gmail.com
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 was a conversation on IRC (including the RM) where it was discussed. So, in the unlikely event that Guido changes his mind, there is still time to do so. Raymond
participants (33)
-
"Martin v. Löwis" -
A.M. Kuchling -
Aahz -
Alexander Belopolsky -
Andrew McNamara -
Antoine Pitrou -
Barry Warsaw -
Ben Finney -
Benjamin Peterson -
Bill Janssen -
C. Titus Brown -
Case Vanhorsen -
Clay McClure -
David Bolen -
Dirkjan Ochtman -
Georg Brandl -
glyph＠divmod.com -
Greg Ewing -
Gregory P. Smith -
Guido van Rossum -
Jake McGuire -
Jake McGuire -
Jean-Paul Calderone -
Jesse Noller -
Michael Foord -
Ned Deily -
Neil Schemenauer -
Nick Coghlan -
Paul Moore -
R. David Murray -
Raymond Hettinger -
Stephen J. Turnbull -
Terry Reedy