The Cafes

Here’s the coverage report on a recent PR of mine:

All modified and coverable lines are covered by tests ?

    Comparison is base (a765aef) 85.95% compared to head (fe02e1b) 85.95%.

Additional details and impacted files

@@            Coverage Diff            @@
##             master     #546   +/-   ##
=========================================
  Coverage     85.95%   85.95%           
  Complexity     3480     3480           
=========================================
  Files           230      230           
  Lines          8225     8225           
  Branches        960      960           
=========================================
  Hits           7070     7070           
  Misses          865      865           
  Partials        290      290           

Precisely identical. What happened? Did I change a comment? Well, no. In fact I added tests for
situations that were not currently covered, so why didn’t coverage increase?
Read the rest of this entry »

Reason 1: Mocking.

unittest.mock, Python’s mocking framework is so much more powerful than EasyMock, Mockito, or any other Java mock framework I’ve ever used. You can replace any method you like with essentially arbitrary code. No longer do you have to contort APIs with convoluted dependency injection just to mock out network connections or reproduce error conditions.

Instead you just identify a method by name and module within the scope of the test method. When that method is invoked, the actual code is replaced with the mock code. You can do this long after the class being mocked was written. Model classes do not need to participate in their own mocking. You can mock any method anywhere at any time, in your own code or in dependencies. No dependency injection required. You can even mock fields.

By contrast Java only lets you mock objects (not methods) and only when you have an available API to insert the mock in place of the real thing.

Reason 2: None is its own type.
Read the rest of this entry »

Reason 1: Strong, static, compile time typing

I used to take Pythonistas at their word that they didn’t actually need strong, static compile time type checking. That was before I spent over a year writing Python more or less full time.

I am constantly blocked by not understanding which variables have which types. I am frequently spelunking through many levels of code and popping open the debugger to find out what type a variable actually has when. Not having explicit, enforced types makes code far harder to understand and edit.

Corollary: var is very bad idea for Java and should not be used.

This is well known in the Python community today. PEP 484 is basically an admission that inline typing is a necessity for robust code, and Guido has admitted as much. It’s why large Python shops like Meta and Google have invested in tools like Pyre and Pytype to add strong typing to the language. These tools help, but they’re not as good as Java’s strong, reliable, static type declarations and type checking.

Reason 2: Checked exceptions
Read the rest of this entry »

How many times have you seen someone use a hammer to pound screws because they are a hammer expert, they are comfortable with hammers, they don’t know how to use a screwdriver, and they don’t want to take a week to learn how to use a screwdriver? Maybe not so much if you’re a carpenter, but if you’re a software developer it happens all the time.

I’ve noticed a common anti-pattern of defining declarative DSLs in Turing complete languages — specifically Python — to avoid the overhead of learning new syntax and tools, XML or JSON. Instead programmers define the DSL as a Python library and reuse the Python compiler with predictable results. Blaze/Bazel, Airflow, dataswarm, and many other projects have gone down this road. Gradle made the same mistake, only with Ruby instead of Python.

This is massive tech debt that causes massive problems (security, indeterminancy, irreproducibility) and has heavy cost. Never do this. It always leads to a huge expensive effort to redefine the language as its own thing (not Python) that still looks like Python, and the team ends up writing a complete parser in addition to everything else. XML is not that hard. Nut up and learn it.

Do not write declarative configs in a Turing complete language.
Do not invent Python subsets for config files. <cough>Starlark</cough>

Here’s another example of confirmations that shouldn’t happen:

Read the rest of this entry »