Recently, there have been a few proposals to change Python's syntax to make it easier to avoid break and continue statements.

The reasoning seems to be that many people are taught never to use break and continue, or to only have a single break in any loop. Some of these people are in fact forced to follow these rules for class assignments.

These rules are ludicrous. The stdlib has hundreds of break and continue statements. There are dozens of them in the official tutorial, the library reference docs, Guido's blogs, etc. The reasons for avoiding break and continue in other languages don't apply to Python, and many of the ways people use to avoid them don't even exist in Python. Using break and continue appropriately is clearly Pythonic.

The python-ideas community tracked these rules back to some misguided attempts to apply the rules from MISRA-C to Python.

It should be obvious that C and Python are very different languages, with different appropriate idioms, so applying MISRA-C to Python is insanely stupid. But, in case anyone doesn't get it, I've gone through the requirements and recommendations in MISRA-C 1998. By my count, more than half of them don't even mean anything in Python (e.g., rules about switch statements or #define macros), and more than half of the rest are bad rules that would encourage non-Pythonic code.

I've paraphrased them, both to avoid violating the copyright on the document, and to express them in Python terms:

• 8. req: No unicode, only bytes, especially in literals. (In other words, '\u5050' is bad; b'\xe5\x81\x90' is good.)
• 12. rcm: Don't use the same identifier in multiple namespaces. (For example, io.open and gzip.open should not have the same name, nor should two different classes ever have members or methods with the same name.)
• 13. rcm: Never use int when you can use long. (Only applies to Python 2.x.)
• 18. rcm: Suffix numeric literals. (Only applies to Python 2.x.)
• 20. req: Declare all variables and functions at the top of a module or function.
• 31. req: Use curly braces in all initializers. (Sorry, no lists allowed, just dicts and sets.)
• 33. req: Never use a user-defined function call on the right side of logical and/or.
• 34. req: Never use anything but a primary expression on either side of logical and/or.
• 37. req.: Never use bitwise operators on signed types (like int).
• 47. rcm: Never rely on operator precedence rules.
• 48. rcm: Use explicit conversions when performing arithmetic between multiple types.
• 49. rcm: Always test non-bool values against False instead of relying on truthiness.
• 53. req: All statements should have a side-effect.
• 57. req: No continue.
• 58. req: No break.
• 59. req: No one-liner if and loop bodies.
• 60. rcm: No if/elif without else.
• 67. rcm: Don't rebind the iterator in a for loop.
• 68. req: All functions must be at file scope.
• 69. req: Never use *args in functions.
• 70. req: No recursion.
• 82. rcm: Functions should have a single point of exit.
• 83. req: No falling off the end of a function to return None.
• 86. rcm: Always test function returns for errors.
• 104. req: No passing functions around.
• 118. req: Never allocate memory on the heap.
• 119. req: Never rely on the errno in an OSError (or handle FileNotFoundError separately, etc.).
• 121. req: Don't use locale functions.
• 123. req: Don't use signals.
• 124. req: Don't use stdin, stdout, etc., including print.
• 126. req: Don't use sys.exit, os.environ, os.system, or subprocess.*.
• 127. req: Never use Unix-style timestamps (e.g., time.time()).