On 3/08/19 4:02 PM, Terry Reedy wrote:
On 8/2/2019 4:52 PM, DL Neil wrote:
On 3/08/19 8:32 AM, Terry Reedy wrote:
On 8/2/2019 5:10 AM, DL Neil wrote:
Please recommend a Python-friendly, bandwidth-respectful, (but
effective) system for pair-programming; where the 'pair' are
geographically separate.
'geographically separate' could range from in the same room to a
continent away, as long as two people have separate keyboards and
screens.
True! As long as the tech works...
My experience has always been two sharing one PC, ie
taking-it-in-turns to think or to type. Do you do it differently?
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"?
What I had in-mind, and others may see it differently (and I will
happily modify any contribution to whatever an individual PUG attendee
might need!) is more-or-less the sort of practical question we see on
the list/one hears in a dev-lab, all the time, eg 'why doesn't 'this'
work?', or 'how do I...?" but with the advantage of the conversation
taking-place in real-time. If the answer is trivial, that's it.
Something more-involved however, may require a detailed look at the
code, or 'sitting and watching' whilst the other starts to include some
new 'suggestion' into their code-base. That takes us into the synergies
offered by pair-programming...
Use case: (possible examples)
(The meeting organiser talked about a project involving Solid ID)
- let's suggest the project hasn't started to-date. Perhaps he would
download the code and start coding an enquiry against the API. Meantime
I could be writing some Tests.
- he starts work, but the API doesn't respond in the expected manner. He
asks me to 'take a look', so I read the code, scroll around, ask 'why'
or 'why not' questions, and within the conversation we decide an
alternative approach
The former, strikes me as a possible contribution to the PUG mtg, but
the latter is more "pair programming" mode.
In the case of Wednesday's PUG meeting, my personal goal is to offer
encouragement. If that involves 'full' pair-programming I would like to
be ready - if it involves more simplistic contribution, crest la vie -
if we can find some new approach which 'shoots for the moon' then all my
dreams will come true...
IDLE is Python-friendly, free, and FOSS. I wonder how hard it would
be to pair programming connectivity as an extension.
This was an initially pie-in-the-sky idea that cannot solve your
immediate problem. But I think now that something useful could be
feasible sometime.
(with all due apologies)
I haven't touched Idle in years (probably v2.n - and n<5 at that). Can't
remember if I did something which impacted the Idle environment, or if
it was because I was doing a lot of web-work. Regardless, even after a
quick scan of the v3.7 PSL docs, I don't know what I'm talking about!
(as if that's anything new)
1. Do the systems you have considered operate as an editor +
satellite terminal or as synchronized peer editors.
Always the former, the local devices are merely 'repeaters' (through a
web browser) of what is happening on the server. This at both edit and
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.
IDLE already intercepts keypresses to do syntax coloring and smart
indentation (after \n). It should not be too hard to also send through
a socket anything sent to a tkinter/tk text widget. Making a text
read-only is trivial.
Sounds like the sorts of things Linux's X-server does/did.
With a real editor as satellite, the locally configured font face, font
size, and syntax highlight colors can be used. Transmitting
highlighting as text would require the invention of a protocol to
differentiate text from such meta information.
run/test stages.
Yes, important to remember that the editor is only one tool, and that
pair-programming may involve kicking-off a 'run' from the cmdLN or
browsing a page from the web server (etc).
Running code locally would
1. Save bandwidth.
2. Allow two users to do different things occasionally.
3. Reveal OS dependencies if on different systems. When patching IDLE,
I would love to have my Macbook set as a satellite to check that code
works on Mac as well as Windows.
Good idea! Websites frequently use services which show how different
browsers (and versions) will display the same web page.
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?
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.
Some of the cloud services I've reviewed present a screen very similar
to a GUI editor one might use on a (local) PC. Others offer a BASH cmdLN
and thus the Python REP. (I haven't tried calling for Idle, and maybe I
should - some have listed VI[m], EMACS, or even Nano. Thus, it may be
that a GUI-based service suits some coders, whereas others would prefer
the more character-oriented approach...
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...
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list
