Fair enough. I’ll let the OP defend his use case. On Wed, Dec 4, 2019 at 10:51 Serhiy Storchaka <storch...@gmail.com> wrote:
> 04.12.19 20:01, Guido van Rossum пише: > > On Wed, Dec 4, 2019 at 9:18 AM Serhiy Storchaka > > <storch...@gmail.com > > <mailto:storch...@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-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/ESQCRVYL3PP352HFQU6SWHZXH7YJI3KI/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido (mobile)
_______________________________________________ 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/OO6M52MDHQKVDMWSVB4PJQYWKHR3SAJE/ Code of Conduct: http://python.org/psf/codeofconduct/
