Argh! Who thought Black should be automatically applied to lines in the IPython CLI?
The makes it less useful for education purposes, less useful for interactive math, and annoying when it rewrites your input across multiple lines.
In a #Python course, if you want to demonstrate that print('hello') and print("hello") are the same, then too bad. The CLI rewrites both to use double quotes and the students can't see what you were demonstrating.
When doing math, you improve readability by grouping your terms as shown in PEP 8:
3*x**2 - 5*x + 10
However, the new #Ipython CLI immediately expands it to:
3 * x ** 2 - 5 * x + 10
Black's quotation rewrites are especially distracting in a REPL where it clearly conflicts the language's internal preferences:
In [11]: {"x": 10}
Out[11]: {'x': 10}
For teaching purposes, it is especially annoying to have in-line comments smushed to two spaces after the code ends. And more so, when it splits your input lines.
if n == 0: return 0 # 1st known case
if n == 1: return 1 # 2nd known case
return n * fact(n-1) # Recurse
It's no longer possible to show students how to use the semicolon to separate statements:
Yes, this can be turned off, but you have to get a whole classroom of mixed Windows, Mac, and Linux users to monkey through the steps to get back to a normal environment where you can see what you typed into the computer rather than what it wanted you to type.
Even if you usually like how Black formats your scripts and modules, why would you ever do this line by line in a CLI?
It wasn't long ago that IDLE became unusable for teaching. And now IPython decides to rewrite my inputs so that students never see what I actually typed.
>>> from sympy import var
>>> var('x')
x
>>> ((3*x + 5) * (2*x - 4)).expand()
6*x**2 - 2*x - 20
I'm not sure what to say to defuse this thread.
Black is good product. IPython is a good tool. The people involved are good developers.
Ideally, let's focus on the problem rather the people. The main thread identifies five specific usability problems. That's what we care about.
The original PR had 32 downvotes but was pushed despite opposition from those aware of the impending change. Unfortunately, they didn't give examples so it may have been easy to dismiss their concerns.
#Python's structural pattern matching is new, so the best practices aren't yet known.
Just added to my personal list: Add a comment or assertion noting when case ordering is important.
Otherwise, a future maintainer will be bitten by the illusion of case independence.
1 of 4
match x:
case bool():
...
case int():
assert not isinstance(x, bool)
...
case Counter():
...
case dict():
assert not isinstance(x, Counter)
case _:
raise TypeError
2 of 4
match sales_report:
case {'dept': dept, 'holiday': event}:
# Holiday case must precede other cases
...
case {'dept': 'shoes'}:
...
case {'dept': 'hats'}:
...
#Python tip: Structural pattern matching works with abstract base classes such as: Contains, Hashable, Iterable, Iterator, Reversible, Generator, Sized, Callable, and Collection.
match obj:
case Hashable:
...
Matching a collection ABC is preferable to looking for the required methods directly.
The complication is that those methods may be present but could be set to None.
The ABCs listed above handle the None checks for you.
For more complex ABCs, such as Sequence and Mapping, the presence of the required methods is insufficient.
The object's class needs to either inherit from the ABC or be registered with the ABC.
With dataclasses, you get nice attribute access, error checking, a name for the aggregate data, and a more restrictive equality test. All good things.
Dicts are at the core of the language and are interoperable with many other tools: json, **kw, …
@yera_ee Dicts have a rich assortment of methods and operators.
People learn to use dicts on their first day.
Many existing tools accept or return dicts.
pprint() knows how to handle dicts.
Dicts are super fast.
JSON.
Dicts underlie many other tools.
@yera_ee Embrace dataclasses but don't develop an aversion to dicts.
Python is a very dict centric language.
Mentally rejecting dicts would be like developing an allergy to the language itself. It leads to fighting the language rather than working in harmony with it.