On Sun, Oct 4, 2009 at 5:29 AM, Martien Verbruggen <martien.verbrug...@invalid.see.sig> wrote: > On Sun, 4 Oct 2009 01:17:18 +0000 (UTC), > Grant Edwards <inva...@invalid.invalid> wrote: >> On 2009-10-03, ryniek90 <rynie...@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
I haven't tried it but couldn't you use scanf from ctypes? -- http://mail.python.org/mailman/listinfo/python-list
