Is pythonic version of scanf() or sscanf() planned?

[Martien Verbruggen]

On Sun, 4 Oct 2009 01:17:18 +0000 (UTC),
	Grant Edwards <invalid at invalid.invalid> wrote:
> On 2009-10-03, ryniek90 <ryniek90 at gmail.com> wrote:
>
>> So, whether it is or has been planned the core Python
>> implementation of *scanf()* ?
>
> One of the fist things I remember being taught as a C progrmmer
> was to never use scanf.  Programs that use scanf tend to fail
> in rather spectacular ways when presented with simple typos and
> other forms of unexpected input.  

That's right. One shouldn't use scanf() if the input is unpredictable
osr comes from people, because the pitfalls are many and hard to avoid.
However, for input that is formatted, scanf() is perfectly fine, and
nice and fast. 

fgets() with sscanf() is better to control if your input is not as
guaranteed.

> Given the bad behavior and general fragility of scanf(), I
> doubt there's much demand for something equally broken for
> Python.

scanf() is not broken. It's just hard to use correctly for unpredictable
input.

Having something equivalent in Python would be nice where most or all of
your input is numerical, i.e. floats or integers. Using the re module,
or splitting and converting everything with int() or float() slows down
your program rather spectacularly. If those conversions could be done
internally, and before storing the input as Python strings, the speed
improvements could be significant.

There is too much storing, splitting, regex matching and converting
going on if you need to read numerical data from columns in a file.
scanf() and friends make this sort of task rather quick and easy.

For example, if your data is the output of a numerical analysis program
or data coming from a set of measuring probes, it often takes the form
of one or more columns of numbers, and there can be many of them. If you
want to take one of these output files, and transform the data, Python
can be terribly slow.

It doesn't have to be scanf(), but something that would allow the direct
reading of text input as numerical data would be nice.

On the other hand, if something really needs to be fast, I generally
write it in C anyway :)

Martien
-- 
                             | 
Martien Verbruggen           | Unix is user friendly. It's just
first.last at heliotrope.com.au | selective about its friends.
                             |