This implicitly ends with return None.
Prefer an explicit return TrueFalse.
Adopt mypy, and annotate this as returning ...) -> bool:
This implicitly ends with return None.
Prefer an explicit return True.
Adopt mypy, and annotate this as returning ...) -> bool:
This implicitly ends with return None.
Prefer an explicit return False.
Adopt mypy, and annotate this as returning ...) -> bool:
GvR was right when he anticipated the := walrus
operator would encourage folks to write hard-to-read code.
Please resist the temptation.
class Range:
processed = deque()
stack = deque()
What is going on here?!? Singletons? With no motivation in the docs or comments? We need to understand why There Can Be Only One computation in progress.
Perhaps another class should hold these?
Or they should be local to discretize()
and passed around as parameters?
Please return a single type, such as bool on a predicate.
Not because it makes things easier on the machine,
but because it makes it easier for the Gentle Reader to see your meaning.
def join(self, ini, fin):
if ini <= self.fin + 1:
self.fin = fin
return True
This implicitly ends with return None.
Prefer an explicit return True.
Adopt mypy, and annotate this as returning ...) -> bool:
Similarly for the return value of update().
Both methods should """document""" that they are predicates,
as the names do not spell that out at all.
I would typically expect join() to return a str
which combines its arguments, and update() to
be void, evaluated for side effects.
elif ini <= self.fin and not (ignore := self.update(ini, fin, data)):
self.prepend(ini)
if not ignore:
No.
Assign ignore, and then inspect it.
It's an important state variable which the following if not inspects.
Don't bury the state change in the 2nd argument of and.
It's only assigned when ini <= self.fin.
You're being too tricky.
Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?
—- Kernighan & Plauger, The Elements of Programming Style, chapter 2
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
Plus, you're making it hard to recruit new graduates to your team who are willing and able to maintain your code.
In contrast, this line is easy to reason about:
ignore = self.cover(fin) or self.join(ini, fin)
Consider renaming ignore, and/or commenting on what
return not ignore means to the caller.
Does every method need a """docstring"""? No.
But this one really does, given how vacuous
identifiers like process or do_it are.
Input ranges must be sorted, so consider offering a method or option which verifies that.