syntax difference

[Chris Angelico]

On Mon, Jun 18, 2018 at 8:33 PM, Bart <bc at freeuk.com> wrote:
> On 18/06/2018 01:10, Chris Angelico wrote:
>>
>> On Mon, Jun 18, 2018 at 9:30 AM, Rick Johnson
>> <rantingrickjohnson at gmail.com> wrote:
>>>
>>> On Sunday, June 17, 2018 at 2:07:40 PM UTC-5, Jim Lee wrote:
>>>
>>>> IMHO, trying to shoehorn static type checking on top of a dynamically
>>>> typed language shows that the wrong language was chosen for the job.
>>>
>>>
>>> Exactly.
>>>
>>> I'm not against the idea of Python growing a new feature.
>>> Features are great. My objection is concerned merely with
>>> the "how" it is implemented, not the "why" it was
>>> implemented.
>>>
>>> "Type-hint comments" would allow:
>>>
>>>   (1) those who need them, to use them.
>>>
>>>   (2) those who don't care about them, to totally ignore
>>>       them.
>>>
>>>   (3) and those who utterly *HATE* them, to write a simply
>>>       little function which will strip them from any and all
>>>       source code they might be forced to maintain.
>>
>>
>> Awwww. Isn't it cute, how he thinks that comments are easier to remove
>> than other elements equally well defined in the grammar?
>
>
> You're right in that neither task is that trivial.
>
> I can remove comments by writing a tokeniser which scans Python source and
> re-outputs tokens one at a time. Such a tokeniser normally ignores comments.
>
> But to remove type hints, a deeper understanding of the input is needed. I
> would need a parser rather than a tokeniser. So it is harder.

They would actually both end up the same. To properly recognize
comments, you need to understand enough syntax to recognize them. To
properly recognize type hints, you need to understand enough syntax to
recognize them. And in both cases, you need to NOT discard important
information like consecutive whitespace.

So in both cases, you would probably end up with something like 2to3.
The effective work is going to be virtually identical. And.... there's
another complication, if you want any form of generic tool. You have
to ONLY remove certain comments, not others. For instance, you
probably should NOT remove copyright/license comments.

> Both methods would fail with source code that exists as a string constant
> (for exec() for example), or source code that is synthesised at runtime.
>

Sure, but I would just consider that to be outside the scope.

ChrisA