From tim_one@email.msn.com  Thu Jun  1 06:20:59 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Thu, 1 Jun 2000 01:20:59 -0400
Subject: [meta-sig] Re: [Python-Dev] SIG: python-lang
In-Reply-To: <39357EE6.BBD276C1@digicool.com>
Message-ID: <001f01bfcb89$2c044a60$b92d153f@tim>

Two observations:

1. "Follow the Guido."  It doesn't matter how many alternative forums
   we set up or what their nature is, the "serious" discussion will
   migrate instantly to exactly whichever particular one of them Guido
   happens to be active in at any moment.  This seems to me to follow
   from the very nature of a BDFL organization:  when one guy makes
   the rules, that's the one (& often only!) guy you really want to
   talk to.

2. There are very few "new" language suggestions that weren't already
   old by the end of '91.  But the community displays no collective
   memory, and in part because the historical record is *already*
   sprayed across far too many forums.

For purposes of language evolution, it's time Python did this the way every
other language does:  relatively careful proposals and separate (but
related) rationales, refined over time by interested parties rather than
re-argued from scratch every time a newcomer shows up on c.l.py demanding
satisfaction.  Some combination of the SIGs, ToDo list and FAQ is the
closest thing we've got to that now, and that mish-mash doesn't work for
this purpose.

I don't know how to solve that, but it sounds like each of the rest of you
does <wink>.  I know what's needed in the *end*, though:  a permanent
repository for spec and rationale docs, coupled with free-form discussion
forums.  Nothing of permanent interest should remain in the forum:
everything a newcomer to an issue needs to know should appear in the
appropriate spec or the rationale.  And every particular idea needs a
champion whose job it is to update those docs, else the idea drops out of
consideration.

However, as with any other scheme, this one too (*however* implemented) will
end up being a piss into the wind if Guido doesn't participate (language
design is the one area where he can't pretend it's somebody else's job --
being BDFL isn't all job offers and lavish honeymoons <wink>).

just-sucking-up-to-the-boss-ly y'rs  - tim




From mclay@nist.gov  Thu Jun  1 11:36:29 2000
From: mclay@nist.gov (Michael McLay)
Date: Thu, 1 Jun 2000 06:36:29 -0400 (EDT)
Subject: [meta-sig] Re: [Python-Dev] SIG: python-lang
In-Reply-To: <001f01bfcb89$2c044a60$b92d153f@tim>
References: <39357EE6.BBD276C1@digicool.com>
 <001f01bfcb89$2c044a60$b92d153f@tim>
Message-ID: <14646.15533.347076.658900@fermi.eeel.nist.gov>

Tim Peters writes:
 > I don't know how to solve that, but it sounds like each of the rest of you
 > does <wink>.  I know what's needed in the *end*, though:  a permanent
 > repository for spec and rationale docs, coupled with free-form discussion
 > forums.  Nothing of permanent interest should remain in the forum:
 > everything a newcomer to an issue needs to know should appear in the
 > appropriate spec or the rationale.  And every particular idea needs a
 > champion whose job it is to update those docs, else the idea drops out of
 > consideration.

This sounds a bit like the RFC mechanism used by the IETF.  The email
lists are used for discussions, but the specifications and rationales
are captured as numbered documents.  Perhaps python.org should have a
(in)formal submission process modeled after the IETF process.

The wiki idea sounds interesting as well, but I like the persistence
of the IETF RFC documents.  My only complaints with the IETF RFCs is
the lack of forward references in obsoleted RFC, but other than that I
find it very easy to track the important decisions made by the IETF.
I suppose the Python RFCs could use an XML document format to add some
structure to the Python RFCs.



From andy@reportlab.com  Thu Jun  1 13:31:10 2000
From: andy@reportlab.com (Andy Robinson)
Date: Thu, 1 Jun 2000 13:31:10 +0100
Subject: [meta-sig] Re: [Python-Dev] SIG: python-lang
In-Reply-To: <14646.15533.347076.658900@fermi.eeel.nist.gov>
Message-ID: <PGECLPOBGNBNKHNAGIJHEEDKCCAA.andy@robanal.demon.co.uk>

Michael McLay says:
> This sounds a bit like the RFC mechanism used by the IETF.  The email
> lists are used for discussions, but the specifications and rationales
> are captured as numbered documents.  Perhaps python.org should have a
> (in)formal submission process modeled after the IETF process.
>
> The wiki idea sounds interesting as well, but I like the persistence
> of the IETF RFC documents.  My only complaints with the IETF RFCs is
> the lack of forward references in obsoleted RFC, but other than that I
> find it very easy to track the important decisions made by the IETF.
> I suppose the Python RFCs could use an XML document format to add some
> structure to the Python RFCs.

I like this suggestion.  I've worked on big multi-year corporate projects
with good architecture documents, and it was very important to be able to
see why things were done originally, even though circumstances change and
decisions often seem wrong several years later.

Much though I hate writing them, I also think thrashing out these proposals
and "signing them off" is a good exercise that ultimately saves time on
implementation.

Marc-Andre Lemburg's Unicode proposal is a good starting point.  Maybe this
could be made PyRFC001 on www.python.org somewhere.

- Andy Robinson



From klm@digicool.com  Thu Jun  1 15:13:25 2000
From: klm@digicool.com (Ken Manheimer)
Date: Thu, 1 Jun 2000 10:13:25 -0400 (EDT)
Subject: [meta-sig] Re: [Python-Dev] SIG: python-lang
In-Reply-To: <14646.15533.347076.658900@fermi.eeel.nist.gov>
Message-ID: <Pine.LNX.4.21.0006010939020.31343-100000@korak.digicool.com>

On Thu, 1 Jun 2000, Michael McLay wrote:

> of the IETF RFC documents.  My only complaints with the IETF RFCs is
> the lack of forward references in obsoleted RFC, but other than that I
> find it very easy to track the important decisions made by the IETF.

With the "nesting" organizational zwiki features, major revisions could be
represented like so:

      NetworkPrototocols
              /
             /
       NFSProtocols
         /  |   \
        /   |    \
  NFS1.x  NFS2.x NFS3.x

Each of the NFSy.x pages would indicate their parent, NFSProtocols, so
anyone wondering about all the other versions would be able to go to the
encompassing page, to discover all the relevant stuff.

(I don't mean to suggest that the above organization is the right one for
network protocols, just a simple example from a possibly simplistic model
of them...)

With v2.2 changes (it's in the CVS checkout), Zope will provide access to
contents of different object versions, particularly useful for text-based
objects like wiki pages - so minor version changes to an RFC could be
captured in different versions of the wiki page for the RFC, if that would
be a suitable thing to do.  With discriminating security settings, a group
of authors can collaborate on the development of an RFC in full view of
the public, for feedback and comment.  Lotsa benefits.

> I suppose the Python RFCs could use an XML document format to add some
> structure to the Python RFCs.

The next generation of structured text processing will realize the
original intent, divorcing the internal structure from its presentation -
so we can subclass the renderer to produce whatever kind of output we
might want, including XML.  This way, RFC authors could author the
document in easy-to-write structured text and still be expressing the full
structure...

Ken
klm@digicool.com



From tim_one@email.msn.com  Thu Jun  1 06:20:59 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Thu, 1 Jun 2000 01:20:59 -0400
Subject: [meta-sig] Re: [Python-Dev] SIG: python-lang
In-Reply-To: <39357EE6.BBD276C1@digicool.com>
Message-ID: <001f01bfcb89$2c044a60$b92d153f@tim>

Two observations:

1. "Follow the Guido."  It doesn't matter how many alternative forums
   we set up or what their nature is, the "serious" discussion will
   migrate instantly to exactly whichever particular one of them Guido
   happens to be active in at any moment.  This seems to me to follow
   from the very nature of a BDFL organization:  when one guy makes
   the rules, that's the one (& often only!) guy you really want to
   talk to.

2. There are very few "new" language suggestions that weren't already
   old by the end of '91.  But the community displays no collective
   memory, and in part because the historical record is *already*
   sprayed across far too many forums.

For purposes of language evolution, it's time Python did this the way every
other language does:  relatively careful proposals and separate (but
related) rationales, refined over time by interested parties rather than
re-argued from scratch every time a newcomer shows up on c.l.py demanding
satisfaction.  Some combination of the SIGs, ToDo list and FAQ is the
closest thing we've got to that now, and that mish-mash doesn't work for
this purpose.

I don't know how to solve that, but it sounds like each of the rest of you
does <wink>.  I know what's needed in the *end*, though:  a permanent
repository for spec and rationale docs, coupled with free-form discussion
forums.  Nothing of permanent interest should remain in the forum:
everything a newcomer to an issue needs to know should appear in the
appropriate spec or the rationale.  And every particular idea needs a
champion whose job it is to update those docs, else the idea drops out of
consideration.

However, as with any other scheme, this one too (*however* implemented) will
end up being a piss into the wind if Guido doesn't participate (language
design is the one area where he can't pretend it's somebody else's job --
being BDFL isn't all job offers and lavish honeymoons <wink>).

just-sucking-up-to-the-boss-ly y'rs  - tim




From mclay@nist.gov  Thu Jun  1 11:36:29 2000
From: mclay@nist.gov (Michael McLay)
Date: Thu, 1 Jun 2000 06:36:29 -0400 (EDT)
Subject: [meta-sig] Re: [Python-Dev] SIG: python-lang
In-Reply-To: <001f01bfcb89$2c044a60$b92d153f@tim>
References: <39357EE6.BBD276C1@digicool.com>
 <001f01bfcb89$2c044a60$b92d153f@tim>
Message-ID: <14646.15533.347076.658900@fermi.eeel.nist.gov>

Tim Peters writes:
 > I don't know how to solve that, but it sounds like each of the rest of you
 > does <wink>.  I know what's needed in the *end*, though:  a permanent
 > repository for spec and rationale docs, coupled with free-form discussion
 > forums.  Nothing of permanent interest should remain in the forum:
 > everything a newcomer to an issue needs to know should appear in the
 > appropriate spec or the rationale.  And every particular idea needs a
 > champion whose job it is to update those docs, else the idea drops out of
 > consideration.

This sounds a bit like the RFC mechanism used by the IETF.  The email
lists are used for discussions, but the specifications and rationales
are captured as numbered documents.  Perhaps python.org should have a
(in)formal submission process modeled after the IETF process.

The wiki idea sounds interesting as well, but I like the persistence
of the IETF RFC documents.  My only complaints with the IETF RFCs is
the lack of forward references in obsoleted RFC, but other than that I
find it very easy to track the important decisions made by the IETF.
I suppose the Python RFCs could use an XML document format to add some
structure to the Python RFCs.



From andy@reportlab.com  Thu Jun  1 13:31:10 2000
From: andy@reportlab.com (Andy Robinson)
Date: Thu, 1 Jun 2000 13:31:10 +0100
Subject: [meta-sig] Re: [Python-Dev] SIG: python-lang
In-Reply-To: <14646.15533.347076.658900@fermi.eeel.nist.gov>
Message-ID: <PGECLPOBGNBNKHNAGIJHEEDKCCAA.andy@robanal.demon.co.uk>

Michael McLay says:
> This sounds a bit like the RFC mechanism used by the IETF.  The email
> lists are used for discussions, but the specifications and rationales
> are captured as numbered documents.  Perhaps python.org should have a
> (in)formal submission process modeled after the IETF process.
>
> The wiki idea sounds interesting as well, but I like the persistence
> of the IETF RFC documents.  My only complaints with the IETF RFCs is
> the lack of forward references in obsoleted RFC, but other than that I
> find it very easy to track the important decisions made by the IETF.
> I suppose the Python RFCs could use an XML document format to add some
> structure to the Python RFCs.

I like this suggestion.  I've worked on big multi-year corporate projects
with good architecture documents, and it was very important to be able to
see why things were done originally, even though circumstances change and
decisions often seem wrong several years later.

Much though I hate writing them, I also think thrashing out these proposals
and "signing them off" is a good exercise that ultimately saves time on
implementation.

Marc-Andre Lemburg's Unicode proposal is a good starting point.  Maybe this
could be made PyRFC001 on www.python.org somewhere.

- Andy Robinson



From klm@digicool.com  Thu Jun  1 15:13:25 2000
From: klm@digicool.com (Ken Manheimer)
Date: Thu, 1 Jun 2000 10:13:25 -0400 (EDT)
Subject: [meta-sig] Re: [Python-Dev] SIG: python-lang
In-Reply-To: <14646.15533.347076.658900@fermi.eeel.nist.gov>
Message-ID: <Pine.LNX.4.21.0006010939020.31343-100000@korak.digicool.com>

On Thu, 1 Jun 2000, Michael McLay wrote:

> of the IETF RFC documents.  My only complaints with the IETF RFCs is
> the lack of forward references in obsoleted RFC, but other than that I
> find it very easy to track the important decisions made by the IETF.

With the "nesting" organizational zwiki features, major revisions could be
represented like so:

      NetworkPrototocols
              /
             /
       NFSProtocols
         /  |   \
        /   |    \
  NFS1.x  NFS2.x NFS3.x

Each of the NFSy.x pages would indicate their parent, NFSProtocols, so
anyone wondering about all the other versions would be able to go to the
encompassing page, to discover all the relevant stuff.

(I don't mean to suggest that the above organization is the right one for
network protocols, just a simple example from a possibly simplistic model
of them...)

With v2.2 changes (it's in the CVS checkout), Zope will provide access to
contents of different object versions, particularly useful for text-based
objects like wiki pages - so minor version changes to an RFC could be
captured in different versions of the wiki page for the RFC, if that would
be a suitable thing to do.  With discriminating security settings, a group
of authors can collaborate on the development of an RFC in full view of
the public, for feedback and comment.  Lotsa benefits.

> I suppose the Python RFCs could use an XML document format to add some
> structure to the Python RFCs.

The next generation of structured text processing will realize the
original intent, divorcing the internal structure from its presentation -
so we can subclass the renderer to produce whatever kind of output we
might want, including XML.  This way, RFC authors could author the
document in easy-to-write structured text and still be expressing the full
structure...

Ken
klm@digicool.com