On Tue, Jun 2, 2009 at 1:47 AM, "Martin v. Löwis" wrote:

...

If this were a core feature that many developers were anxiously awaiting, I could understand the desire to release and iterate. But is there really a pressing need for an IP library in the stdlib?

You should have asked this 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

On Tue, Jun 2, 2009 at 2:15 AM, "Martin v. Löwis" wrote:

We could remove it, but then what we have wouldn't really be a release candidate anymore, so the release would get delayed.

How long do release candidates soak in the field before being accepted? I'm curious if an exception could be 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

On Tue, 02 Jun 2009 19:34:11 +0200, "\"Martin v. Löwis\"" wrote:

[snip]

...

You seem comfortable with these quirks, but then you're not planning to write software with this library. Developers who do intend to write meaningful network applications do seem concerned, yet we're ignored.

I don't 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

On 03/06/2009, at 3:56 AM, Jean-Paul Calderone wrote:

On Tue, 02 Jun 2009 19:34:11 +0200, "\"Martin v. Löwis\""

...

wrote: [snip]

...

You seem comfortable with these quirks, but then you're not planning to write software with this library. Developers who do intend to write meaningful network 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).

On Tue, Jun 2, 2009 at 7:39 PM, Guido van Rossum wrote:

I'm disappointed in the process -- it's as if nobody really reviewed the API until it was released with rc1, and this despite there being a significant discussion about its inclusion and alternatives months ago. (Don't look at me -- 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?

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

2009/6/2 Aahz :

On Tue, Jun 02, 2009, Guido van Rossum wrote:

...

I hope we can learn from this.

I'm not thrilled with adding more process just because we had a problem here, and the only obvious solution I see is to require a PEP every time a module is added.  Based on what I've seen 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

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.

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.

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

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/)

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

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/)

On 05:19 pm, guido@python.org wrote:

On Wed, Jun 3, 2009 at 10:13 AM, Neil Schemenauer wrote:

...

Barry Warsaw wrote:

...

It would be really nice if say the Cheeseshop had a voting feature. Use PEP 10 voting to get a rough estimate of a module's popularity (download counts alone might not tell you 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 ;-).

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.

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

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.

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

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 ---------------------------------------------------------------

On Thu, Jun 4, 2009 at 6:20 AM, Paul Moore 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.

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 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 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

On Thu, Jun 4, 2009 at 5:08 PM, C. Titus Brown 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

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 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

On Wed, Jun 3, 2009 at 10:41 AM, 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

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

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

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 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.

Stephen J. Turnbull wrote:

Antoine Pitrou writes:

...

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 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

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

Terry Reedy 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 wrote:

Terry Reedy 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

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

Aahz 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

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