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[2] except IndexError! "No value"
or just:
value = lst[2] 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 <ros...@gmail.com> 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.
>
> 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/
>
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
