This makes methods like _replace available in real code, and caught the
bug where we can't use @functools.lru_cache with Transaction arguments,
because they're unhashable due to their mutable members.
This gets closer to our real intentions: anything that checks link
metadata should check rt-id. MetaRepoLinks is the exception, not
the rule, in ignoring rt-id.
Unfortunately this is becoming more trouble than it's worth as we
call more and more untyped Beancount functions.
disallow_untyped_defs provides most of the value of what we really
want here, so go ahead and turn this off.
This is something reporting tools will want a lot. This will make it
easier for them to look at just postings without worrying about the
parent transaction.
See docstring for full rationale. This greatly reduces the need for other
plugin code to handle the case of `post.units.number is None`, eliminating
the need for entire methods and letting it do plain numeric comparisons.
The main impetus of this change is to rename accounts that were outside
Beancount's accepted five root accounts, to move them into that
structure. This includes:
Accrued:*Payable: → Liabilities:Payable:*
Accrued:*Receivable: → Assets:Receivable:*
UneanedIncome:* → Liabilities:UnearnedIncome:*
Note the last change did inspire in a change to our validation rules. We no
longer require income-type on unearned income, because it's no longer
considered income at all. Once it's earned and converted to an Income
account, that has an income-type of course.
This did inspire another rename that was not required, but
provided more consistency with the other account names above:
Assets:Prepaid* → Assets:Prepaid:*
Where applicable, I have generally extended tests to make sure one of each
of the five account types is tested. (This mostly meant adding an Equity
account to the tests.) I also added tests for key parts of the hierarchy,
like Assets:Receivable and Liabilities:Payable, where applicable.
As part of this change, Account.is_real_asset() got renamed to
Account.is_cash_equivalent(), to better self-document its purpose.
Because these are the classes that get instantiated many times while
iterating transactions, the performance benefit of defining __slots__
is worth the development overhead.
The main motivation for this change is to make sure that higher-level
code deals with the fact that self.units.number can be None, and has
an easy way to do so.
I'm not sure all our code is *currently* doing the right thing for this
case, because I'm not sure it will ever actually come up. It's possible
that earlier Beancount plugins fill in decimal amounts for postings
that are originally loaded with self.units.number=None. I'll have to see
later whether this case comes up in reality, and then deal with it if so.
For now the safest strategy seems to be that most code should operate
when self.units.number is None.
Our version of Posting is interface-compatible with Beancount's,
but makes stronger guarantees about the data types for our
higher-level code to rely on.
As I'm pushing to reimplement payment-report/income-report, I see query and
reporting tools will want easy access to these kinds of views, so here it
starts.
