Traling junk in string.atof (RE: array constructor)

[Ken Seehof]

I remember reading about a language that generates absolutely no errors of
any kind.  Maybe it was called Nobol; I don't remember.  The idea is that
a syntax error indicates a failure in the language to provide semantics for a
potentially useful idiom.

That's not Python.  I vote for leaving things like string.atof() the way they
are.

- Ken

Tim Peters wrote:

> [Tom Holroyd]
> > ...
> > While I'm here, string.atof() and float() both barf on "123.45," while the
> > C atof() doesn't.  A quick check of the code (stropmodule.c) shows that
> > there is an explicit check for junk at the end of the string.
>
> Right.
>
> > Is there some reason for this besides just being annoying?  :-)
>
> Yes, but simply because "123.45," does not match the syntax for "a number".
> The trailing comma may be harmless, or it may indicate your program has
> gotten lost, or that your data has gotten corrupted, or that your data was
> ill-formed to begin with.  Python refuses to guess that it makes sense,
> because it has no way to *know*, and guessing "ya, OK" errs in the wrong
> direction (screws *you* the most).  Python takes this attitude all over the
> place, btw -- string.atof is just one instance of it.
>
> I'm curious how you ended up with a numeric string with a trailing comma to
> begin with.  For example, if you're reading lines of comma-separated values,
> the natural idiom is
>
>     numbers = map(float, string.split(line, ","))
>
> which gets rid of the commas explicitly.
>
> > I vote to remove it.
>
> I'll set up a web page to keep a running tally <wink>.
>
> better-careful-coding-than-endless-debugging-ly y'rs  - tim