
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/python-ideas@python.org/message/LNLCYR... having the template string built up separately from where it is applied to scanning is an important feature. -- Steve