On Wed, Oct 31, 2018 at 9:14 PM Steven D'Aprano <st...@pearwood.info> wrote: > > On Wed, Oct 31, 2018 at 08:41:28PM +1100, Chris Angelico wrote: > > On Wed, Oct 31, 2018 at 8:24 PM Nicolas Rolin <nicolas.ro...@tiime.fr> > > wrote: > > > > > > > > > As a user I always found a bit disurbing that dict pop method have a > > > default while list and set doesn't. > > > While it is way more computationally easy to check wether a list or a set > > > is empty that to check if a key is in a dict, it still create a signature > > > difference for no real reason (having a default to a built-in in python > > > is pretty standard). > > > It would be nice if every built-in/method of built-in type that returns a > > > value and raise in some case have access to a default instead of raise, > > > and not having to check the doc to see if it supports a default. > > > > > > > https://www.python.org/dev/peps/pep-0463/ wants to say hi. > > > PEP 463 is too busy crying bitter tears in the corner after being > rejected to say "Hi". > > I don't think this is the same thing: PEP 464 is about being able to > catch arbitrary exceptions in arbitrary expressions in an ad-hoc manner. > Nicholas' suggestion is about making a consistent strategy of avoiding > the need to catch exceptions. > > I don't think I would agree with a broad rule "anything that raises can > return a default value" -- I don't think it makes sense to have, let's > say, len(obj, default=2). But on a case-by-case basis, it works for me.
And that's exactly why a broad rule of "anything that raises can be wrapped in a catcher" does make sense. Hence it may not be the same thing, but it is an alternative solution that doesn't require specifically angling for consistency. ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
