Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Python (http://www.velocityreviews.com/forums/f43-python.html)
-   -   Re: using split for a string : error (http://www.velocityreviews.com/forums/t956914-re-using-split-for-a-string-error.html)

Oscar Benjamin 01-25-2013 01:03 AM

Re: using split for a string : error
 
On 24 January 2013 11:35, Chris Angelico <rosuav@gmail.com> wrote:
>
> It's usually fine to have int() complain about any non-numerics in the
> string, but I must confess, I do sometimes yearn for atoi() semantics:
> atoi("123asd") == 123, and atoi("qqq") == 0. I've not seen a
> convenient Python function for doing that. Usually it involves
> manually getting the digits off the front. All I want is to suppress
> the error on finding a non-digit. Oh well.
>


I'm interested to know what the situations are where you want the
behaviour of atoi().

Personally, I consider the int() function too permissive because of
its behaviour in truncating non-integer numeric types. But then that's
because I'm always paranoid that the values of my precious numbers are
being changed without my knowledge. From my vantage point I really
can't see why the ambiguous behaviour of atoi() would actually be
desired by anyone (unless they were stuck using a language that made
string manipulation generally a bit awkward).


Oscar

Neil Cerutti 01-25-2013 02:04 PM

Re: using split for a string : error
 
On 2013-01-25, Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
> On 24 January 2013 11:35, Chris Angelico <rosuav@gmail.com> wrote:
>> It's usually fine to have int() complain about any
>> non-numerics in the string, but I must confess, I do sometimes
>> yearn for atoi() semantics: atoi("123asd") == 123, and
>> atoi("qqq") == 0. I've not seen a convenient Python function
>> for doing that. Usually it involves manually getting the
>> digits off the front. All I want is to suppress the error on
>> finding a non-digit. Oh well.

>
> I'm interested to know what the situations are where you want
> the behaviour of atoi().


Right. atoi is no good even in C. You get much better control
using the sprintf family. int would need to return a tuple of the
number it found plus the number of characters consumed to be more
useful for parsing.

>>> intparse("123abc")

(123, 3)

But that would make it might inconvenient for general use.

--
Neil Cerutti

Hans Mulder 01-25-2013 02:31 PM

Re: using split for a string : error
 
On 25/01/13 15:04:02, Neil Cerutti wrote:
> On 2013-01-25, Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
>> On 24 January 2013 11:35, Chris Angelico <rosuav@gmail.com> wrote:
>>> It's usually fine to have int() complain about any
>>> non-numerics in the string, but I must confess, I do sometimes
>>> yearn for atoi() semantics: atoi("123asd") == 123, and
>>> atoi("qqq") == 0. I've not seen a convenient Python function
>>> for doing that. Usually it involves manually getting the
>>> digits off the front. All I want is to suppress the error on
>>> finding a non-digit. Oh well.

>>
>> I'm interested to know what the situations are where you want
>> the behaviour of atoi().

>
> Right. atoi is no good even in C. You get much better control
> using the sprintf family.


I think you meant sscanf.

It's true that sscanf gives you more control. That being said,
sometimes the one option atoi gives you, just happens to be what
you need.

> int would need to return a tuple of the
> number it found plus the number of characters consumed to be more
> useful for parsing.
>
>>>> intparse("123abc")

> (123, 3)
>
> But that would make it might inconvenient for general use.


If the new function is nameed intparse, and the existing int
function remains available, then most use cases would be served
by int, and intparse would be available as a building block for
other use cases. For example atoi could be defined as:

def atoi(s): return intparse(s)[0]

intparse("xyz") should return (0, 0), and leave it to the caller
to decide whether a ValueError shoud be raised.


-- HansM





Joel Goldstick 01-25-2013 02:44 PM

Re: using split for a string : error
 
Don't forget to look at csv reader.

http://docs.python.org/2/library/csv.html


On Fri, Jan 25, 2013 at 9:31 AM, Hans Mulder <hansmu@xs4all.nl> wrote:

> On 25/01/13 15:04:02, Neil Cerutti wrote:
> > On 2013-01-25, Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
> >> On 24 January 2013 11:35, Chris Angelico <rosuav@gmail.com> wrote:
> >>> It's usually fine to have int() complain about any
> >>> non-numerics in the string, but I must confess, I do sometimes
> >>> yearn for atoi() semantics: atoi("123asd") == 123, and
> >>> atoi("qqq") == 0. I've not seen a convenient Python function
> >>> for doing that. Usually it involves manually getting the
> >>> digits off the front. All I want is to suppress the error on
> >>> finding a non-digit. Oh well.
> >>
> >> I'm interested to know what the situations are where you want
> >> the behaviour of atoi().

> >
> > Right. atoi is no good even in C. You get much better control
> > using the sprintf family.

>
> I think you meant sscanf.
>
> It's true that sscanf gives you more control. That being said,
> sometimes the one option atoi gives you, just happens to be what
> you need.
>
> > int would need to return a tuple of the
> > number it found plus the number of characters consumed to be more
> > useful for parsing.
> >
> >>>> intparse("123abc")

> > (123, 3)
> >
> > But that would make it might inconvenient for general use.

>
> If the new function is nameed intparse, and the existing int
> function remains available, then most use cases would be served
> by int, and intparse would be available as a building block for
> other use cases. For example atoi could be defined as:
>
> def atoi(s): return intparse(s)[0]
>
> intparse("xyz") should return (0, 0), and leave it to the caller
> to decide whether a ValueError shoud be raised.
>
>
> -- HansM
>
>
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>




--
Joel Goldstick
http://joelgoldstick.com


Neil Cerutti 01-25-2013 03:14 PM

Re: using split for a string : error
 
On 2013-01-25, Hans Mulder <hansmu@xs4all.nl> wrote:
>> Right. atoi is no good even in C. You get much better control
>> using the sprintf family.

>
> I think you meant sscanf.


Yes, thanks for knocking that huge chunk of rust off of me. ;)

--
Neil Cerutti


All times are GMT. The time now is 10:43 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.