>
>
> neither EAFP nor LBYL is "better", they are both appropriate under
> different circumstances. Sometimes one is
clearer and more efficient than the other.
>
One of the reasons LBYL is sometimes cleaner than EAPF is because it has
more support from the language in the form of an expression which is what
PEP 463 intends to change.
The only time I would say that EAFP is clearly better is when LBYL
> introduces "Time Of Check To Time Of Use" bugs.
It also puts the intent of the logic up front instead of requiring the
reader to scroll through a preamble of edge-case checks to get to what the
code is actually trying to do.
I think that this is precisely the sort of syntax that prompted
> Guido to write many years ago that language design is not merely a
> problem-solving exercise.
The sort of syntax that prompted that post was "precisely" multi-line
lambdas. Guido explained that he tried to throw people off the idea of
multi-line lambdas by posing it as an unsolvable puzzle (which people
promptly solved) when really he just thought the concept of multi-line
lambdas was flawed to begin with. I agree with him on that point. The whole
point of a lambda is that, in certain cases, they allow you to write more
expressive code by saying in-line exactly what you want to do. It only
works if that action is easily expressed in a line:
button.onClick(lambda: print("Hello!"))
If it's a long an complicated bit of code, the expressiveness of lambda is
lost and it makes more sense to give it a name and write:
button.onClick(doThatComplicatedThing)
I'm not trying to solve a puzzle that implements an anti-pattern (unless
you have some argument for why expressionized try-except would be an
anti-pattern).
Aesthetics are important. This is not just a matter of finding an unused
> character or two and hammering it into the the language.
Yeah. That's why I didn't just try to find an unused character and hammer
it into the language without paying any regard to aesthetics. I find
value = lst[2] except IndexError! "No value"
to be pretty well in keeping w/ Python's aesthetics because raising an
exception pretty naturally fits with an exclamation point, but of-course;
aesthetics are subjective.
I know what Perl is BTW, and share your distaste for it.
Seeing that syntax, the phrase that came to my mind was not so much
> "close to workable" and more "kill it with fire!".
Funny, that's exactly how I felt about the None-aware operators, only; I
didn't reject the entire concept simply because I disliked the syntax
choice. I simply rejected the syntax choice because I disliked the syntax
choice...
On Tue, Nov 6, 2018 at 5:21 PM Steven D'Aprano <st...@pearwood.info> wrote:
> On Tue, Nov 06, 2018 at 01:03:54PM -0600, Abe Dillon wrote:
>
> > 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?...";
>
> I can't comment on Guido's question about "generally recommended", but
> as for the first part, I agree: neither EAFP nor LBYL is "better", they
> are both appropriate under different circumstances. Sometimes one is
> clearer and more efficient than the other. The only time I would say
> that EAFP is clearly better is when LBYL introduces "Time Of Check To
> Time Of Use" bugs.
>
>
> > Which brings me to the question: What happens when a PEP gets rejected?
> Is
> > it final? Is there a process for reviving a PEP?
>
> Nothing is final-final. You can try opening a competing PEP, or take
> over as champion of the existing PEP (assuming Chris is willing to step
> aside). You ought to respond to the reasons given in the rejection.
>
> It's probably a good idea to gauge the chances of success by asking on
> Python-Ideas and Python-Dev first, to avoid the core devs saying "Oh
> give it up, it's not going to happen!" after you've wasted time trying
> to revise a rejected PEP.
>
>
> [...]
> > I think the colon (and maybe
> > 'except' keyword) could be replaced with an exclamation point:
> >
> > value = lst[2] except IndexError! "No value"
> [...]
> > if that appeases the people who dislike the over-use of colons.
>
> And I think that this is precisely the sort of syntax that prompted
> Guido to write many years ago that language design is not merely a
> problem-solving exercise. Aesthetics are important. This is not just a
> matter of finding an unused character or two and hammering it into the
> the language. That's how you get Perl, which is not a pretty language.
>
>
> > 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.
>
> Seeing that syntax, the phrase that came to my mind was not so much
> "close to workable" and more "kill it with fire!".
>
>
> --
> Steve
> _______________________________________________
> 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/
