This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients Trundle, alex, asvetlov, barry, chris.jerdonek, daniel.urban, david.villa, dmalcolm, eric.smith, ezio.melotti, gregory.p.smith, jcea, jkloth, larry, mark.dickinson, pitrou, skrah, v+python
Date 2012-12-08.18:30:19
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1354991335.3318.19.camel@localhost.localdomain>
In-reply-to <1354989352.4.0.937207161041.issue16612@psf.upfronthosting.co.za>
Content
> Antoine, Stefan: There doesn't appear to be a bright line separating
> "this should get a PEP" from "this doesn't need a PEP".  That said,
> changes to the C API for CPython don't seem to merit PEPs very often,
> the recent "Stable ABI" being the lone exception to the rule I can
> recall.  Also, Guido already said (in python-dev) he didn't think it
> merited a PEP, and I tend to agree.

My argument for requiring a PEP is that this change will not only affect
the people maintaining the clinic code. It will affect everyone
contributing and maintaining code in the CPython codebase. It's much
more than "just an addition to the C API", it's a change in how CPython
is developed.

Writing and proposing a PEP brings public scrutiny in a much more
visible, and also better-recorded, way than a bug entry on a tracker.

Note that writing a PEP doesn't mean that there'll be a huge discussion
about it. And you needn't post it on python-ideas, you can post it on
python-dev instead.
History
Date User Action Args
2012-12-08 18:30:19pitrousetrecipients: + pitrou, barry, gregory.p.smith, jcea, mark.dickinson, larry, eric.smith, jkloth, ezio.melotti, v+python, alex, Trundle, asvetlov, skrah, dmalcolm, daniel.urban, chris.jerdonek, david.villa
2012-12-08 18:30:19pitroulinkissue16612 messages
2012-12-08 18:30:19pitroucreate