Hi Martin,
thank you for your answer. I read the threads you referring to, and I
agree with you that having time information attached to directives
introduces a lot of complication without much benefits. I don't have an
usecase that requires it.
What I was trying to do was to have a less surprising behavior of the
ingest machinery. I have been surprised twice writing importers: the
first time when using datetime classes did not raise an error but
resulted in an invalid benacount file; the second time when I found that
entries are sorted on a key including the line number.
On 01/12/2018 18:59, Martin Blais wrote:
> The problem with adding support for this (i.e., changing the sort order
> rule) is that there will be a lot of other things that start relying on it.
> So say, you change the schema to implicitly support date or datetime in
> the printer, as your patch suggests.
> Now some codes use date, some codes use datetime.
The code already supports any subclass of the date class that prints as
a date. In my importers I just use the class below (minus typos) as a
date field, and I get the sorting I want.
class datetime(datetime.datetime):
def __str__(self):
return '{:%Y-%m-%d}'.format(self)
> Someone uses the result of some importer code that puts datetime in this
> field - code that they didn't write, say - and passes it to some routine
> which fails on datetime. Boom! A bug. (Note that date's don't have a
> timezone and aren't subject to some of the timezone related issues.) Or
> say that person does arithmetic on the dates/datetimes. And it fails.
> That's unpredictable behavior. Then I'll get a request to fix that bug
> on an unsupported data type and someone will be surprised it's not
> supported officially.
I understand your point of view, but there is not much you can do to
stop people using Python language features to interact with beancount
library functions. Other than, well, rewrite it in another language.
> I've agreed with others in previous threads to addÂ
> 1. Support for the grammar to parse a time and to insert the time
> portion in some metadata field
I agree that extending the grammar to understand a type with date and
time information would be useful, but I don't see any advantage in
having it as part of the directive date in the file format, if it is not
used by beancount. Having a 'time' entry in the metadata could be
otherwise useful.
> 2. Adding an option to support specifying a secondary key for sorting
> This wouldn't break any of the current code by default.
Are you referring here to the sorting that is performed before
processing or before serialization in the ingest framework?
In the first case, I don't know what use case it solves, thus I cannot
comment. In the second case, I don't know what would be a good
interface to expose it.
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beancount/32d7f91e-84ab-fea3-e61c-3f0d3b83dae0%40grinta.net.
For more options, visit https://groups.google.com/d/optout.
