[Python-Dev] PEP 318, and the PEP process

[Edward K. Ream]

> I do firmly think this is sufficient reason. It means
> there is no champion for the PEP, so there can't be
> a new feature. In essence, the champion is the one
> who "controls" the feature, and who is in charge of
> making it work well. He is the one to complain to,
> and he will make sure issues get resolved (not necessarily
> resolving them himself).

Python has matured into a language in which many people and companies have
significant investments.  Changes to Python matter.

In this environment, making haste slowly makes more and more sense.  In
particular, not having pep's reflect reality is likely to waste a lot of
time.  It also just doesn't seem like proper procedure.

This is a highly sensitive topic.  I have the highest regard for Python's
volunteers, and I have no intention of even suggesting what they should or
shouldn't do.  It is for GvR to pronounce, if he pleases.

The present discussion of pep 318 shows the pitfalls in not treating Python
as the supremely important language that it clearly is.  I served, very
briefly, on the ANSI C Standards Committee about 10 years ago.  Clearly,
Python needn't follow the extremely picky rules for public disclosure and
public comment that are de rigueur in the Standards world.  However, it
might help to start shading just a bit in that direction, if only to head
off the kind of public outcry we have had with 318.

As I said on c.l.py, it does not seem fair to claim to be discussing a
proposal publicly if it's pep does not reflect reality.  The reason is
simple:  people like me will ignore discussion on python-dev if the pep does
not seem to concern them.  It's like announcing a meeting to discuss sewers,
then using that (public) meeting to give all the county commissioners a
raise.  The open meeting law has been violated.

Edward

P.S.  To respond to the original quote :-)  My own opinion is the lack of a
champion is more than sufficient reason to delay or kill a feature (or a
pep).  To repeat: changes to Python matter.  If there isn't sufficient will
to keep peps up-to-date, how can we be assured of the quality of the design,
or of the code?  Again, I have no right to demand that this criterion go
into effect.

EKR
--------------------------------------------------------------------
Edward K. Ream   email:  edreamleo at charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------