Splitting comp.lang.python

Paul Boddie paulb at infercor.no
Thu Mar 2 12:15:44 CET 2000


Neil Hodgson wrote:
> 
>  Mikael Olofsson writes:
> 
> > Not necessarily exactly those subgroups, but definitely something in
> > that direction, yes. Based on my first post in this thread, I come up
> > 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
> 
>    I think this is splitting along the wrong dimension.

I agree. Firstly, "over-catagorising" only serves to confuse people, and when in
doubt people tend to cross-post: "Is this request a Windows question or a GUI
question? I'll post to both groups just to make sure!"

Moreover, any advocacy group, in my experience, inevitably leads to
cross-posting as the more hot-headed contributors to that group post "articles
of interest" to the other groups in order to "fight off" people who aren't
saying nice things about them or their favourite colour or political party.

>    The criterion for a good split should be "How many mails of no interest
> to me does it remove from the daily list"?

Indeed.

>     For me, I'd most like to remove tk messages and messages explaining how
> to configure emacs (not that there are really too many of those). However, I
> like to see Win32 messages but can see that others may want to avoid them.

Yes. I tend to use Solaris and Linux, and by subscribing to a GUI group I would
still see questions and messages about the Win32 GUI. However, I might be
interested in keeping an open mind about the platforms I use, and one of the
strengths of the current group is the possibility of stumbling across
interesting threads not directly relevant to my current interests.

>     Therefore, I'd say
>         comp.lang.python.misc    # Splitting removes top c.l.py
>         comp.lang.python.tk
>         comp.lang.python.win32
> 
>    There seems to me to be plenty of posts for these three to thrive. Maybe
> a comp.lang.python.unix although there may not be as much unix-specific
> traffic.

This looks quite interesting although there is still some potential confusion
between the 'tk' and 'win32' groups. This might not matter too much, though, as
many of the messages about Win32 GUIs tend to concentrate on the native GUI
APIs.

>     It'd be sad if we ever reached the level of unpleassantness about
> off-topic posts that some groups have achieved. Best to answer the question
> in the wrong group and suggest nicely that the off topic post would receive
> more response in the correct group.

Yes, and it would be best to avoid creating an advocacy group too. Advocacy
groups tend to attract clueless cheerleaders looking for a "brand" either to
promote or to destroy.

I haven't performed a thorough analysis of the types of messages being posted to
comp.lang.python, but I see several topics which could be moved into their own
groups:

Language justification and improvement
--------------------------------------

The whitespace wars, suggestions for "while 1" replacement keywords, requests to
add PHP3 features often come about as contributors either attack or justify the
use or absence of these things in Python.

New users
---------

The books to buy, and the best documentation to begin with are frequently asked
questions in the newsgroup. Perhaps we need to make the FAQ (even) more visible
on the group than it is now.

Getting Python to work
----------------------

There seem to be lots of questions on how Python can be compiled on different
platforms, whether it can be compiled on not-obviously-supported platforms, and
how certain modules can be built on different platforms.

Remember that more in-depth discussions of various issues may belong in the
Special Interest Groups, so we might not be inconveniencing people doing "real
work" on, for example, Python's type system if we dedicate a group to language
improvements and contributors start to discuss the whitespace issue again.

Paul



More information about the Python-list mailing list