[Python-Dev] PEP 318, and the PEP process (original) (raw)

Edward K. Ream edreamleo at charter.net
Fri Aug 6 16:16:52 CEST 2004

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

More information about the Python-Dev mailing list