[Python-ideas] a in x or in y

[Nick Coghlan]

On 14 Feb 2014 00:39, "Boris Borcic" <bborcic at gmail.com> wrote:
>
> Nick Coghlan wrote:
>>
>>
>>  >> In linguistics, there's a concept called "garden path" sentences -
>>  >> these are sentences where the first part is a grammatically coherent
>>  >> sentence, but by *adding more words to the end*, you change the
>>  >> meaning of words that appeared earlier.
>>  >
>>  >
>>  > Are you trying to say "X in Y and" forms a complete expression?? And
couldn't the lexer recognize "and in"
>> and cognates as single tokens anyway, like it apparently does presently
for "is not" ?
>>
>> Yes, there are ways around the technical limitation - the point of the
rest of the post was to make it clear
>> that was largely irrelevant, because it would still be too hard to read.
>>
>
> And my point was that your argument was rather unconvincing, for a
variety of reasons going from the difference between indefinite lookahead
and (rectifiable) two token lookahead, to the rarity of actual garden path
sentences that's evidenced by the fact that the single example you cite is
many decades old.

Huh? Garden path sentences are rare because they're hard to understand -
people instinctively realise that and rephrase them as something less
awkward. The example I used is the one that was used to explain the concept
to me because it's short and to the point.

The point of the elaboration in the post was to make it clear that we
*know* it is technical possible to work around the "only one token
lookahead" limitation, but that as a general principle of the language
design *we won't*. It's not an accident of the implementation, it's a
deliberate design choice intended to benefit both human readers and the
creators of automated tools. This is a constraint that people *need* to
take into account if they wish to make successful syntax change proposals
for Python.

A suggestion like this, which would require defining two or three word
tokens to meet the letter of the guideline while still breaking its spirit,
simply isn't going to happen (especially when it doesn't provide a
significant increase in expressiveness).

Now, if you want to argue with me about whether or not it's a good rule,
that's not an argument I'm interested in having - you can certainly design
usable languages that don't follow it, but I'm pointing out an existing
design principle for Python, and providing the general rationale for it
(i.e. simplicity), not trying to make the case that *all* languages should
be designed that way.

Regards,
Nick.

>
> Cheers, Boris Borcic
>
>
>
> ---
> Ce courrier électronique ne contient aucun virus ou logiciel malveillant
parce que la protection avast! Antivirus est active.
> http://www.avast.com
>
>
> _______________________________________________
> 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/20140214/b589a291/attachment.html>