On 09/11/2016 21:25, breamore...@gmail.com wrote:
On Wednesday, November 9, 2016 at 7:34:41 PM UTC, BartC wrote:
However according to your mindset nothing matters provided it's fast,
> accuracy does not matter to users.
Hence your recent comment on another thread about converting invalid integer entries into zero.
That's by design. And it's not unprecedented; using C's 'atoi()' function (convert a string to an integer), then inputs of "" and "ABC" both return 0. Input of "123ABC" returns 123.
And in the context that was being discussed, it was desired that hitting end-of-line while attempting to read more items should return null values such as 0, 0.0 or "".
For any more refined behaviour, values can be read differently (read as strings then converted with routines that do more validation).
Effectively, the conversion looks at the entire line buffer contents remaining, and converts the first integer encountered, if any, then removes that and any terminator from the buffer.
If I try something like that in Python, trying to convert an integer at the beginning of a string, it fails: int("123,456"), int("123 456"), int("63924 the"). It will need processing first so that the parameter comprises only the thing we're trying to read.
Anyway the comparison between Python and that particular /lower-level/ language is moot as Python apparently doesn't have a way of directly reading items from an input line, either from a console or from a file.
You have to read a line as one string then apply DIY conversions. Which the other language could equally do.
So it's a detail. The other language could also have chosen to use exceptions to signal such events (no integer following, end of input, invalid terminator etc). I chose to keep it simple and to make it work the same way it's always done.
-- Bartc -- https://mail.python.org/mailman/listinfo/python-list
