diff --git a/index.html b/index.html index b30de2b..61c2508 100644 --- a/index.html +++ b/index.html @@ -239,7 +239,7 @@ ul > li { -

Code lay-out

+

Code Layout

Indentation

@@ -486,7 +486,7 @@ import foo.bar.yourclass

When republishing names this way, the guidelines below regarding public and internal interfaces still apply.

-

Module level dunder names

+

Module Level Dunder Names

Module level "dunders" (i.e. names with two leading and two trailing underscores) such as __all__, __author__, __version__, etc. should be placed after the module docstring but before any import statements except from __future__ imports. Python mandates that future-imports must appear in the module before any other code except docstrings.

@@ -707,7 +707,7 @@ if foo == 'blah': one(); two(); three() -

When to use trailing commas

+

When to Use Trailing Commas

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 print statement). For clarity, it is recommended to surround the latter in (technically redundant) parentheses.

@@ -895,7 +895,7 @@ Optional plotz says to frobnicate the bizbaz first.

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.

-

Type variable names

+

Type Variable Names

Names of type variables introduced in PEP 484 should normally use CapWords @@ -923,7 +923,7 @@ or contravariant behavior correspondingly. Examples

Modules that are designed for use via from M import * should use the __all__ 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”).

-

Function and variable names

+

Function and Variable Names

Function names should be lowercase, with words separated by underscores as necessary to improve readability.

@@ -933,7 +933,7 @@ or contravariant behavior correspondingly. Examples

mixedCase is allowed only in contexts where that’s already the prevailing style (e.g. threading.py), to retain backwards compatibility.

-

Function and method arguments

+

Function and Method Arguments

Always use self for the first argument to instance methods.

@@ -963,7 +963,7 @@ or contravariant behavior correspondingly. Examples

Constants are usually defined on a module level and written in all capital letters with underscores separating words. Examples include MAX_OVERFLOW and TOTAL.

-

Designing for inheritance

+

Designing for Inheritance

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.

@@ -1004,7 +1004,7 @@ or contravariant behavior correspondingly. Examples

-

Public and internal interfaces

+

Public and Internal Interfaces

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.