kennethreitz/pep8.org
1
0
Fork 0
mirror of https://github.com/kennethreitz/pep8.org.git synced 2026-06-05 23:10:16 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #32 from KashFar/master

Browse Source 
Standardized capitalization of section titles
This commit is contained in:
Buğra İşgüzar
2019-07-16 17:07:51 +03:00
committed by GitHub
parent e5ce04d406 9ef308fcd2
commit f43e462e78
1 changed files with 8 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files
index.html
+8 -8
View File
@@ -239,7 +239,7 @@ ul > li {
<h1 id="code-lay-out">Code lay-out</h1>
<h1 id="code-lay-out">Code Layout</h1>
<h2 id="indentation">Indentation</h2>
@@ -486,7 +486,7 @@ import foo.bar.yourclass</code></pre>
<p>When republishing names this way, the guidelines below regarding public and internal interfaces still apply.</p></li>
</ul>
<h2 id="module-level-dunder-names">Module level dunder names</h2>
<h2 id="module-level-dunder-names">Module Level Dunder Names</h2>
<p>Module level "dunders" (i.e. names with two leading and two trailing underscores) such as <code>__all__</code>, <code>__author__</code>, <code>__version__</code>, etc. should be placed after the module docstring but before any import statements <em>except</em> <code>from __future__</code> imports. Python mandates that future-imports must appear in the module before any other code except docstrings.</p>
@@ -707,7 +707,7 @@ if foo == &#39;blah&#39;: one(); two(); three()</code></pre></li>
</ul>
<h1 id="when-to-use-trailing-commas">When to use trailing commas</h1>
<h1 id="when-to-use-trailing-commas">When to Use Trailing Commas</h1>
<p>Trailing commas are usually optional, except they are mandatory when making a tuple of one element (and in Python 2 they have semantics for the <code>print</code> statement). For clarity, it is recommended to surround the latter in (technically redundant) parentheses.</p>
@@ -895,7 +895,7 @@ Optional plotz says to frobnicate the bizbaz first.
<p>Note that there is a separate convention for builtin names: most builtin names are single words (or two words run together), with the CapWords convention used only for exception names and builtin constants.</p>
<h3 id="type-variable-names">Type variable names</h3>
<h3 id="type-variable-names">Type Variable Names</h3>
<p>Names of type variables introduced in PEP 484 should normally use CapWords
@@ -923,7 +923,7 @@ or contravariant behavior correspondingly. Examples</p>
<p>Modules that are designed for use via <code>from M import *</code> should use the <code>__all__</code> mechanism to prevent exporting globals, or use the older convention of prefixing such globals with an underscore (which you might want to do to indicate these globals are “module non-public”).</p>
<h3 id="function-and-variable-names">Function and variable names</h3>
<h3 id="function-and-variable-names">Function and Variable Names</h3>
<p>Function names should be lowercase, with words separated by underscores as necessary to improve readability.</p>
@@ -933,7 +933,7 @@ or contravariant behavior correspondingly. Examples</p>
<p>mixedCase is allowed only in contexts where that’s already the prevailing style (e.g. threading.py), to retain backwards compatibility.</p>
<h3 id="function-and-method-arguments">Function and method arguments</h3>
<h3 id="function-and-method-arguments">Function and Method Arguments</h3>
<p>Always use <code>self</code> for the first argument to instance methods.</p>
@@ -963,7 +963,7 @@ or contravariant behavior correspondingly. Examples</p>
<p>Constants are usually defined on a module level and written in all capital letters with underscores separating words. Examples include <code>MAX_OVERFLOW</code> and <code>TOTAL</code>.</p>
<h3 id="designing-for-inheritance">Designing for inheritance</h3>
<h3 id="designing-for-inheritance">Designing for Inheritance</h3>
<p>Always decide whether a class’s methods and instance variables (collectively: “attributes”) should be public or non-public. If in doubt, choose non-public; it’s easier to make it public later than to make a public attribute non-public.</p>
@@ -1004,7 +1004,7 @@ or contravariant behavior correspondingly. Examples</p>
</ul>
<h2 id="public-and-internal-interfaces">Public and internal interfaces</h2>
<h2 id="public-and-internal-interfaces">Public and Internal Interfaces</h2>
<p>Any backwards compatibility guarantees apply only to public interfaces. Accordingly, it is important that users be able to clearly distinguish between public and internal interfaces.</p>