Fair enough. I’ll let the OP defend his use case. 

On Wed, Dec 4, 2019 at 10:51 Serhiy Storchaka <storchaka@gmail.com> wrote:
04.12.19 20:01, Guido van Rossum пише:
> On Wed, Dec 4, 2019 at 9:18 AM Serhiy Storchaka
> <storchaka@gmail.com
> <mailto:storchaka@gmail.com>> wrote:
>     [Guido]
>       > I think I am +1 on
>       > adding re.findfirst() as proposed by the OP.
>     It is not clear what it should return. A Match object, a string, a
>     tuple, whatever? What should it return if no match found -- None, en
>     empty string, an empty tuple, error? I suppose that different users can
>     have different need. It is not practical to provide functions for all
>     combinations, it is easy to write a function for your needs using
>     re.search(). We can only add some receipts in the documentation.
>     The concrete user code can be a little bit simpler (one-liner) if we
>     provide an empty match object. For example:
>           (re.search(patter.string) or EmptyMatch).groups()
> Still pretty obscure. I propose that re.findfirst(...) should return the
> same thing as re.findall(...)[0] *if the findall() returns a non-empty
> list*, and otherwise it should return a default. The default defaults to
> None but can be set by passing default=... to the re.findfirst() call.
> For simple cases (no capturing groups, or a single one) that will return
> a string or the default value; if there are multiple capturing groups it
> will return a tuple of strings or the default. If the user always wants
> a tuple they can do so by specifying an appropriate tuple as default
> value; I don't propose to try and match the shape of the tuple on a
> successful match.

I think this is too fast. We have a single request for this feature, and
we do not know whether this behavior is what the OP wand and in what
context such function would be used, and how common such code. It may be
that using it is suboptimal, and the code can be simpler or more
efficient if use search(), finditer() or other existing functions.

I do not want to add yet one function for special case to the re module.
It is already too complex.

In contrary, there was good reasons for adding fullmatch() because it
provides functionality which is difficult to implement with other
functions. Actually some uses of match() and search() can be replaced
with fullmatch(), and this even can fix possible bugs. I am currently
working on a big patch for this (perhaps will split it on several issues).
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ESQCRVYL3PP352HFQU6SWHZXH7YJI3KI/
Code of Conduct: http://python.org/psf/codeofconduct/
--Guido (mobile)