[Python-ideas] Proposed alternative postfix syntax [was PEP 505: None-aware operators]

[Abe Dillon]

Typo:
*You can usually guess that, since `person` isn't a local variable, we're
probably dealing with a generator *comprehension*

On Sun, Jul 29, 2018 at 11:00 PM, Abe Dillon <abedillon at gmail.com> wrote:

> [Steven D'Aprano]
>
>> really wish you would stop talking about "natural language" as if
>> there were only one (and it were English).
>
>
> I'm fine with that. I've just had someone jump down my throat before about
> being overly English-centric when talking about readability.
>
> [Steven D'Aprano]
>
>> even in English, that isn't how people read questions in general,
>> which is why we can still comprehend punctuation-less sentences
>
>
> Yes because you can make use of other context clues. So if I wrote:
>
> def f(person=None):
>     initial = person.name[0]?
>     ...
>
> You can anticipate the '?' at the end of the expression. Otherwise I would
> be clearly missing an important edge case.
> None checking is often done in very close proximity to some code that
> might yield a None, so this should rarely be a surprise unless the coder is
> writing the equivalent of a garden-path sentence.
>
> [Steven D'Aprano]
>
>> You may be able to find examples of English questions which do require
>> back-tracking
>
>
> It's easier, I'll admit, to find example's of exclamations that require
> back-tracking, but it's not unheard of!
>
> [Steven D'Aprano]
>
>> > and there are plenty of examples of Python following
>> > this pattern in other expressionized syntax like in comprehensions and
>> > ternary expressions.
>> But not binary operators which take only two arguments, in this case a
>> name and an attribute name.
>
>
>  Again, my proposal was never for a binary operator.
>
> [Steven D'Aprano]
>
>> > I actually think this makes sense for expressionized
>> > syntax because it puts the "meat" before the "potatoes". When you're
>> > reading code like:
>> >
>> > initials = [person.name[0] ...
>> >
>> > You can usually guess what goes in the `...` from context
>> Can you?
>> In that example I can't even guess if that's the start of a list
>> comprehension or a list display. If its a comprehension, I sure as hell
>> can't guess the important question of what it being iterated over.
>
>
> Maybe I should have fleshed out my example a little more. Usually there
> are plenty of context clues such that the latter part of a comprehension is
> more a formality for the computer's sake because computers, unlike humans,
> can't deal with ambiguity very well. So when you see:
>
> def func(people):
>     initials = [person.name[0] ...
>
> You can usually guess that, since `person` isn't a local variable, we're
> probably dealing with a generator so there's probably a `for` clause down
> the line where `person` is declared and it probably iterates over, I don't
> know, how about `people` and maybe there's a filter clause too. The point
> is that the most important information, the "meat" of the expression is up
> front.
>
> In the same vein, In the spirit of EAFP, it's better to get the meat of
> your business logic up front and do all the tedious-yet-necessary edge-case
> checking later just like:
>
> def func(person=None):
>     initial = person.name[0] ?
>     ...
>
> The business logic comes first and the edge-case checking follows.
>
> > so it's redundant, so it makes sense that it comes later.
>> If it's redundant, why don't we just leave it out?
>
>
> Because redundancy from the perspective of the reader doesn't imply
> redundancy from the perspective of the computer. People can make sense of
> ambiguous language in a way that computers cant. The sentence "time flies
> like an arrow" has over 11 valid interpretations, yet few humans would
> think "oh, you're commanding me to use a stop watch to measure some
> behavior of common flying insects in the same way that I would use the same
> instrument to measure the behavior of an arrow!". If I type:
>
> def func(people):
>     initials = [person.name[0] for person in people
>     return Counter(initals).most_common(1)[0]
>
> You, as a human, can probably guess with extremely high certainty that I
> meant to put a ']' at the end of the second line. In that sense, it's
> redundant to you, but not to the computer which doesn't know how to handle
> that situation. Does that make sense?
>
>
>
> On Sun, Jul 29, 2018 at 7:48 PM, Steven D'Aprano <steve at pearwood.info>
> wrote:
>
>> On Sun, Jul 29, 2018 at 12:08:46PM -0500, Abe Dillon wrote:
>>
>> > look-ahead and back-tracing is how people read punctuation like '?' and
>> '!'
>> > in natural language
>>
>> I really wish you would stop talking about "natural language" as if
>> there were only one (and it were English). Many natural languages don't
>> even have punctuation like '?', or if they do, they are a very recent
>> innovation. Spanish uses a bracketing pair of marks:
>>
>>    ¿Qué Mr Fawlty?
>>
>> while many other European languages make do with just one at the end.
>> And not all of them use the same symbol. (Greek uses the semi-colon,
>> which must make reading C-like languages a remarkable experience.)
>>
>> But even in English, that isn't how people read questions in general,
>> which is why we can still comprehend punctuation-less sentences
>>
>>    what's for dinner
>>
>>    where are you
>>
>>    who was the German professor in Lord Palmerston's quote about the
>>    Schleswig-Holstein business
>>
>> as questions, despite the lack of a question mark. Questions really only
>> need the question mark if they would otherwise be ambiguously either a
>> statement or a question.
>>
>> You may be able to find examples of English questions which do require
>> back-tracking, but that is generally considered to be a bad thing,
>> increasing surprise (not a good thing unless you are attempting humour)
>> and reducing the speed and ease of comprehension. See my earlier link
>> about garden path sentences.
>>
>> In other words, reducing not increasing readability.
>>
>>
>> > and there are plenty of examples of Python following
>> > this pattern in other expressionized syntax like in comprehensions and
>> > ternary expressions.
>>
>> But not binary operators which take only two arguments, in this case a
>> name and an attribute name.
>>
>>
>> > I actually think this makes sense for expressionized
>> > syntax because it puts the "meat" before the "potatoes". When you're
>> > reading code like:
>> >
>> > initials = [person.name[0] ...
>> >
>> > You can usually guess what goes in the `...` from context
>>
>> Can you?
>>
>> In that example I can't even guess if that's the start of a list
>> comprehension or a list display. If its a comprehension, I sure as hell
>> can't guess the important question of what it being iterated over.
>>
>>
>> > so it's redundant, so it makes sense that it comes later.
>>
>> If it's redundant, why don't we just leave it out?
>>
>>
>> --
>> Steve
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180729/e420cfbd/attachment-0001.html>