[Python-ideas] Add "default" kwarg to list.pop()
abedillon at gmail.com
Tue Nov 6 14:03:54 EST 2018
I don't understand the rationale behind PEP 463's rejection. Guido says, "I
disagree with the position that EAFP is better than LBYL, or "generally
recommended" by Python. (Where do you get that?..."; but it's been in the
official Python.org docs <https://docs.python.org/3/glossary.html> for a
while and even provides a pretty good justification for why EAFP is
preferable to LBYL (aside from the language calling EAFP "common", "clean",
and "fast" that's notably absent from LBYL's description):
"In a multi-threaded environment, the LBYL approach can risk introducing a
race condition between “the looking” and “the leaping”. For example, the
code, if key in mapping: returnmapping[key] can fail if another thread
removes *key* from *mapping* after the test, but before the lookup. This
issue can be solved with locks or by using the EAFP approach."
Which brings me to the question: What happens when a PEP gets rejected? Is
it final? Is there a process for reviving a PEP?
I personally would love to have *both* more consistent methods on built-in
classes AND exception handling expressions. I think the colon (and maybe
'except' keyword) could be replaced with an exclamation point:
value = lst except IndexError! "No value"
value = lst IndexError! "No value"
if that appeases the people who dislike the over-use of colons.
A full exception list would have to be in parentheses which get's ugly, but
would also be (I would wager) a less common form:
dirlist.append(os.getcwd() (AttributeError, OSError as e)! os.curdir)
That might need some work. I don't know if it's compatible w/ the compiler.
It may have to start with "try" or something, but it seems pretty close to
a workable solution.
On Wed, Oct 31, 2018 at 4:42 AM Chris Angelico <rosuav at gmail.com> wrote:
> On Wed, Oct 31, 2018 at 8:24 PM Nicolas Rolin <nicolas.rolin at tiime.fr>
> > 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.
> Python-ideas mailing list
> Python-ideas at python.org
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas