From 4025990529e2d98908df1cf8d72627e4d70e9658 Mon Sep 17 00:00:00 2001 From: bhumijgupta Date: Sat, 29 Jun 2019 16:05:35 +0530 Subject: [PATCH 1/9] Migrated changes made in https://github.com/python/peps/commit/a81f56f75187b31f9ad114ead0eb8c52dfc09f14 --- index.html | 33 ++++++++++++++++++++++++++++++++- 1 file changed, 32 insertions(+), 1 deletion(-) diff --git a/index.html b/index.html index b30de2b..23e4e95 100644 --- a/index.html +++ b/index.html @@ -1235,7 +1235,7 @@ if not len(seq): + +

Variable annotations

+ + +

PEP 526 introduced variable annotations. The style recommendations for them are similar to those on function annotations described above:

+ +

Footnotes

From df27e7f2afe3bf4afecedc418c46fd05b05f1951 Mon Sep 17 00:00:00 2001 From: bhumijgupta Date: Sat, 29 Jun 2019 16:15:26 +0530 Subject: [PATCH 2/9] Migrate changes made in https://github.com/python/peps/commit/108b2f9da2b7f04c78cdf4520b36735f4d26d184 --- index.html | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/index.html b/index.html index 23e4e95..a50f6fe 100644 --- a/index.html +++ b/index.html @@ -371,7 +371,7 @@ result = some_function_that_takes_arguments(

Make sure to indent the continued line appropriately.

-

Should a line break before or after a binary operator?

+

Should a Line Break Before or After a Binary Operator?

For decades the recommended style was to break after binary operators. But this can hurt readability in two ways: the operators tend to get scattered across different columns on the screen, and each operator is moved away from its operand and onto the previous line. Here, the eye has to do extra work to tell which items are added and which are subtracted:

@@ -447,9 +447,9 @@ import sys

Imports should be grouped in the following order:

    -
  1. standard library imports
    2. -
  2. related third party imports
    3. -
  3. local application/library specific imports
    4. +
  4. Standard library imports
    5. +
  5. Related third party imports
    6. +
  6. Local application/library specific imports

You should put a blank line between each group of imports.

@@ -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.

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

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.

-

Public attributes are those that you expect unrelated clients of your class to use, with your commitment to avoid backward incompatible changes. Non-public attributes are those that are not intended to be used by third parties; you make no guarantees that non-public attributes won’t change or even be removed.

+

Public attributes are those that you expect unrelated clients of your class to use, with your commitment to avoid backwards incompatible changes. Non-public attributes are those that are not intended to be used by third parties; you make no guarantees that non-public attributes won’t change or even be removed.

We don’t use the term “private” here, since no attribute is really private in Python (without a generally unnecessary amount of work).

@@ -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.

From 9c135231c3b30245fbfd9f3b4c1d505911a67b7f Mon Sep 17 00:00:00 2001 From: bhumijgupta Date: Sat, 29 Jun 2019 16:26:29 +0530 Subject: [PATCH 3/9] Migrate changes made in https://github.com/python/peps/commit/3714aa1cefd115ff05b91e2acd0c5d50fba0fc4e --- index.html | 26 +++++++++++--------------- 1 file changed, 11 insertions(+), 15 deletions(-) diff --git a/index.html b/index.html index a50f6fe..be9812d 100644 --- a/index.html +++ b/index.html @@ -239,7 +239,7 @@ ul > li { -

Code lay-out

+

Code Lay-out

Indentation

@@ -429,7 +429,7 @@ income = (gross_wages
    -

  • Imports should usually be on separate lines, e.g.:

    +

  • Imports should usually be on separate lines

    Yes:

    import os
@@ -474,7 +474,7 @@ from .sibling import example
    from myclass import MyClass
 from foo.bar.yourclass import YourClass
    -

    If this spelling causes local name clashes, then spell them :

    +

    If this spelling causes local name clashes, then spell them explicitly :

    import myclass
 import foo.bar.yourclass
    @@ -486,12 +486,10 @@ 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.

-

For example:

- 
"""This is the example module.
 
 This module does stuff.
@@ -786,7 +784,7 @@ initialize(FILES, error=True,)
  • Write docstrings for all public modules, functions, classes, and methods. Docstrings are not necessary for non-public methods, but you should have a comment that describes what the method does. This comment should appear after the def line.

    • -

  • PEP 257 describes good docstring conventions. Note that most importantly, the """ that ends a multiline docstring should be on a line by itself, e.g.:

    +

  • PEP 257 describes good docstring conventions. Note that most importantly, the """ that ends a multiline docstring should be on a line by itself:

    """Return a foobang
 
@@ -901,7 +899,7 @@ Optional plotz says to frobnicate the bizbaz first.
 
    Names of type variables introduced in PEP 484 should normally use CapWords
 preferring short names: T, AnyStr, Num. It is recommended to add
 suffixes _co or _contra to the variables used to declare covariant
-or contravariant behavior correspondingly. Examples
    
+or contravariant behavior correspondingly.
    
 
   
    from typing import TypeVar
 
@@ -963,7 +961,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.
    
@@ -1079,8 +1077,6 @@ or contravariant behavior correspondingly. Examples
    
 
 
  • When catching exceptions, mention specific exceptions whenever possible instead of using a bare except: clause.
    
 
-
    For example, use:
    
-
 
    try:
     import platform_specific_module
 except ImportError:
@@ -1130,7 +1126,7 @@ except KeyError:
 
 
  • When a resource is local to a particular section of code, use a with statement to ensure it is cleaned up promptly and reliably after use. A try/finally statement is also acceptable.
    • 
 
-
  • Context managers should be invoked through separate functions or methods whenever they do something other than acquire and release resources. For example:
    
+
  • Context managers should be invoked through separate functions or methods whenever they do something other than acquire and release resources.
    
 
 
    Yes:
    
 
@@ -1176,7 +1172,7 @@ def bar(x):
 
 
  • Use ''.startswith() and ''.endswith() instead of string slicing to check for prefixes or suffixes.
    
 
-
    startswith() and endswith() are cleaner and less error prone. For example:
    
+
    startswith() and endswith() are cleaner and less error prone.
    
 
 
 
    Yes:
    
@@ -1257,7 +1253,7 @@ if not len(seq):
    • 
 
 
 
-
    Variable annotations
    
+
    Variable Annotations
    
 
 
 
    PEP 526 introduced variable annotations. The style recommendations for them are similar to those on function annotations described above:
    
@@ -1274,7 +1270,7 @@ if not len(seq):
    • 
 
 class Point:
     coords: Tuple[int, int]
-    label: str = '<unknown>'
    + label: str = '<unknown>'

  • No:

    From c133f755af73331696c8a096bcee9524876778b0 Mon Sep 17 00:00:00 2001 From: bhumijgupta Date: Sat, 29 Jun 2019 16:38:06 +0530 Subject: [PATCH 4/9] Migrate changes made in https://github.com/python/peps/commit/acda0d1ddef5bc19c1f9410895d21555a9395726 --- index.html | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/index.html b/index.html index be9812d..c1eb259 100644 --- a/index.html +++ b/index.html @@ -630,18 +630,6 @@ x = x * 2 - 1 hypot2 = x * x + y * y c = (a + b) * (a - b)
    • -

  • Don’t use spaces around the = sign when used to indicate a keyword argument or a default parameter value.

    - -

    Yes:

    - -
    def complex(real, imag=0.0):
-    return magic(r=real, i=imag)
    - -

    No:

    - -
    def complex(real, imag = 0.0):
-    return magic(r = real, i = imag)
    • -

  • Function annotations should use the normal rules for colons and always have spaces around the -> arrow if present. (See Function Annotations below for more about function annotations.)

    Yes:

    @@ -654,7 +642,19 @@ def munge() -> AnyStr: ... 
    def munge(input:AnyStr): ...
 def munge()->PosInt: ...
    • -

  • When combining an argument annotation with a default value, use spaces around the = sign (but only for those arguments that have both an annotation and a default).

    +

  • Don’t use spaces around the = sign when used to indicate a keyword argument,or when used to indicate a default value for an unannotated function parameter.

    + +

    Yes:

    + +
    def complex(real, imag=0.0):
+    return magic(r=real, i=imag)
    + +

    No:

    + +
    def complex(real, imag = 0.0):
+    return magic(r = real, i = imag)
    • + +

  • When combining an argument annotation with a default value, however, do use spaces around the = sign:

    Yes:

    From 0c4a2e157421aa96d322c64ffd1317683b15bdb0 Mon Sep 17 00:00:00 2001 From: bhumijgupta Date: Sat, 29 Jun 2019 16:39:43 +0530 Subject: [PATCH 5/9] Migrate changes made in https://github.com/python/peps/commit/b487e29f03cba8c9e739fc8016fd8782c16e15bc --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index c1eb259..19cdc32 100644 --- a/index.html +++ b/index.html @@ -255,7 +255,7 @@ ul > li { foo = long_function_name(var_one, var_two, var_three, var_four) -# More indentation included to distinguish this from the rest. +# Add 4 spaces (an extra level of indentation) to distinguish arguments from the rest. def long_function_name( var_one, var_two, var_three, var_four): From 4ba803b6684b95b3a35848f15eaa8a0bff23743c Mon Sep 17 00:00:00 2001 From: bhumijgupta Date: Sat, 29 Jun 2019 16:42:22 +0530 Subject: [PATCH 6/9] Migrate changes made in https://github.com/python/peps/commit/7b72f683beff08112b6605c43d4b126a8db4d27f --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 19cdc32..f431db4 100644 --- a/index.html +++ b/index.html @@ -353,7 +353,7 @@ result = some_function_that_takes_arguments(

    The default wrapping in most tools disrupts the visual structure of the code, making it more difficult to understand. The limits are chosen to avoid wrapping in editors with the window width set to 80, even if the tool places a marker glyph in the final column when wrapping lines. Some web based tools may not offer dynamic line wrapping at all.

    -

    Some teams strongly prefer a longer line length. For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay to increase the nominal line length from 80 to 100 characters (effectively increasing the maximum length to 99 characters), provided that comments and docstrings are still wrapped at 72 characters.

    +

    Some teams strongly prefer a longer line length. For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay to increase the line length limit up to 99 characters, provided that comments and docstrings are still wrapped at 72 characters.

    The Python standard library is conservative and requires limiting lines to 79 characters (and docstrings/comments to 72).

    From ea897599a1d7448a572968273089bcbb3658f2ed Mon Sep 17 00:00:00 2001 From: bhumijgupta Date: Sat, 29 Jun 2019 16:43:29 +0530 Subject: [PATCH 7/9] Migrate changes made in https://github.com/python/peps/commit/2f8f1ec0ba92df5db85e9f78e7c2f422739ef1ec --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index f431db4..e68fd50 100644 --- a/index.html +++ b/index.html @@ -844,7 +844,7 @@ Optional plotz says to frobnicate the bizbaz first.
      -
    • _single_leading_underscore: weak “internal use” indicator. E.g. from M import * does not import objects whose name starts with an underscore.
      • +
    • _single_leading_underscore: weak “internal use” indicator. E.g. from M import * does not import objects whose name start with an underscore.

    • single_trailing_underscore_: used by convention to avoid conflicts with Python keyword, e.g.:

      From 86e8c9dd4a5ccbda0ae400a7118da8e863803402 Mon Sep 17 00:00:00 2001 From: bhumijgupta Date: Sat, 29 Jun 2019 16:44:55 +0530 Subject: [PATCH 8/9] Update revision to 2f8f1ec --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 273b042..2b87e29 100644 --- a/README.md +++ b/README.md @@ -25,7 +25,7 @@ Whenever the original PEP 8 at python.org gets updated we need to migrate these To migrate the latest changes from the original PEP 8 source do the following: -* Look at the [source control history for the original PEP 8](https://github.com/python/peps/commits/master/pep-0008.txt) and compare it with what's live on pep8.org. (As of 2019-06 we're tracking rev `e0436e9`.) +* Look at the [source control history for the original PEP 8](https://github.com/python/peps/commits/master/pep-0008.txt) and compare it with what's live on pep8.org. (As of 2019-06 we're tracking rev `2f8f1ec`.) * Apply the missing changes to `index.html` and create a pull-request to get them reviewed and live on pep8.org From f4d1f3711136eacbc1910fbbc4a9f83ab27dc190 Mon Sep 17 00:00:00 2001 From: Devil Date: Mon, 29 Jul 2019 23:42:14 +0530 Subject: [PATCH 9/9] Resolved merge conflict *Renamed Lay-out to Layout --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index e68fd50..c0e02fd 100644 --- a/index.html +++ b/index.html @@ -239,7 +239,7 @@ ul > li { -

      Code Lay-out

      +

      Code Layout

      Indentation