[Python-Dev] Breaking undocumented API

[Michael Foord]

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.