[Python-ideas] PEP 572: Statement-Local Name Bindings

Stephen J. Turnbull turnbull.stephen.fw at u.tsukuba.ac.jp
Thu Mar 1 04:41:45 EST 2018


Reply-To set to *me*.  I don't really think this idea has legs at this
point.  It's been discussed before (it even has a SIG), but that ran
out of steam and the move to Mailman 3 (whose archiver provides a more
forum-like interface) is more or less imminent anyway, so it's kind of
moot.  I'm happy to deal with it off-list, but for the moment it's OT
IMO.

>>>>> Robert Vanden Eynde writes:

 > We are currently like a dozen of people talking about multiple
 > sections of a single subject.
 > 
 > Isn't it easier to talk on a forum?

There's the Overload SIG for this discussion of media (currently
inactive for many months).

Transparency notice: Mailman dev here, bias acknowledged, some in the
SIG were more sympathetic to forums, I don't claim to be
representative of SIG opinion.

 > Am I the only one who thinks mailing list isn't easy when lots of
 > people talking about multiple subjects?

No, you are hardly alone.

However, in my experience good forum software is distinctly inferior
to good mail software in high-traffic multi-threaded communications.
There is very little that forum software can do that a mail client
cannot.[1]  The main advantages of forum software are better thread
management (message ids are reliable and threads are built
synchronously, but it's not much better) and server-side storage (but
of course that's a SPoF).  As the name of the SIG suggests, the
problem is not so much that mail is such a bad medium; it's more that
the traffic levels are higher than people are used to, so the bad
experience of high traffic is conflated with a bad experience of using
mail.  (We do have one or two on the SIG who say that they do fine
with high-traffic multi-threaded forums.  I'm not sure how closely the
use case matches the main python-* channels, excluding python-list.)

The main advantage to using email is that management of multiple
high-traffic streams requires smart, highly configurable clients.
These have been available for mail since the late 80s.  They've only
gotten better since.  Forums, on the other hand, are based on thin
clients (ie web browsers), and so you get only the configuration the
forum offers, and you have to tell the forum all about it.  Of course
we are hackers: all the main browsers are scriptable, the language is
javascript, so we could write our own forum clients.  But that's
exactly what forum advocates want to avoid, at least if you call it
"email".

The problem for mail advocates is the flip side of that.  That is,
AFAIK there is no good mail software that runs in a browser (let alone
a smartphone), and change of mail clients, like religions and
programmer's editors, is advocated only at risk to limb and life.

As mentioned above, this whole issue may become moot when the mailing
lists are moved to Mailman 3 (we have some experimental Mailman 3
lists; ETA of a general migration is 6--18 months, at a slightly-
informed guess), which has a forum-like interface to the archives
called "HyperKitty".  HyperKitty is not a rival to Discourse, at least
not in the near future[2], but it's already pretty good.

 > A forum (or just few "issues" thread on github) is where we could
 > have different thread in parallel, in my messages I end up with
 > like 10 comments not all related, in a forum we could talk about
 > everything and it would still be organized by subjects.
 > 
 > Also, it's more interactive than email on a global list, people can
 > talk to each other in parallel, if I want to answer about a mail
 > that was 10 mail ago, it gets quickly messy.

I have no idea why any of those things would be unmanageable in email,
unless you have disabled threading in your client, or your client
doesn't allow you to kill (or collapse) threads of no interest to you.

 > We could all discuss on a gist or some "Issues" thread on GitHub.

Those are non-starters.  *You* can already do that, but very few of
the committers will follow.  We already have an issue tracker for very
focussed discussion.  This works because people actually working on an
issue are frequently spending hours on it and related work, so a
minute or so spent finding the appropriate issue is small overhead.
The overhead would be substantially greater if you had to regularly
scan all recent issues to see if any are of interest to you.  Trackers
are not very good at switching threads (issues), so even if you turn
on push notification for new issues, there will be substantial
overhead in following more than a tiny number of threads.  The kinds
of things that are discussed on the mailing lists generally need to be
broadcast, at least at first, and (assuming a decent mail client)
threads of no interest can easily be suppressed in email.  That's what
the committers do, mostly.  (Some just live with the firehose.)

Note, that's not to say a *forum* is a non-starter.  I guess that good
forum software provides similar features.  Some senior developers have
expressed interest in moving to a forum-based discussion.  Just that
most of the committers have broad interest in the discussion, so are
going to get their news from whatever the main channels are: we need
to have a fairly small number of them, and we do *not* want them split
across multiple media.

Finally, speaking of "split across media", any serious proposal for
change of medium will need to deal with the (voluminous) mail
archives.  This may not be difficult ("just provide a link"), but then
again it may not be that easy.  I have given no thought to it yet, and
I don't think the forum advocates have either.

Bottom line: in the end at least one PEP (I would guess two or three)
will be needed to make a major change to the workflow like this,
unless it's done in the context of a hybrid Mailman + forum system
like Mailman 3 including HyperKitty.

Once again, I admit that I strongly prefer mailing lists.  However, I
also believe that it's not bias to suggest that it's volume of
communication, not the medium, that is the problem here.  At least in
principle mail is fully capable of carrying the load.  In practice,
deficient mail clients (I'm looking at you, GMail and Outlook and
anything on a handheld) are all over the place.  In the end we'll need
to balance the costs of moving (which includes the preferences of
those who "just" like email better as well as setup and migration of
archives) against the benefits (mostly the preferences of those who
have learned to use forums very efficiently).


Footnotes: 
[1]  To my knowledge.  I'm willing to be educated.

[2]  And it won't solve the asynchronicity of SMTP messaging.  Mailman
will still be primarily a mail-based system, at least at first.



More information about the Python-ideas mailing list