syntax difference

[Rick Johnson]

On Tuesday, June 19, 2018 at 1:02:52 PM UTC-5, Ian wrote:
> On Mon, Jun 18, 2018 at 2:57 PM Rick Johnson
[...]
> > 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.

And if it's any consolation for you, you'll be happy to know
that i'm not at all surprised to learn this, either.

> 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.

If you had read my argument from the beginning of the
thread, you would have known that: whilst i never liked the
idea of Python having any kind of type annotations, i made
it very clear at multiple places in this debate, that i am
willing to grit my teeth and accept them *IF* the python dev
team would be kind enough to (1) force all type annotation
to be declared as comments, or (2) release a tool that will
remove type-hints (error free) from scripts.  

And while i don't particularly enjoy repeating myself, i am
hoping that perhaps this time it might sink in...

> > 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.

Ian, you an i both know that at our current level of
technological evolution, we do not yet have machines that
program themselves. That would require artificial
intelligence. However, while our machines cannot yet program
themselves, we certainly can offload many of the _burdens_
we programmers face onto these machines. And parsing, just
like computation, is one of those repetitive burdens that
machines perform far much better than any human ever could.

Furthermore, and contrary to popular belief, the full
philosophy of Python is not as neatly contained in the Zen
as some may think. No. The Python Zen is merely a list of
style prejudices which attempt to convey the "overall"
philosophy of the stereotypical python programmer. Not a
detailed style guide or an exhaustive rule book.

Moreover, Guido has written and has been documented in
interviews detailing the core principles of Python's design,
and i dare any of you to find me one quote from those early
days that gushed about type annotations.

Go ahead now....

Give 'er a go!

> > 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?

Why shouldn't i have the right to "brush type-hints under
the rug" Ian? After all, if the code *I* write doesn't
belong to *ME*, well then, who *HELL* does it belong to?

Is it not the right of the programmer to decide whether a
named function is more appropriate than a list comprehension
or an anonymous function?

Huh???

Is is not the right of the programmer to decide that string
formatting is more appropriate than string concatenation, or
vice versa?

Hmm???

Correct me if i'm wrong here, but i seem to remember an oft-
sited statement around these parts which says roughly:
"Python is programming for adults" . Meaning, that unlike
more "formalized" languages (such as Java, for instance),
Python does not try to dictate how we must write our code.

Sure, there are certain exceptions to this rule, like forced
indentation, for instance, but, compared to other languages,
Python is perhaps one of the most tolerant when it comes to
freedom.

For instance, Python does not force us to declare private
attribute and public attributes. Nor does it require us to
write setters or getters. Each programmer can decide for
themselves if they want to employ strategies which will
present proper interfaces, or not. This is "programming for
adults" -- okay.

So with that in mind, i cannot understand why Python wants
to saddle me with type-hints?

But what is even more disturbing, is the hostility that is
being displayed here when i request a simple tool that will
remove these offensive type-hints.

> 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.

Are you a dev? 

Is Chris a Dev? 

Is Steven a Dev?

> [...]
    
> 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.

Did you miss the part where i came to the table and made a
compromise? Yea -- that part -- the part where i compromised
to accept these type-hints in exchange for a tool that will
remove them. Hmm. Is that too much to ask? Surely you don't
believe that diplomacy is a one-sided compromise, do you?

> 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. 

And still you don't get it! I am willing to accept the
inclusion of type-hints, just give me a damn tool to remove
them!

> 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".

How will my non-use of type-hints "cripple" the feature?

Does choosing a named function over a list comprehension
somehow "cripple" list comprehensions? 

Does choosing a lambda over a named function cripple the
"named-function feature"?

No. 

That's ridiculous!

Besides, isn't it you and chris and steven who claim that i
am the only person in the whole community who doesn't want
type-hints? Well, if that's true (and it's not!) then how is
one person going to effect this supposedly "beloved" feature
of yours it that one person refuses to use it?

And BTW, what's the definition of FUD?

PS: Tell your friend Steven that I'm still waiting on the
nyms of all these supposed "people" of his who have been
requesting static typing since "day one".