I'm trying to shorten this again... On Sun, Feb 28, 2021 at 5:54 PM Cameron Simpson <c...@cskk.id.au> wrote:
> > Let's turn this on its head: > > - what specific harm comes from giving EGs container truthiness for size > testing? > For something that's not a pure container, this is an anti-pattern. No other subclass of BaseException (that I know of) can ever be falsey, so existing code would be forgiven to write "if e:" where "if e is not None:" was meant. > - what specific harm comes from returning an empty EG from split on no > match instead of None? > It would be an exception. What is raising an empty EG supposed to do? > - what specific harm comes from supporting iteration with a caveat about > metadata in the docstring, and maybe a recommendation of subgroup? > Iteration is such an easy-to-use API that it would become an attractive nuisance -- people would use it regardless of whether it's the right tool for the job. > > - if I wanted to override subgroup and split to not return None, is that > even possible with the current ? i.e. can I make a clean metadata > preserved EG from an empty list? For example: > > eg2 = eg.subgroup(lambda e: False) > > Does that get me None, or an empty group? If the latter, I can roll my > own subclass with my desired features. If not, I can't AFAICT. > It returns None. Writing a subclass that behaves differently than the base class will just confuse users who aren't aware of your overrides. > EGs _have_ a .errors attribute which has all these aspects, why not > expand it to the class as a whole? > They are different. The `errors` attribute may contain other EGs. But presumably iteration would recurse into those so as to flatten the tree and yield only leaf nodes. The attribute is necessary so it is possible to write traversal functions (including that iterator you so desperately want -- as a helper function). > You seem very happen to implement 80% of what I want using callbacks > (lambda e: ...), but I find explicit iteration much easier to read. I > rarely use filter() for example, and often prefer a generator expression > of list comprehension. > Our (the PEP authors') belief is that in most cases users are better off not handling the leaf exceptions. If you want to handle e.g. KeyError, the place to do that is in the try/except clause immediately surrounding the offending `__getitem__` operation (which will never raise an EG), not several stack frames below, where you're potentially dealing with an aggregate of many KeyErrors, or perhaps a KeyError and a TypeError. At that point the most common option is to ignore or log some or all exception types. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/GBUJJLRV5OH3ZE4OGWVVOBY2YLHFOWRR/ Code of Conduct: http://python.org/psf/codeofconduct/
