```python Bad theme={null} p = re.compile(r"^(?:(?:31(\/|-|\.)(?:0?[13578]|1[02]))\1|(?:(?:29|30)(\/|-|\.)(?:0?[13-9]|1[0-2])\2))(?:(?:1[6-9]|[2-9]\d)?\d{2})$|^(?:29(\/|-|\.)0?2\3(?:(?:(?:1[6-9]|[2-9]\d)?(?:0[48]|[2468][048]|[13579][26])|(?:(?:16|[2468][048]|[3579][26])00))))$|^(?:0?[1-9]|1\d|2[0-8])(\/|-|\.)(?:(?:0?[1-9])|(?:1[0-2]))\4(?:(?:1[6-9]|[2-9]\d)?\d{2})$") if p.match($dateString): handleDate($dateString) ``` ```python Fix theme={null} p = re.compile("^\d{1,2}([-/.])\d{1,2}\1\d{1,4}$") if p.match($dateString): dateParts = re.split(r"[-/.]", dateString) day = intval(dateParts[0]) month = intval(dateParts[1]) year = intval($dateParts[2]) // Put logic to validate and process the date based on its integer parts here ```

Jump statements, such as return, break and continue let you change the default flow of program execution, but jump statements that direct the control flow to the original direction are just a waste of keystrokes.

```python Bad theme={null} def redundant_jump(x): if x == 1: print(True) return # NonCompliant ``` ```python Fix theme={null} def redundant_jump(x): if x == 1: print(True) ```

Classes subclassing only \`unittest.TestCase are considered test cases, otherwise they might be mixins.

As classes subclassing unittest.TestCase will be executed as tests, they should define test methods and not be used as "abstract" parent helper. Methods within the class will be discovered by the test runner if their name starts with test. If a method intended to be a test does not respect this convention, it will not be executed.

This rule raises an issue when a method is not discoverable as a test and is never used within its test case class.

This rule will not raise if:

The method is called directly from another method.
The method overrides an existing one in unittest.TestCase (example: a tearDown\` method).

```python Bad theme={null} import unittest class MyTest(unittest.TestCase): def setUp(self): ... # OK (unittest.TestCase method) def something_test(self): ... # Noncompliant ``` ```python Fix theme={null} import unittest class MyTest(unittest.TestCase): def setUp(self): ... def test_something(self): ... ```

Functions that use yield are known as "generators". Before Python 3.3, generators cannot return values. Similarly, functions that use return cannot use yield. Doing so will cause a SyntaxError.

Either upgrade your version of Python to a version >= 3.3, or don’t use both return and yield in a function.

```python Bad theme={null} def adder(n): num = 0 while num < n: yield num num += 1 return num #Noncompliant ``` ```python Fix theme={null} ```

Python 3.9 introduced built-in generic types such as list\[T], dict\[T], set\[T] to make type hints more concise and easier to read. These built-in types have the same functionality as their counterparts in the typing module, but are more readable and idiomatic.

Using types such as typing.List is confusing in the presence of the already existing built-in types. This can also create inconsistencies when different parts of the codebase use different syntaxes for the same type.

```python Bad theme={null} import typing def print_numbers(numbers: typing.List[int]) None: for n in numbers: print(n) ``` ```python Fix theme={null} def print_numbers(numbers: list[int]) None: for n in numbers: print(n) ```

The \`**len** special method enables to define the length of an object. As such it should always return an integer greater than or equal to 0. When the len(...) builtin is called on an object, any other return type will raise a TypeError and a negative integer will raise a ValueError.

This rule raises an issue when a **len**\` method returns an expression which is not an integer greater than or equal to 0.

```python Bad theme={null} class A: def __len__(self): return 2.0 # Noncompliant len(A()) # This will raise "TypeError: 'float' object cannot be interpreted as an integer" class B: def __len__(self): return -2 # Noncompliant len(B()) # This will raise "ValueError: __len__() should return >= 0" ``` ```python Fix theme={null} class A: def __len__(self): return 2 len(A()) # This will return 2 ```

Server-side template injections occur in an application when the application retrieves data from a user or a third-party service and inserts it into a template, without sanitizing it first.

If an application contains a template that is vulnerable to injections, it is exposed to attacks that target the underlying rendering server.

A user with malicious intent can create requests that will cause the template to change its logic into unwanted behavior.

After creating the malicious request, the attacker can attack the servers affected by this vulnerability without relying on any prerequisites.

```python Bad theme={null} from flask import request, render_template_string @app.route('/example') def example(): username = request.args.get('username') template = f"

Hello {username}

" return render_template_string(template) # Noncompliant ``` ```python Fix theme={null} from flask import request, render_template_string @app.route('/example') def example(): username = request.args.get('username') template = "

Hello {{ username }}

" return render_template_string(template, username=username) ```

Data science and machine learning tasks make extensive use of random number generation. It may, for example, be used for:

Model initialization
- Randomness is used to initialize the parameters of machine learning models. Initializing parameters with random values helps to break symmetry and prevents models from getting stuck in local optima during training. By providing a random starting point, the model can explore different regions of the parameter space and potentially find better solutions.
Regularization techniques
- Randomness is used to introduce noise into the learning process. Techniques like dropout and data augmentation use random numbers to randomly drop or modify features or samples during training. This helps to regularize the model, reduce overfitting, and improve generalization performance.
Cross-validation and bootstrapping
- Randomness is often used in techniques like cross-validation, where data is split into multiple subsets. By using a predictable seed, the same data splits can be generated, allowing for fair and consistent model evaluation.
Hyperparameter tuning
- Many machine learning algorithms have hyperparameters that need to be tuned for optimal performance. Randomness is often used in techniques like random search or Bayesian optimization to explore the hyperparameter space. By using a fixed seed, the same set of hyperparameters can be explored, making the tuning process more controlled and reproducible.
Simulation and synthetic data generation
- Randomness is often used in techniques such as data augmentation and synthetic data generation to generate diverse and realistic datasets.

To ensure that results are reproducible, it is important to use a predictable seed in this context.

The preferred way to do this in numpy is by instantiating a Generator object, typically through numpy.random.default\_rng, which should be provided with a seed parameter.

Note that a global seed for RandomState can be set using numpy.random.seed or numpy.seed, this will set the seed for RandomState methods such as numpy.random.randn. This approach is, however, deprecated and Generator should be used instead. This is reported by rule S6711.

```python Bad theme={null} import numpy as np def foo(): generator = np.random.default_rng() # Noncompliant: no seed parameter is provided x = generator.uniform() ``` ```python Fix theme={null} import numpy as np def foo(): generator = np.random.default_rng(42) # Compliant x = generator.uniform() ```

The pandas library provides many ways to filter, select, reshape and modify a data frame. Pandas supports as well method chaining, which means that many DataFrame methods return a modified DataFrame. This allows the user to chain multiple operations together, making it effortless perform several of them in one line of code:

```python Bad theme={null} import pandas as pd schema = {'name':str, 'domain': str, 'revenue': 'Int64'} joe = pd.read_csv("data.csv", dtype=schema).set_index('name').filter(like='joe', axis=0).groupby('domain').mean().round().sample() ``` ```python Fix theme={null} import pandas as pd def foo(df: pd.DataFrame): return df.set_index('name').filter(like='joe', axis=0).groupby('team').mean().round().sort_values('salary').take([0]) # Noncompliant: too many operations happen on this data frame. ```

The **all** property of a module is used to define the list of names that will be imported when performing a wildcard import of this module, i.e. when from mymodule import \* is used.

In the following example:

```python Bad theme={null} # mymodule.py def foo(): ... def bar(): ... __all__ = ["foo"] ``` ```python Fix theme={null} from mymodule import my_func __all__ = ["unknown_func"] # Noncompliant: "unknown_func" is undefined ```

Prior to Python 3.12, generic type aliases were defined as follows:

```python Bad theme={null} from typing import TypeAlias, TypeVar _T = TypeVar("_T") MyAlias: TypeAlias = set[_T] ``` ```python Fix theme={null} type MyAlias[T] = set[T] ```

Python sides effects such as printing, mutating a list or a global variable, inside of a tensorflow\.function may not behave as expected. Because of the Rules of tracing, the execution of side effects will depend on the input values of the function and will execute only once per tracing.

```python Bad theme={null} import tensorflow as tf @tf.function def f(x): print("A side effect", x) f(1) # prints "A side effect 1" f(1) # does not print anything f(2) # prints "A side effect 2" ``` ```python Fix theme={null} import tensorflow as tf @tf.function def f(x): print("Printing", x) # Noncompliant print is a side effect ```

Unlike class and instance methods, static methods don’t receive an implicit first argument. Nonetheless naming the first argument self or clz guarantees confusion - either on the part of the original author, who may never understand why the arguments don’t hold the values he expected, or on that of future maintainers.

```python Bad theme={null} class MyClass: @staticmethod def s_meth(self, arg1, arg2): #Noncompliant # ... ``` ```python Fix theme={null} class MyClass: @staticmethod def s_meth(arg1, arg2): #Noncompliant # ... ```

for-in loops, yield from and iterable unpacking only work with iterable objects. In order to be iterable, an object should have either an \`**iter** method or a **getitem** method implementing the Sequence protocol.

When trying to iterate over an object which does not implement the required methods, a TypeError will be raised.

Below is an example of a basic implementation of a iterator with **iter**\`:

```python Bad theme={null} class IterExample(object): def __init__(self): self._values = [1,2,3,4] def __iter__(self): return iter(self._values) ``` ```python Fix theme={null} class GetItemExample(object): def __init__(self): self._values = [1,2,3,4] def __getitem__(self, item): return self._values[item] ```

There are no constants in Python, but when a variable is named with all uppercase letters, the convention is to treat it as a constant. I.e. to use it as a read-only variable, and not reassign its value.

Ignore this convention, and you run the risk of confusing other developers, particularly those with experience in other languages. This rule raises an issue each time a variable named with all uppercase letters is reassigned.

```python Bad theme={null} RESOURCE_NAME = 'foo' # ... RESOURCE_NAME = 'bar' # Noncompliant ``` ```python Fix theme={null} ```

Objects can be used as sequence indexes to access a specific element from the sequence, through the following syntax:

```python Bad theme={null} my_list = [1, 2, 3, 4] x = 1 print(my_list[x]) # This will print 2 ``` ```python Fix theme={null} my_list = [1, 2, 3, 4] x = 1 print(my_list[1:3]) # This will print [2, 3] ```

Variables, Classes and functions should not be undefined, otherwise the code will fail with a NameError.

```python Bad theme={null} my_var # Noncompliant (variable is never defined) def noncompliant(): foo() # Noncompliant MyClass() # Noncompliant ``` ```python Fix theme={null} from mod import my_var my_var def compliant(): foo = sum foo() class MyClass: pass MyClass() ```

Calling \`unittest methods assertEqual, assertNotEqual, assertIs or assertIsNot on objects of incompatible types will always fail or always succeed.

For methods assertEqual and assertNotEqual, arguments' types are incompatible if:

they are unrelated builtin types such as string and integer.

they are instances of unrelated classes which do not implement ++**eq**++ or ++**ne**++ (if a class implements one of these methods it could compare to any other type it wants).

As for methods assertIs and assertIsNot, if arguments' types are different it is not possible for them to point to the same object, thus assertIs will always fail and assertIsNot\` will always succeed.

```python Bad theme={null} import unittest class A(): ... class MyTest(unittest.TestCase): def test_something(self): a = A() mydict = {"x": a} self.assertEqual(a, "x") # Noncompliant self.assertIs(a, "x") # Noncompliant ``` ```python Fix theme={null} import unittest class A(): ... class MyTest(unittest.TestCase): def test_something(self): a = A() mydict = {"x": a} self.assertEqual(a, mydict["x"]) # OK self.assertIs(a, mydict["x"]) # OK ```

Dictionary unpacking allows you to pass the key-value pairs of a dictionary as keyword arguments to a function or merge dictionaries:

```python Bad theme={null} def foo(a, b): print(a+b) my_dict = {"a": 1, "b": 2} foo(**my_dict) # will print 3 ``` ```python Fix theme={null} class A: pass dict(**A()) # Noncompliant {'a': 10, 'b': 20, **A()} # Noncompliant ```

The operators \<> and != are equivalent. However, the \<> operator is considered obsolete in Python 2.7 and has been removed from Python 3. Therefore, it is recommended to use != instead.

```python Bad theme={null} return a <> b # Noncompliant: the operator "<>" is deprecated. ``` ```python Fix theme={null} return a != b ```

Through PEP 701, Python 3.12 lifts restrictions on how to construct "f-strings".

Prior to Python 3.12, it was not possible to reuse string quotes when nesting "f-strings". Therefore, the maximum level of nesting was:

```python Bad theme={null} f"""{f'''{f'{f"{1+1}"}'}'''}""" ``` ```python Fix theme={null} f"{f"{f"{f"{f"{f"{1+1}"}"}"}"}"}" ```

When calling a tensorflow\.function behind the scenes a ConcreteFunction is created everytime a new value is passed as argument. This is not the case with Python global variables, closure or nonlocal variables.

This means the state and the result of the tensorflow\.function may not be what is expected.

```python Bad theme={null} import tensorflow as tf @tf.function def addition(): return 1 + foo foo = 4 addition() # tf.Tensor(5, shape=(), dtype=int32): on this first step we obtain the expected result foo = 10 addition() # tf.Tensor(5, shape=(), dtype=int32): unexpected result of 5 instead of 11 ``` ```python Fix theme={null} import tensorflow as tf @tf.function def addition(): return 1 + foo foo = tf.Variable(4) addition() foo.assign(10) addition() ```

The raise a, b syntax is deprecated in Python 3, and should no longer be used.

```python Bad theme={null} try: if not is_okay: raise Exception, 'It\'s not okay' # Noncompliant except Exception as e: # ... ``` ```python Fix theme={null} try: if not is_okay: raise Exception('It\'s not okay') except Exception as e: # ... ```

Attempting to raise an object which does not derive from BaseException will raise a \`TypeError.

If you are about to create a custom exception class, note that custom exceptions should inherit from Exception, rather than BaseException.

BaseException is the base class for all built-in exceptions in Python, including system-exiting exceptions like SystemExit or KeyboardInterrupt, which are typically not meant to be caught. On the other hand, Exception is intended for exceptions that are expected to be caught, which is generally the case for user-defined exceptions. See PEP 352 for more information.

To fix this issue, make sure that the object you’re attempting to raise inherits from BaseException\`.

```python Bad theme={null} raise "Something went wrong" # Noncompliant: a string is not a valid exception class A: pass raise A # Noncompliant: A does not inherit from Exception ``` ```python Fix theme={null} class MyError(Exception): pass raise MyError("Something went wrong") raise MyError ```

Assigning a lambda to a variable is not inherently wrong or discouraged in Python. Lambdas are anonymous functions that can be useful for short and simple expressions or as function arguments. However, there are a few reasons why you might consider alternatives to assigning a lambda to a variable:

Readability and clarity: Lambdas can be concise, but they may become less readable as the expression or logic becomes more complex. For more complex or longer functions, using a regular named function defined with def can make the code more readable and self-explanatory.
Reusability: Lambdas are often used for one-off or small, isolated tasks. If you find that you need to reuse a piece of functionality in multiple places within your code or across modules, it is better to define a named function using def. This promotes code modularity and maintainability.
Documentation: Lambdas do not support docstrings, which are important for providing clear and comprehensive documentation for your functions. If you need to document the purpose, parameters, or behavior of a function, it is best to define a named function using def and include a docstring.
Debugging and error handling: Lambdas are anonymous functions, which means that when an error occurs during execution, the traceback will not provide a specific name associated with the lambda function. This can make it more challenging to identify and troubleshoot errors. Named functions defined with def provide more meaningful tracebacks.

Using a def statements rather than assigning lambdas to variable is also recommended by PEP8.

```python Bad theme={null} def foo(): multiply = lambda x, y: x * y # Noncompliant ``` ```python Fix theme={null} def foo(): def multiply(x, y): return x * y ... ```

Operators \`in and not in, also called "membership test operators", require that the right operand supports the membership protocol.

In order to support the membership protocol, a user-defined class should implement at least one of the following methods: **contains**, **iter**, **getitem**.

If none of these methods is implemented, a TypeError\` will be raised when performing a membership test.

```python Bad theme={null} myint = 42 if 42 in myint: # Noncompliant: integers don't support membership protocol ... class A: def __init__(self, values): self._values = values if "mystring" in A(["mystring"]): # Noncompliant: class A doesn't support membership protocol ... ``` ```python Fix theme={null} mylist = [42] if 42 in mylist: ... class MyContains: def __init__(self, values): self._values = values def __contains__(self, value): return value in self._values if "mystring" in MyContains(["mystring"]): ... # OR class MyIterable: def __init__(self, values): self._values = values def __iter__(self): return iter(self._values) if "mystring" in MyIterable(["mystring"]): ... # OR class MyGetItem: def __init__(self, values): self._values = values def __getitem__(self, key): return self._values[key] if "mystring" in MyGetItem(["mystring"]): ... ```

In NumPy, some built-in types such as int have aliases in the form of numpy.int. However, these aliases have been deprecated and should not be used anymore.

The following deprecated aliases should be replaced with their built-in alternatives:

Deprecated name	Equivalent built-in type
numpy.bool	bool
numpy.int	int
numpy.float	float
numpy.complex	complex
numpy.object	object
numpy.str	str
numpy.long	int
numpy.unicode	str

Deprecated name

Equivalent built-in type

numpy.bool

bool

numpy.int

int

numpy.float

float

numpy.complex

complex

numpy.object

object

numpy.str

str

numpy.long

int

numpy.unicode

str

```python Bad theme={null} import numpy as np def foo(): x = np.int(42) # Noncompliant: deprecated type alias ``` ```python Fix theme={null} import numpy as np def foo(): x = 42 # Compliant ```

When working with timezones in Python, it’s important to understand that the datetime.datetime constructor and pytz timezone objects handle timezones differently. This difference can lead to unexpected results if a pytz object is used as the tzinfo argument in the datetime.datetime constructor.

The datetime.datetime constructor expects a tzinfo object that is a subclass of the datetime.tzinfo base class. pytz timezone objects do provide this interface, but they implement it in a way that’s not fully compatible with datetime.datetime.

One key difference is how they handle historical changes in timezone offsets. The datetime module uses the IANA time zone database, which includes historical changes.

When you create a datetime object with a pytz timezone object as the tzinfo argument, it uses the earliest known offset for that timezone. This can lead to unexpected offsets, as the earliest known offset may not match the current or most commonly used offset for that timezone.

For example, if you were to use 'US/Eastern' as your timezone, you might expect the offset to be either -5 hours (Eastern Standard Time) or -4 hours (Eastern Daylight Time), depending on the time of the year. However, due to historical changes, the actual offset might be something different, like -4 hours and 56 minutes. This can lead to subtle bugs in your code, especially if you’re doing calculations with datetime objects.

Note that, when using Python 3.9 and later, it is recommended to use the zoneinfo package from the standard library over pytz.

```python Bad theme={null} import datetime import pytz dt = datetime.datetime(2022, 1, 1, tzinfo=pytz.timezone('US/Eastern')) # Noncompliant: 2022-01-01 00:00:00-04:56 ``` ```python Fix theme={null} import datetime import pytz dt = pytz.timezone('US/Eastern').localize(datetime.datetime(2022, 1, 1)) # OK: 2022-01-01 00:00:00-05:00 ```

Methods **enter** and **exit** make it possible to implement objects which can be used as the expression of a with statement:

```python Bad theme={null} with MyContextManager() as c : ... # do something with c ``` ```python Fix theme={null} c = MyContextManager() c.__enter__() try: ... # do something with c finally: c.__exit__() ```