syntax difference

Ian Kelly ian.g.kelly at gmail.com
Tue Jun 19 14:01:58 EDT 2018


On Mon, Jun 18, 2018 at 2:57 PM Rick Johnson
<rantingrickjohnson at gmail.com> wrote:
>
> On Monday, June 18, 2018 at 2:48:58 PM UTC-5, Ian wrote:
> > I would also note that none of this applies to type hinting
> > in any case. Type hints don't require the programmer to be
> > able to explain anything in natural language, nor are they
> > prone to becoming out-of-sync.
> >
> > Because if they do, then then the type analyzer will
> > complain the very next time you run it. So if you're trying
> > to make the case for type hints being treated like
> > comments, this isn't it.
>
> My point is perfectly clear to anyone who bothers to read it
> in its entirety.

Actually, I responded to this paragraph because it was the only one
that made any sense at all. I didn't consider the rest to be worth of
the post to be worth the time. But if you want, I'll respond to the
rest.

> From the POV of the interpreter, comments are nothing but a
> human crutch that is to be ignored.

This is like saying that from the POV of the interpreter, the keyboard
and monitor are nothing but a human crutch to be ignored. Okay, fine,
but so what?

> And even from the POV of a programmer, comments can be more
> useful if they are ignored than if they are not. Some
> programmers lack the skill required to properly explain the
> workings of an algorithm in natural language, and thus, the
> reader of such a comment will only become confused.
> Likewise, comments are notorious for becoming out-of-sync
> with the code. And at such point, comments are not only
> _confusing_ or _misleading_, no, they have become _lies_.

Already responded to above.

> The point is, from the POV of the interpreter and the
> programmer. comments are always going to be comments
> regardless of whether special purpose tools parse them or
> not. And given a choice between placing a new burden on a
> programmer or placing that burden on the machine, we should
> always choose to place that burden on the _machine_.

As far as I can tell, you seem to be arguing that putting type hints
in an annotation somehow puts a burden on the programmer, while
putting type hints in a comment somehow puts a burden on the machine.
This makes no sense to me. It's a "burden" (actually, a helpful tool)
to the programmer either way: whether it's in a comment or an
annotation, it's the programmer's job to keep it correct. Whether it's
in a comment or an annotation, it's up to the programmer to read it or
not in order to better understand the code. How it would be a burden
on the machine either way is beyond me.

> After all, it's the Python way.

Whatever this platitude is supposed to mean. I don't see "shift the
work of programming onto the machine" anywhere in the Zen of Python.

> The beauty of type-hint comments is that even without
> striping the type-hint comment from the source code, a
> programmer can more easily ignore a type-hint comment than
> the interleaved type-hint. This is especially true if the
> programmer uses an editor which has syntax hilighting. My
> syntax hilighter colors all comments a light gray. So
> therefore, i can skip block and blocks of comments in a
> fraction of second simply by quickly scanning down to the
> first line that is not grayed out.

This paragraph was the reason for my statement about "if you're trying
to make the case for type hints being treated like comments, this
isn't it". If this is not trying to justify why type hints should be
in comments (so you can brush them under the rug and pretend they
don't exist), then what is it?

> I have asked time and time again for someone to directly
> justify why py-dev won't offer a tool to remove the
> interleaved type-hint syntax from scripts.

You've been answered time and time again -- the devs are volunteers
and are not beholden to do whatever you want just because you don't
like it -- yet for some reason you keep asking.

> And yet, this whole thread has been a giant cascade of
> distractions from that one, simple, question.
>
> It is obvious to the impartial reader what is going on here.
>
> There is a systematic campaign of brow beating underway to
> punish those who do not blindly accept the validity of type-
> hints. And any wavering from the the official party line
> will be subject to retributions.

Yeah, just as soon as we finish covering up the moon landing hoax and
chemtrails, we're all going to a secret Hillary Clinton deep state
Illuminati meeting where we'll plan out how to control Python users
forever.

> That is not behavior of a community. A community would care
> for the opinions of all members.

Somebody who actually values the community would not make rude posts
on the mailing list about other members of the community, accusing
them all of being part of some conspiracy and accusing GvR of being a
puppet. All I'm saying, you reap what you sow.

And for all your desire to have your opinion heard, you seem awfully
eager to dismiss the opinions of those who actually like and want type
hints the way they are.

> I have made my sacrifice, by agreeing that i will accept
> the inclusion of type-hints even though i find the whole
> concept the be a violation of Python's core principles. All
> i ask in return is that the py-devs make a sacrifice of their
> own, by releasing a tool to remove these type-hints error
> free.

I don't know why you seem to think that this is a negotiation between
yourself and the devs. It's not. As far as the devs are concerned, the
discussion on the function annotation feature is done. It was done
over a decade ago, when the feature was added in Python 3.0. Nobody
back then brought up "oh, there needs to also be a tool to cripple the
new feature by removing all the annotations from the source".

And FWIW, I rather doubt that the devs care about whether you
personally "will accept the inclusion of type-hints". Python
development is not about what Rick Johnson will accept. If you really,
actually want this tool, then write it yourself. In the time you've
spent complaining about it, you could have written it several times
over already. But I don't think you will, because honestly, I don't
think that you actually care about this issue at all. This is all just
a control game for you, yet another soapbox for you to stand on and
pretend like you have some sort of power over the Python community.

> And then those of us who are offended by type-hints will
> have no reason to complain.
>
> And wouldn't that be nice?
>
> Wouldn't it be nice to actually have a sense of community
> again.
>
> Wouldn't it be nice to compromise instead of squabble?

You can stop squabbling over this ridiculous issue any time you want.
Just go away and write your type-hint-removal tool.



More information about the Python-list mailing list