Changes between Version 80 and Version 81 of DeveloperGuidelines/Py_2_3

Timestamp:

07/24/19 08:24:37 (6 years ago)

Author:

Dominic König

Comment:

--

DeveloperGuidelines/Py_2_3

@@ -32 +32 @@
 }}}
 
+=== Avoid overriding built-ins and wildcard-imports ===
+
+Except where it is deliberate, we should avoid to use the names of built-in functions or types as variable names.
+
+Overriding a built-in function/type can - depending on scope - have adverse side-effects, which can then be very hard to trace back to a cause.
+
+Example:
+
+{{{#!python
+# Somewhere at the top of the module
+range = lambda x, y: (x, y)
+
+...
+
+# Somewhere further down in the module
+class Example(object):
+
+    def __init__(self, maximum):
+
+        self.indexes = [x for x in range(0, maximum)]
+
+# Doesn't crash, but doesn't behave as expected either:
+#   my_example.indexes should be [0, 1, 2, 3, 4], but instead it is (0, 5)
+my_example = Example(5)
+}}}
+
+The developer of the Example-class will find it difficult to understand why it doesn't work as expected - so we should avoid such situations.
+
+Python-3 introduces some new built-in names (e.g. "input"), so this needs extra care. A good strategy is to use a static code checker (e.g. pylint) to detect overrides, or to use an editor that highlights built-in names right away.
+
+A very tricky part of this are '''wildcard-imports''' like {{{from dateutil.rrule import *}}} - these wildcard imports can (unintentionally) override built-ins without that being obvious (dateutil.rrule overrides range, for instance). Therefore, we should avoid all wildcard-imports, except from internal modules (e.g. {{{from s3 import *}}}) where we have control over what they expose and what not.
 === Use as-syntax for catching exceptions ===