Re: Simplified Python caching

[Bruno Haible]

Hi Collin,

> I don't necessarily disagree with your point about the use of
> higher-order functions. I found decorator functions really confusing
> when I first started using Python

;-)

> I make an exception to this rule for decorators that are a part of the
> Python language or standard library. It is sort of hard to avoid them,
> in my opinion. As an example, all (I think?) of the functions in the
> GLInfo class can be static.

Yes, they _can_ be made static, but they can also be left as-is. And so,
as a developer, you start to spend time considering whether to make a
function static or not. That time is not well spent.

This is actually one of my main criticisms of C++: There are so many
different ways to code the same thing. How many kinds of functions are
there in C++? Last time I counted, there were 13:
  - plain function
  - inline plain function
  - constexpr plain function
  - static member function
  - pointer to plain function or static member function
  - member function
  - inline member function
  - virtual member function
  - pointer to member function
  - plain function with template parameters
  - static member function with template parameters
  - member function with template parameters
  - lambda (anonymous) function
When a programmer, each time they define a function, they consider which
of the 13 variants is suitable or the best, they spend time on a thing
that is not necessary for the functioning of their program.

> Another example is using 'classmethod' to define alternate
> constructors [3].

I agree that @classmethod is necessary for doing things that are common;
its use is not so problematic because it's for a _specific_ code pattern.

> The value I saw was less in the lines removed and more in the level of
> nesting removed. I think this make things more readable, but also deep
> nesting causes actual issues. For example the break in
> GLModuleTable.add_dummy() doesn't properly break the loop over all of
> the modules [4]. In shell we use 'break [n]' but Python doesn't
> support this since "Flat is better than nested." [5].

A workaround is to move the loop into a function, and then use
'return' from different locations.

Bruno