[Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2 (original) (raw)
David Lyon david.lyon at preisshare.net
Thu Dec 24 02:40:47 CET 2009
- Previous message: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
- Next message: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Thu, 24 Dec 2009 10:31:09 +0900, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
Martin's point is that the PEP process doesn't have "reference" implementations. It has sample implementations. It may be useful to refer to a sample implementation as an example..
Fair enough. But otoh, asking for sample implementations on this type of project can skew the PEP towards a particular implementation or product.
A definition for metadata should be something quite abstract and self contained. So imo I am happier where it is currently.
What implementations do is another matter.
Right. We all agree on that.
An implementation with lots of state like PyPI is not likely to change quickly. As a matter of user relations (including but not limited to developers like you), Python doesn't want to deprecate practices that are expensive to change too soon. (That's not my opinion about what is appropriate, that is my assessment of the historical policy of Python, which I don't think will change.)
Well I would need more convincing that it is better to do one PEP every 4-5 years as a user relations exercise than one PEP every year or two years.
Whilst I agree that the core language is really great and the rate of progress can happily slow. It would be nice to see the rate of progress of other areas, such as the metadata side, increase a little.
That wouldn't break policy
David
- Previous message: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
- Next message: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]