Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #85006
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Subject | Re: CSV and number formats |
| Date | 2015-02-01 11:46 -0500 |
| Organization | IISS Elusive Unicorn |
| References | <maki32$iav$1@ger.gmane.org> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.18363.1422809201.18130.python-list@python.org> (permalink) |
On Sun, 1 Feb 2015 08:45:54 +0200, "Frank Millman" <frank@chagford.com>
declaimed the following:
>If it is negative, it appears as '+00000-21.45'
>
>Predictably, decimal.Decimal does not like this.
>
>Is this a recognised format, and is there a standard way of parsing it? If
>not, I will have to special-case it, but I would prefer to avoid that if
>possible.
>
If it were showing as "0000021-45" I'd think leakage from a COBOL
decimal type (the COBOL-74 on my college computer normal numeric type was
BCD, and used the decimal place to hold the sign of the value).
Possibly a bug in data generation, or it may have been done as a signal
that this is not a transaction value... The limited exposure I have
(Quicken) is that the "starting value" for a reconciliation is carried over
from the last reconciliation and does not rely upon the starting value of
the transaction report (and any difference really means having to back up
to the prior period to figure out what went wrong).
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
Back to comp.lang.python | Previous | Next | Find similar | Unroll thread
Re: CSV and number formats Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-02-01 11:46 -0500
csiph-web