On Sat, Aug 3, 2019 at 3:36 PM DL Neil <pythonl...@danceswithmice.info> wrote: > > On 3/08/19 4:02 PM, Terry Reedy wrote: > > I currently work on my home machine, so my recent 'pair programming' has > > been limited to comments and now diff suggestions on Github PRs. So I > > need the comments on real use cases from you and Chris to even think > > about something for IDLE. > > Is that really "p-p" or more "code review"?
I'd say that, no, commenting on GitHub PRs is not "pair programming". It's a different form of collaboration. Pair programming specifically refers to two people working in realtime on one project. > > Good. Master-satellite would be much easier. We added line numbers to > > IDLE's editor last week, so verbal feedback from satellite to master > > should be sufficient for many purposes. > > Elsewhere in the thread there is much discussion of this. Regardless of > the "we are all adults here" philosophy, my feeling (stuck-in-the-mud > though it might be) is that one person/system has to have 'control', and > the other, the 'pair' (or the 'tutor') is invited to see/do 'whatever'. > However, r/o would be a show-stopping limitation. When pair programming involves training (tutor and student, or senior and junior programmer), forcing the more experienced person to stay hands-off is a very good thing; it forces the less experienced person to actually keyboard every change, and thus is more likely to understand what's going on. But when it's two peers, you'll often want to switch out who's in control. Depending on the architecture, this might be a simple matter of flipping a switch and changing who's master and who's on a read-only clone. > > 4. Require encryption of some sort if over the public internet. Just > > because people download code from strangers over http is not a reason to > > encourage carelessness. I am pretty ignorant on what this would mean. > > TLS? > TLS doesn't really solve this problem. If you have a single central server, TLS just tells you that you're talking to that server, without proving anything about who's on the other end. Even if you directly connect the two nodes, TLS wouldn't prove who that is, unless you get a dedicated certificate. What it *can* prove is that your data stream hasn't been tampered with en route, but the problem of receiving code from strangers is still an issue. Ultimately, pair programming depends on a measure of trust - you have to be confident that the person you're pairing with isn't going to be maliciously messing with your system. However, I think it would be an extremely useful feature if the output from running the program could also be replicated to the other client. Let's say you're developing a Python script that connects to a database (eg psycopg2 + PostgreSQL). To run that locally, you'd need your own replica of the database, and that often means having your own credentials (ie having the script able to choose which set of credentials to use), replicating the database schema, and possibly even getting a duplicate of the current table contents. Way WAY easier to just run it on one computer and copy the output. > >>> 2. Do two systems connect directly peer-to-peer or through a server? > >> Exclusively the latter (thus far in the investigation). > > > > The former would be the only option until someone (else) set up and > > supported a server. > > Except that when you think about it, were I viewing your screen, your > m/c would indeed be a "server"! We could lose potential by arguing > semantics (not my intention). In fact, we dealt with this point, above. There's a difference between the conceptual and the technical here. The NAT issue may mean that, for technical reasons, a broker is needed. > I'm thrilled at your interest, but am ignorant/uncertain that > pair-programming and Idle go together. To which you may say that perhaps > they should... In which case, I'd recommend taking a look at some of the > services (listed at the beginning of this thread) to first establish > 'virtue' and yes, I'll try to do a better job at roughing-out some > use-cases with you... I think Idle could be a very useful pair programming tool, but that doesn't mean it'd be the best option available. IMO it could be an extremely light-weight one, though. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
