Splitting comp.lang.python

[Cameron Laird]

In article <XFMail.000301155713.mikael at isy.liu.se>,
Mikael Olofsson  <mikael at isy.liu.se> wrote:
>
>On 01-Mar-00 Gerrit Holl wrote:
> >  <quote name=3D"Mikael Olofsson" date=3D"951918286" email=3D"mikael at isy.=
>liu.se">
> > > Perhaps the best thing would be to keep c.l.py as it is as the general
> > > place for discussion, and then adding subgroups for specific interests=
>.
> > =20
> >  Perl uses:
> > =20
> >   comp.lang.perl.announce
> >   comp.lang.perl.misc
> >   comp.lang.perl.tk
> >   comp.lang.perl.modules
> >   comp.lang.perl
> >   comp.lang.perl.moderated
> > =20
> >  Maybe it's a good idea too do something like that on c.l.py.
>
>Not necessarily exactly those subgroups, but definitely something in=20
>that direction, yes. Based on my first post in this thread, I come up=20
>with the following
>
>  c.l.py             General
>  c.l.py.gui         GUI
>  c.l.py.os          os/platform dependent issues
>  c.l.py.db          DataBase handling
>  c.l.py.advocacy    Whitespace and such
>
>The CGI subgroup that I proposed earlier is perhaps not especially
>interresting. Many questions and discussions regarding CGI programming=20
>tend to be originating from poor understanding of Python itself, and=20
>its modules. I guess that is the way in to the Python world for many
>newbies. It sure was for me once.
>
>I think that it is better to have general subgroup names such as gui,=20
>os, db, and advocacy, rather than more explicit ones like tk, linux,=20
>sql, and whitespace. Maybe platform is better than os... I leave that
>to the os/platform lawyers out there.
			.
			.
			.
Seconded.  That is, I can imagine that creation of
comp.lang.python.{gui,db,advocacy} would result in
nice dialectical dynamics.  Most important, I pro-
pose that the target audiences would quickly agree
on which threads belong where.  I see the .gui and
.db humming along with nice sustainable communities
of discussants and topics.

I'm a bit less convinced .advocacy would work.  It
certainly would change the character of our present
inclusive c.l.p.  Some of that change would be for
the better ...

Here's the hazard in all this:  timbot doesn't bother
with c.l.p.gui because actual user interfaces are too
practical for it (or whatever the random reason gener-
ator happens to say that day).  Some part of the real
progress with GUI bindings is dependent on general
ideas about Pyextensibility and persistence methods
and dictionary cleverness and the threading model and
... and, well, we'd miss him.

Whatever we do or don't do with c.l.p will have both
costs and benefits.  I take the possibility seriously
enough that I'm criticizing it realistically.  If
people want such a change, it can work, despite the
melancholy it elicits from the nostalgia-afflicted.
I do believe some changes are clearly more favorable
than others (c.l.p.gui over c.l.p.tkinter), and I'll
largely confine my remarks to those comparisons.

Any change will involve a controversy over whether
c.l.p becomes c.l.p.misc or stays unchanged.  Don't
be distracted by that, at least for now.  Treat it as
a technical requirement to suffer through the argument.

I'm not so sanguine about c.l.p.platform.  What are
examples of postings you anticipate there?
-- 

Cameron Laird <claird at NeoSoft.com>
Business:  http://www.Phaseit.net
Personal:  http://starbase.neosoft.com/~claird/home.html