Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #85006

Re: CSV and number formats

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)

Show all headers | View raw


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


Thread

Re: CSV and number formats Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-02-01 11:46 -0500

csiph-web