Round-Tripping guarantee and a pad directive

[Chary Chary]

Martin,

correct me if I am wrong, but I think the beancount's pad directive conflicts with the Round-Tripping guarantee, the way it is described here: 

https://docs.google.com/document/d/1QftxNvQPdH-MikMBHupftU6F4IsNZP5FlFh1LCbVgk8/edit#heading=h.qs8b7mcsjj82

In particular, Beancount offers the guarantee that the output of the printer should always be parseable and should result in the same data structure when read back in. (It should be considered a bug if that is not the case.)

I think it may be worth mentioning this in the documentation

[Daniele Nicolodi]

On 18/08/24 21:26, Chary Chary wrote:
> Martin,

It is weird to use a public mailing list to address a single person.

Are you expecting only Martin to answer?

> correct me if I am wrong, but I think the beancount's *pad *directive
> conflicts with the *Round-Tripping guarantee*, the way it is described

> here:
> https://docs.google.com/document/d/1QftxNvQPdH-MikMBHupftU6F4IsNZP5FlFh1LCbVgk8/edit#heading=h.qs8b7mcsjj82
>
> In particular, Beancount offers the guarantee that the output of the
> printer should always be parseable and should result in the same data
> structure when read back in. (It should be considered a bug if that is
> not the case.)
>
> I think it may be worth mentioning this in the documentation

I don't understand what you mean.

The property described there holds true:

>>> from beancount.parser import parser, printer
>>> entries, errors, options = parser.parse_string(
... 2024-08-17 open Assets:Foo
...
... 2024-08-18 pad Assets:Foo Equity:Opening-Balances
... ''')
>>> printer.print_entries(entries)
2024-08-17 open Assets:Foo

2024-08-18 pad Assets:Foo Equity:Opening-Balances

Cheers,
Dan

[Eric Altendorf]

On Sun, Aug 18, 2024 at 12:42 PM Daniele Nicolodi <dan...@grinta.net> wrote:

On 18/08/24 21:26, Chary Chary wrote:
> Martin,

It is weird to use a public mailing list to address a single person.

Are you expecting only Martin to answer?

I disagree, there are many situations where a communication is intended primarily for one individual to respond to, but which is open to responses from others (as happened here), and especially where the response from the directee is likely of interest to the broader community.

I think it's a bit weird to call someone out for doing this :)

> correct me if I am wrong, but I think the beancount's *pad *directive
> conflicts with the *Round-Tripping guarantee*, the way it is described
> here:
> https://docs.google.com/document/d/1QftxNvQPdH-MikMBHupftU6F4IsNZP5FlFh1LCbVgk8/edit#heading=h.qs8b7mcsjj82
>
> In particular, Beancount offers the guarantee that the output of the
> printer should always be parseable and should result in the same data
> structure when read back in. (It should be considered a bug if that is
> not the case.)
>
> I think it may be worth mentioning this in the documentation

I don't understand what you mean.

The property described there holds true:

 >>> from beancount.parser import parser, printer
 >>> entries, errors, options = parser.parse_string(
... 2024-08-17 open Assets:Foo
...
... 2024-08-18 pad Assets:Foo Equity:Opening-Balances
... ''')
 >>> printer.print_entries(entries)
2024-08-17 open Assets:Foo

2024-08-18 pad Assets:Foo Equity:Opening-Balances

Cheers,
Dan

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/0c5c7060-cde1-4386-b1ec-1a1fa21047dc%40grinta.net.

[Martin Blais]

It's possible there's a bug.

The newer implementation I had started in C++ was better in that way. I think when I restart this I should make the output of the parser contain even the comments and be able to be edited and used to regenerate the file, and the output of the interpolation and booking (which runs on that data structure) will be a distinct data structure with no syntax whatsoever. This will be better defined. Right now it's just using this set of Python objects that are the same between the parser's output and the final output, with different sets of guarantees... that's not great.

--

You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/0873ad88-48d7-4694-b7cf-3317599b3b9bn%40googlegroups.com.

[Chary Chary]

On Sunday, August 18, 2024 at 9:42:16 PM UTC+2 dan...@grinta.net wrote:

On 18/08/24 21:26, Chary Chary wrote:
> Martin,

It is weird to use a public mailing list to address a single person.

Are you expecting only Martin to answer?

Agreed, I should not have called a single person for the question, where many can possibly answer

 

[Chary Chary]

On Sunday, August 18, 2024 at 9:42:16 PM UTC+2 dan...@grinta.net wrote:

I don't understand what you mean.

What I mean, is that pad statement causes beancount to insert a padding transaction

Such code

2024-01-01 * "Initial balance"

    Assets:Bank                 1000 EUR

    Equity:StartingBalance

2024-01-09 pad Assets:Bank Expenses:Misc

2024-01-10 balance Assets:Bank 500 EUR

Gets converted to such code

2024-01-01 * "Initial balance" Assets:Bank 1000 EUR Equity:StartingBalance -1000 EUR 2024-01-09 open Expenses:Misc 2024-01-09 pad Assets:Bank Expenses:Misc 2024-01-09 P "(Padding inserted for Balance of 500 EUR for difference -500 EUR)" Assets:Bank -500 EUR Expenses:Misc 500 EUR 2024-01-10 balance Assets:Bank 500 EUR

It all works as designed, but I thought that it conflicts a bit with the documentation.

However now, having read this one again, I think, that the Round-Tripping guarantee in the documentation is applicable to a single transaction, not to the whole ledger, and then it is fine

 

[Daniele Nicolodi]

On 19/08/24 09:51, Chary Chary wrote:
> On Sunday, August 18, 2024 at 9:42:16 PM UTC+2 dan...@grinta.net wrote:
>
> I don't understand what you mean.
>

> What I mean, is that *pad *statement causes beancount to insert a
> padding transaction

I think there is a fundamental misunderstanding.

The statement you quote from the documentation says that the
serialization of the ledger to file (implemented in the
beancount.parser.printer Python module) is read back by the beancount
parser (implemented in the beancount.parser.parser Python module)
resulting in the same data structure.

This statement is true also in the case of "pad" directives, as proven
with the code in my other message. There is nothing special done with
"pad" directives in the parser.

It is not the parser that adds the transactions that implement the
padding accordingly to the "pad" and "balance" entries in the ledger.
This job is done by the booking code. There are many other
transformations done by the booking code (the main one being completing
postings in the transactions adding the inferred amounts and prices).

Cheers,
Dan

[Daniele Nicolodi]

On 18/08/24 22:21, Eric Altendorf wrote:
> On Sun, Aug 18, 2024 at 12:42 PM Daniele Nicolodi <dan...@grinta.net
> <mailto:dan...@grinta.net>> wrote:
>
> On 18/08/24 21:26, Chary Chary wrote:
> > Martin,
>
> It is weird to use a public mailing list to address a single person.
>
> Are you expecting only Martin to answer?
>
>
> I disagree, there are many situations where a communication is intended
> primarily for one individual to respond to, but which is open to
> responses from others (as happened here), and especially where the
> response from the directee is likely of interest to the broader community.
>
> I think it's a bit weird to call someone out for doing this :)

Addressing a question to a specific individual implies that only they
are likely to be able to answer, or that an answer from them is preferred.

It is very dismissive of the contributions of others.

The reason why I pointed this out is because it lowers my motivation to
answer to queries on the mailing list. As this is not the first time
that similar openings in messages to the mailing list, I thought that
expressing my distaste for this would be better than stopping to answer
messages that start like this.

Cheers,
Dan