scanf in python...?

[Grant Griffin]

Andrew Dalke wrote:
> 
> Tony Waterman wrote in message <39ebd839.159714 at news>...
> >Does python have any way to mimic scanf ?
> 
> http://www.python.org/cgi-bin/faqw.py?req=show&file=faq04.033.htp
> 
>  =========
> 
> Python FAQ Entry
> 
> 4.33. Is there a scanf() or sscanf() equivalent?
> 
> Not as such.
> For simple input parsing, the easiest approach is usually to split the line
> into whitespace-delimited words using string.split(), and to convert decimal
> strings to numeric values using string.atoi(), string.atol() or
> string.atof(). (Python's atoi() is 32-bit and its atol() is arbitrary
> precision.) If you want to use another delimiter than whitespace, use
> string.splitfield() (possibly combining it with string.strip() which removes
> surrounding whitespace from a string).

There's a subtle thing going on here that I think the FAQ entry should
be revised to explain.  In my own "scanf" journey (wherein I discovered
some of the many, non-obvious ways to do scanf <wink>), I have tended to
use "float()", "int()" etc. rather than "string.atof()" and
"string.atoi()".  To the uninitiated, that would be the more obvious
(and concise) approach.  But what about this?:

   Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32
   >>> int('0x13')
   Traceback (most recent call last):
     File "<stdin>", line 1, in ?
   ValueError: invalid literal for int(): 0x13

So "int" evidently can't figure out what "0x" means.  But what about
string.atoi()?

   >>> import string
   >>> string.atoi('0x13')
   Traceback (most recent call last):
     File "<stdin>", line 1, in ?
     File "c:\apps\python20\lib\string.py", line 215, in atoi
       return _int(s, base)
   ValueError: invalid literal for int(): 0x13

Durn.  It's no smarter than int().  Or _is_ it?  What if we gave it a
little hint? <<nudge nudge, wink wink>>...

   >>> string.atoi('0x13',16)
   19

Cool!  So it just seems to ignore the "0x" part.  Or _does_ it?...

   >>> string.atoi('0x13',10)
   Traceback (most recent call last):
     File "<stdin>", line 1, in ?
     File "c:\apps\python20\lib\string.py", line 215, in atoi
       return _int(s, base)
   ValueError: invalid literal for int(): 0x13

Nope--it seems to think it knows what "0x" means.  But for _some_
strange <<neurotic>> reason it wants us to _reassure_ it.  (I guess the
poor little thing just lacks self-confidence. <wink>)

Now, in 1.5.2, I seem to recall that "string.atoi()" allowed you to
specify the base, but "int()" didn't.  <<i dunno either>>

So let's just confirm that:

   Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on
win32
   >>> int('0x13',16)
   Traceback (innermost last):
     File "<stdin>", line 1, in ?
   TypeError: int requires exactly 1 argument; 2 given

Yup.  But in 2.0 we evidently can:

   >>> int('0x13',16)
   19

That's nice, Dear.

So, I would recommend to whomever is in charge of such things that the
FAQ answer at top be ammended to include the possible use of "float()"
and "int()" as alternatives to "string.atof()" and "string.atoi()", and
that it explain that you have to tell int() or string.atoi() the base,
if not base 10.  (And don't you go trying to tell it the _wrong_ base,
fella--it's run into your type before!)

of-all-personality-traits-computers-can-display,-neurosis-is-the
   -most-charming-<wink> ly y'rs,

=g2
p.s.  If anybody can explain to me any good reason why int() and
string.atoi() aren't allowed to interpret "0x" (and, heck--maybe even
"0X" <wink>) without including the "base" argument, I'd sure be
interested to know.
-- 
_____________________________________________________________________

Grant R. Griffin                                       g2 at dspguru.com
Publisher of dspGuru                           http://www.dspguru.com
Iowegian International Corporation	      http://www.iowegian.com