On Thu, 22 Oct 2020 at 03:16, David Mertz <me...@gnosis.cx> wrote:
>
> To bring it back to a concrete idea, here's how I see things:
>
> The idea of f-string-like assignment targets has little support.  Only Chris, 
> and maybe the OP who seems to have gone away.
> The idea of a "scanning language" seems to garner a fair amount of enthusiasm 
> from everyone who has commented.
> Having the scanning language be "inspired by" f-strings seems to fit nicely 
> with Python
> Lots of folks like C scanf() as another inspiration for the need.  I was not 
> being sarcastic in saying that I thought COBOL PICTURE clauses are another 
> similar useful case.  I think Perl 6 "rules" were trying to do something 
> along those lines... but, well, Perl.

There's also SNOBOL (and Icon) matching functions, although they are
less of a pattern "language" and more of a set of building blocks for
making matchers.

> In my opinion, this is naturally a function, or several related functions, 
> not new syntax (I think Steven agrees)
>
> So the question is, what should the scanning language look like?  Another 
> question is: "Does this already exist?"
>
> I'm looking around PyPI, and I see this that looks vaguely along the same 
> lines. But most likely I am missing things: https://pypi.org/project/rebulk/

The other one I know of (mentioned previously somewhere in all of
this) is https://pypi.org/project/parse/

>
> In terms of API, assuming functions, I think there are two basic models.  We 
> could have two (or more) functions that were related though:
>
> # E.g. pat_with_names = "{foo:f}/{bar:4s}/{baz:3d}"
> matches = scan_to_obj(pat_with_names, haystack)
> # something like (different match objects are possible choices, dict, 
> dataclass, etc)
> print(matches.foo)
> print(maches['bar'])
>
> Alternately:
>
> # pat_only = "{:f}/{:4s}/{:3d}"
> foo, bar, baz = scan_to_tuple(pat_only, haystack)
> # names, if bound, have the types indicated by scanning language
>
> There are questions open about partial matching, defaults, exceptions to 
> raise, etc.  But the general utility of something along those lines seems 
> roughly consensus.

Agreed

Paul
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/N4HFLC6J5R47GXOTKLW4KY546MR5QTVK/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to