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

Groups > comp.lang.python > #37643 > unrolled thread

Re: using split for a string : error

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: using split for a string : error Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-01-25 01:03 +0000
    Re: using split for a string : error Neil Cerutti <neilc@norwich.edu> - 2013-01-25 14:04 +0000
      Re: using split for a string : error Hans Mulder <hansmu@xs4all.nl> - 2013-01-25 15:31 +0100
        Re: using split for a string : error Joel Goldstick <joel.goldstick@gmail.com> - 2013-01-25 09:44 -0500
        Re: using split for a string : error Neil Cerutti <neilc@norwich.edu> - 2013-01-25 15:14 +0000

#37643 — 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

[toc] | [next] | [standalone]

#37663

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

[toc] | [prev] | [next] | [standalone]

#37670

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

[toc] | [prev] | [next] | [standalone]

#37671

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#37672

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web