On Wed, Oct 21, 2020 at 11:07:28AM -0700, Christopher Barker wrote:
> As for the question of do we need a scanning language at all? We already
> have pretty full features string methods, and regex for the complex stuff.
>
> I think yes -- for both simplicity for the simple stuff (the easy stuff
> should be easy) and performance. The fact is that while it's pretty easy to
> write a simple text file parser in Python with the usual string methods
> (I've done a LOT of that) -- it is code to write, and it's pretty darn slow.
I concur with your reasoning here. We have regexes for heavy duty string
parsing, and third-party libraries for writing full-blown parsers or
arbitrary complexity. We have Python string methods that can be used to
parse strings, but beyond the simplest cases it soon becomes awkward and
slow.
There's a middle ground of text parsing tasks that would seem to be a
good match for some sort of scanner, inspired by C's scanf, whether it
uses % or {} format codes.
> [*] I actually think f-strings are pretty much irrelevant here -- I don't
> want the variable names assigned to be buried in the string -- that makes
> it far less usable as a general scanner, where the scanning string may be
> generated far from where it's used.
Indeed. As I pointed out back in September:
https://mail.python.org/archives/list/[email protected]/message/LNLCYRPJUZYSTZRHPWSS4CJQ3YR5HNGQ/
having the template string built up separately from where it is applied
to scanning is an important feature.
--
Steve
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/RLZ63YBMNH5FDQBU7QOB36VF5A2TXLY4/
Code of Conduct: http://python.org/psf/codeofconduct/
