On 17/11/2010 13:31, Łukasz Langa wrote:
Am 17.11.2010 14:11, schrieb Michael Foord:
I don't think those reasons are compelling and the cost of splitting
the Python development style guide into multiple documents are
higher. (They run the risk of contradicting each other, if you want
to find a particular rule you have multiple places to check, there is
no single authoritative place to send people, people *wanting* to
base documents off the Python style rules now have to refer to
multiple places, etc.)
So -1 on splitting Python development style guide into multiple
documents.
Bah, again my English skills failed me in a critical moment ;) I was
proposing creation of PEP 88 to supersede PEP 8. This would be better
IMO for the following reasons:
1. Existing projects wouldn't have to explain afterwards why they
differ from PEP 8, e.g. in terms of public/private API declaration.
"Your project claims PEP8 conformance! Why don't you use __all__?"
"Ah, that was before they've added this part to PEP8."
2. All other projects (new and old) would have a much more explicit
(better than implicit) sign that *something significant has changed*
in the recommended style.
3. As someone already said, PEP8 is not visible enough. Transition
from PEP 8 to PEP 88 could help to make some hype that would help
raise the awareness within the community.
Mutating PEP8 is bad form. We fight mercilessly over source code
backwards compatibility so I think PEPs should be taken just as
seriously in that regard.
Given the following:
http://code.python.org/hg/peps/log/6b223d6b8b24/pep-0008.txt
Anyone who thinks that PEP 8 is immutable (and should remain so) is
already wrong...
As discussed, the goal is to codify what is already considered "best
practise" within the wider community and the standard library *anyway*.
So in practise this won't be a great surprise or change.
As to the publicity, PEP 8 is both the most widely known PEP and the
most widely known Python style guide. This isn't an argument for letting
it rot, nor for deprecating it and invalidating all those tutorials /
developers / links / books that consider it authoritative. Better to
carefully and slowly evolve it as practise and the language change.
For those wanting immutable versions we provide that in the form of
specific revisions.
All the best,
Michael
Łukasz
--
http://www.voidspace.org.uk/
READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
